Skip to content

CyberFM

  • Home
  • FileMaker Security
  • Disclaimer
  • Privacy Policy
  • Home
  • Calvin Mosiman
  • FileMaker – Audit Logs
  • Calvin Mosiman

FileMaker – Audit Logs

Dimitris Kokoutsidis 4 years ago3 months ago32 mins0

Implementing Comprehensive Audit Logs in FileMaker: An In-Depth Guide

Calvin Mosiman, Jan 6, 2021, FileMaker Training Videos

Table of Contents

  • Introduction
  • Understanding Audit Logs
    • What is an Audit Log?
    • Why Are Audit Logs Important?
    • Audit Logs in Different Industries
  • Audit Logging in FileMaker
    • FileMaker’s Capabilities for Audit Logging
    • Challenges and Considerations
  • Methods of Implementing Audit Logs in FileMaker
    • Field-Level Audit Logging
      • Pros and Cons
    • Record-Level Audit Logging
      • Pros and Cons
    • Using Script Triggers
      • OnObjectEnter and OnObjectSave
      • Other Relevant Script Triggers
    • External Audit Log Tables
      • Separation Model
      • Benefits of External Tables
  • Designing an Effective Audit Log System
    • Planning Your Audit Log
      • Defining Requirements
      • Compliance and Legal Considerations
      • Performance Impact
    • Data to Capture
      • User Information
      • Timestamp Details
      • Action Types
      • Old and New Values
      • Additional Context
  • Step-by-Step Implementation Guide
    • Step 1: Setting Up the AuditLog Table
      • Creating the Table
      • Defining Fields
      • Field Definitions and Calculations
    • Step 2: Establishing Relationships
      • Adding Global Fields
      • Defining Relationships in the Graph
      • Enabling Record Creation via Relationships
    • Step 3: Implementing Script Triggers
      • Understanding Script Triggers
      • OnObjectEnter Script Trigger
      • OnObjectSave Script Trigger
      • Applying Script Triggers to Fields
      • Handling Special Field Types
    • Step 4: Creating Audit Logging Scripts
      • Script for OnObjectEnter
      • Script for OnObjectSave
      • Optimizing Scripts for Performance
    • Step 5: Capturing User Actions
      • Logging Edits
      • Logging Record Creations
      • Logging Deletions
      • Logging Script Executions
    • Step 6: Viewing and Managing the Audit Log
      • Designing the Audit Log Layout
      • Implementing Search and Filter Options
      • User Interface Considerations
  • Advanced Topics
    • Auditing Container Fields
      • Challenges with Container Fields
      • Solutions for Auditing Containers
    • Handling Related Records and Portals
      • Auditing Changes in Portals
      • Script Triggers in Portals
    • Performance Optimization Techniques
      • Using Global Variables and Let Functions
      • Minimizing Impact on User Experience
      • Batch Processing Audit Logs
    • Managing Audit Log Growth
      • Archiving Old Logs
      • Purging Strategies
      • Storing Logs Externally
  • Best Practices for Audit Logging
    • Security and Access Control
      • Restricting Access to Audit Logs
      • Protecting Audit Log Integrity
    • Compliance with Regulations
      • Industry-Specific Requirements
      • Data Retention Policies
      • User Consent and Privacy
    • Testing and Validation
      • Testing Script Triggers
      • Validating Audit Log Entries
      • Performance Testing
  • Case Studies and Examples
    • Implementing Audit Logs in a Medical Database
      • Challenges Faced
      • Solutions Implemented
    • Audit Logging in Financial Applications
      • Compliance Requirements
      • Performance Considerations
  • Common Pitfalls and How to Avoid Them
    • Overloading the Audit Log
    • Inefficient Script Design
    • Ignoring User Experience
  • Conclusion
  • References and Further Reading

Introduction

In today’s data-driven world, maintaining a detailed record of all actions performed within a database system is not just a best practice but often a legal necessity. Audit logs play a critical role in tracking changes, ensuring data integrity, and meeting compliance requirements. FileMaker, a versatile and user-friendly database platform, offers various ways to implement audit logging. However, creating an efficient and comprehensive audit log in FileMaker requires a deep understanding of its features and potential pitfalls.

This in-depth guide aims to provide you with a thorough understanding of how to implement audit logs in FileMaker. We’ll explore different methods, step-by-step implementation strategies, advanced topics, best practices, and real-world examples to equip you with the knowledge to build a robust audit logging system tailored to your needs.

Understanding Audit Logs

What is an Audit Log?

An audit log, also known as an audit trail, is a chronological record that documents all activities and changes within a system. It captures detailed information about events such as:

  • User Actions: Logins, logouts, data entry, edits, deletions.
  • System Events: Script executions, errors, system alerts.
  • Data Changes: Before and after values of modified data.

An audit log serves as an immutable record that can be reviewed to understand the history of data and user interactions within the system.

Why Are Audit Logs Important?

Audit logs are vital for several reasons:

  • Accountability: They hold users accountable for their actions, deterring malicious activities.
  • Compliance: Many industries are subject to regulations requiring detailed audit trails (e.g., HIPAA, GDPR, PCI DSS).
  • Data Recovery: Audit logs can help restore data to a previous state in case of accidental changes or corruption.
  • Security Monitoring: They assist in detecting unauthorized access or unusual activities.
  • Operational Insights: Audit logs can provide insights into system usage patterns and performance bottlenecks.

Audit Logs in Different Industries

Different industries have specific requirements for audit logging:

  • Healthcare: Under HIPAA, patient data access and modifications must be tracked.
  • Finance: Financial institutions must comply with regulations like SOX and PCI DSS, requiring detailed audit trails.
  • Legal: Law firms need to maintain records of document access and changes for compliance and accountability.
  • Manufacturing: Tracking changes in production data ensures quality control and traceability.

Understanding the specific needs of your industry is crucial in designing an effective audit log system.

Audit Logging in FileMaker

FileMaker’s Capabilities for Audit Logging

FileMaker provides a flexible platform that allows developers to implement custom audit logging solutions. Key features that facilitate audit logging include:

  • Script Triggers: Automate actions in response to user interactions.
  • Global Variables: Store session-specific data.
  • Relationships: Create complex data models to support audit logs.
  • Calculation Fields: Perform real-time calculations and data manipulation.
  • Custom Scripts: Define custom behaviors and data processing.

Challenges and Considerations

Implementing audit logs in FileMaker comes with challenges:

  • Performance Impact: Logging every action can slow down the system if not optimized.
  • Complexity: Managing audit logs for large systems requires careful planning.
  • Storage Requirements: Audit logs can grow rapidly, consuming storage space.
  • User Experience: Overly intrusive logging can hinder usability.
  • Security: Ensuring that audit logs are tamper-proof and secure.

Addressing these challenges requires a balanced approach that meets audit requirements without compromising system performance or user experience.

Methods of Implementing Audit Logs in FileMaker

There are several methods to implement audit logs in FileMaker, each with its own advantages and trade-offs.

Field-Level Audit Logging

Tracks changes at the individual field level within a record.

  • How It Works: Captures the old and new values of a field whenever it is modified.
  • Use Cases: Ideal for systems where tracking specific data changes is critical.
  • Implementation: Often uses script triggers like OnObjectEnter and OnObjectSave.

Pros and Cons

Pros:

  • Provides detailed change history.
  • Allows for granular tracking of sensitive data.
  • Facilitates data recovery at the field level.

Cons:

  • Can impact performance if not optimized.
  • Increases complexity in script management.
  • May consume significant storage over time.

Record-Level Audit Logging

Logs changes at the record level.

  • How It Works: Captures events like record creation, modification, and deletion.
  • Use Cases: Suitable for systems where the fact that a record changed is more important than what changed.
  • Implementation: Can be implemented using scripts triggered on record commit.

Pros and Cons

Pros:

  • Simpler to implement than field-level logging.
  • Less impact on performance.
  • Requires less storage space.

Cons:

  • Less detailed information about specific changes.
  • May not meet compliance requirements for detailed logging.

Using Script Triggers

Script triggers automate the execution of scripts in response to user actions.

OnObjectEnter and OnObjectSave

  • OnObjectEnter: Triggered when an object (e.g., a field) becomes active.
  • OnObjectSave: Triggered when changes to an object are committed.

Implementation:

  • OnObjectEnter: Capture the current value of the field before changes.
  • OnObjectSave: Compare the new value with the old value and log the change if different.

Other Relevant Script Triggers

  • OnRecordCommit: Triggered when a record is committed.
  • OnObjectExit: Triggered when leaving an object.
  • OnLayoutEnter: Useful for logging when users access specific layouts.

External Audit Log Tables

Storing audit logs in separate tables or even separate FileMaker files.

Separation Model

  • Definition: Separating the audit log data from the main application data.
  • Implementation: Use external data sources to link to audit log tables.

Benefits of External Tables

  • Performance: Reduces the load on the main database.
  • Scalability: Allows for independent scaling and maintenance.
  • Security: Easier to secure and restrict access to audit logs.
  • Maintenance: Simplifies backups and archiving of audit data.

Designing an Effective Audit Log System

Planning Your Audit Log

Effective audit logging requires careful planning.

Defining Requirements

  • Identify What to Log: Determine which actions and data changes need to be captured.
  • User Actions: Edits, deletions, creations, logins, logouts.
  • Data Sensitivity: Prioritize fields with sensitive information.

Compliance and Legal Considerations

  • Regulatory Requirements: Understand laws and standards that apply.
  • Data Privacy: Ensure compliance with privacy laws like GDPR.

Performance Impact

  • Assess System Load: Consider the impact of logging on system performance.
  • Optimize Design: Plan for efficient data capture and storage.

Data to Capture

Identify the specific data points to include in your audit logs.

User Information

  • Account Name: Get(AccountName)
  • User ID: If using custom user IDs.
  • Privileges: User roles and permissions.

Timestamp Details

  • Date and Time: Use Get(CurrentTimestamp) for precise timing.
  • Time Zone: If users are in different time zones, record the time zone or use UTC.

Action Types

  • Event Type: “Edit”, “Create”, “Delete”, “Login”, “Logout”.
  • Script Names: If logging script executions.

Old and New Values

  • Field Changes: Store both old and new values for comparison.
  • Multi-Field Changes: If multiple fields change simultaneously, log each or capture a snapshot.

Additional Context

  • Layout Name: Get(LayoutName) to know where the action occurred.
  • Script Parameters: If relevant to the action.
  • Device Information: If necessary, capture Get(SystemPlatform).

Step-by-Step Implementation Guide

Step 1: Setting Up the AuditLog Table

Creating the Table

  1. Go to File > Manage > Database.
  2. Create a New Table: Name it AuditLog.

Defining Fields

Add the following fields to the AuditLog table:

  • LogID (Text): Primary Key, auto-enter calculation Get(UUID).
  • Timestamp (Timestamp): Auto-enter creation timestamp.
  • UserAccount (Text): Account name of the user.
  • ActionType (Text): Type of action performed.
  • TableName (Text): Name of the affected table.
  • RecordID (Text): Primary key of the affected record.
  • FieldName (Text): Name of the field changed.
  • OldValue (Text): Value before the change.
  • NewValue (Text): Value after the change.
  • CalculationDetails (Text): Any additional calculations or context.
  • ScriptName (Text): If logging script executions.
  • LayoutName (Text): Name of the layout where the action occurred.

Field Definitions and Calculations

  • LogID: Use Get(UUID) to ensure a unique identifier.
  • Timestamp: Set to auto-enter the creation timestamp.
  • UserAccount: Auto-enter calculation Get(AccountName).
  • TableName: Use auto-enter calculation if applicable.
  • ActionType: Populate via scripts or script parameters.
  • OldValue/NewValue: Ensure these fields can handle large text if necessary.

Step 2: Establishing Relationships

Adding Global Fields

In your main data tables (e.g., Contacts):

  1. Add a Global Field: Name it g_AuditUUID (Text, global storage).

Defining Relationships in the Graph

  1. Open Relationship Graph.
  2. Create a New Table Occurrence: For AuditLog, name it AuditLog_Contacts.
  3. Define Relationship:
    • Contacts::g_AuditUUID = AuditLog_Contacts::LogID.
  4. Enable Creation via Relationship:
    • Check “Allow creation of records in this table via this relationship” for AuditLog_Contacts.

Enabling Record Creation via Relationships

This setup allows you to create new audit log records by setting fields in the related AuditLog_Contacts table occurrence without scripting New Record commands.

Step 3: Implementing Script Triggers

Understanding Script Triggers

Script triggers automate scripts based on user actions. They are essential for capturing data changes without requiring users to perform additional steps.

OnObjectEnter Script Trigger

  • Purpose: Capture the current value of a field before any changes are made.
  • Implementation:
    • Script Parameter: Pass the field name and current value.
    • Action: Set a global variable to store the old value.

OnObjectSave Script Trigger

  • Purpose: Detect when a field has been modified and log the change.
  • Implementation:
    • Script Parameter: Pass the field name.
    • Action:
      • Compare the new value with the stored old value.
      • If different, create a new audit log record.

Applying Script Triggers to Fields

  1. Select Fields to Audit: In layout mode, select the fields you want to track.
  2. Assign Script Triggers:
    • OnObjectEnter: Assign your AuditCaptureOldValue script.
    • OnObjectSave: Assign your AuditLogChange script.
  3. Script Parameters:
    • Pass necessary information such as field names and table names.

Handling Special Field Types

  • Checkboxes and Radio Buttons: Ensure script triggers are compatible.
  • Drop-Down Lists: May require additional handling if values are auto-entered.
  • Container Fields: Special considerations discussed later.

Step 4: Creating Audit Logging Scripts

Script for OnObjectEnter

Script Name: AuditCaptureOldValue

Steps:

  1. Set Variable:
    • Name: $$AuditOldValue
    • Value: Get(ActiveFieldContents)
  2. Set Variable:
    • Name: $$AuditFieldName
    • Value: Get(ActiveFieldName)

Purpose: Store the current value and field name in global variables for later comparison.

Script for OnObjectSave

Script Name: AuditLogChange

Steps:

  1. If: $$AuditOldValue ≠ Get(ActiveFieldContents)
  2. Set Field (via relationship to AuditLog):
    • Fields to Set:
      • UserAccount: Get(AccountName)
      • Timestamp: Get(CurrentTimestamp)
      • ActionType: "Edit"
      • TableName: "Contacts" (or dynamic if applicable)
      • RecordID: Primary key of the current record.
      • FieldName: $$AuditFieldName
      • OldValue: $$AuditOldValue
      • NewValue: Get(ActiveFieldContents)
  3. End If

Purpose: If the field value has changed, log the details in the AuditLog table.

Optimizing Scripts for Performance

  • Use Let Functions: To set multiple variables efficiently.
  • Minimize Script Steps: Keep scripts lean to reduce execution time.
  • Error Handling: Include error capture to handle unexpected issues.

Step 5: Capturing User Actions

Beyond field edits, you may want to log other user actions.

Logging Edits

  • Field-Level Edits: Handled via script triggers as described.
  • Record-Level Edits: Use OnRecordCommit to detect changes at the record level.

Logging Record Creations

  • OnRecordLoad: Not suitable since it triggers on viewing records.
  • After Creating a Record: Include audit logging in the script or process that creates new records.

Example Script:

  1. Set Field (via relationship to AuditLog):
    • ActionType: "Create"
    • Other relevant fields.

Logging Deletions

Since deleted records cannot trigger scripts after deletion, you must handle this proactively.

  • Override Delete Commands:
    • Replace default delete menu options with custom scripts.
  • Custom Delete Script:
    1. Capture Record Details:
      • Store necessary data in variables.
    2. Create Audit Log Entry:
      • Log the deletion action.
    3. Delete Record:
      • Use Delete Record/Request.

Logging Script Executions

  • Purpose: Track when specific scripts are run, especially those that modify data.
  • Implementation:
    • At the start of the script, create an audit log entry with ActionType: "Script Start".
    • At the end, log "Script End".
    • Include ScriptName and any relevant parameters.

Step 6: Viewing and Managing the Audit Log

Designing the Audit Log Layout

Create a layout based on the AuditLog table for viewing logs.

  • Layout Type: List view is recommended.
  • Fields to Display:
    • Timestamp
    • UserAccount
    • ActionType
    • TableName
    • RecordID
    • FieldName
    • OldValue
    • NewValue
    • ScriptName (if applicable)

Implementing Search and Filter Options

  • Filters:
    • By Date Range
    • By User
    • By ActionType
    • By Table or Field Name
  • Quick Find: Enable for searching text across multiple fields.

User Interface Considerations

  • Access Control: Ensure only authorized users can view audit logs.
  • Navigation: Provide intuitive ways to access the audit log from relevant areas.
  • Performance: Optimize the layout for fast loading, especially with large datasets.

Advanced Topics

Auditing Container Fields

Challenges with Container Fields

  • Size: Containers can store large files, impacting performance.
  • Data Type: Binary data is not easily compared or logged.

Solutions for Auditing Containers

  • Log Metadata: Capture file names, sizes, and types instead of the actual content.
  • Checksums: Use functions to generate a hash or checksum of the file for comparison.
  • Versioning: Store previous versions of files in separate records or external storage.

Example:

  • OnObjectSave Script:
    • Use GetContainerAttribute( Get(ActiveFieldContents); "MD5" ) to generate a hash.
    • Compare with previous hash to detect changes.

Handling Related Records and Portals

Auditing Changes in Portals

  • Challenge: Changes in related records via portals may not trigger scripts in the main table.
  • Solution:
    • Apply script triggers to fields within the portal.
    • Use relationships to log changes in the related table’s audit log.

Script Triggers in Portals

  • Implementation:
    • Assign OnObjectEnter and OnObjectSave triggers to portal fields.
    • Ensure scripts reference the correct context and relationships.

Performance Optimization Techniques

Using Global Variables and Let Functions

  • Global Variables: Store session-specific data without affecting other users.
  • Let Functions: Efficiently set multiple variables in calculations or script parameters.

Example:

filemakerCopy codeLet (
  [
    $$AuditOldValue = Get(ActiveFieldContents);
    $$AuditFieldName = Get(ActiveFieldName);
    Result = ""
  ];
  Result
)

Minimizing Impact on User Experience

  • Asynchronous Logging: Consider logging actions asynchronously to prevent delays.
  • Conditional Logging: Only log significant changes or actions to reduce overhead.
  • UI Feedback: Provide subtle indicators that actions are being logged without interrupting the user.

Batch Processing Audit Logs

  • Deferred Logging: Collect changes and log them in batches during idle times.
  • Server-Side Scripts: Use Perform Script on Server (PSoS) to offload processing.

Managing Audit Log Growth

Archiving Old Logs

  • Regular Archiving: Move older logs to an archive table or external storage.
  • Automation: Schedule scripts to archive data periodically.

Purging Strategies

  • Retention Policies: Define how long to keep audit logs based on compliance requirements.
  • Selective Deletion: Purge logs that are no longer needed.

Storing Logs Externally

  • Separate Files: Use a dedicated FileMaker file for audit logs.
  • External Databases: Export logs to SQL databases or other storage solutions.

Best Practices for Audit Logging

Security and Access Control

Restricting Access to Audit Logs

  • Privileges: Use FileMaker’s privilege sets to limit who can view or edit audit logs.
  • Layout Restrictions: Hide audit log layouts from unauthorized users.

Protecting Audit Log Integrity

  • Prevent Deletion: Restrict delete permissions on the AuditLog table.
  • Tamper-Proofing: Use scripts and field options to prevent unauthorized modifications.

Compliance with Regulations

Industry-Specific Requirements

  • Healthcare (HIPAA):
    • Ensure all access to patient data is logged.
    • Protect audit logs with appropriate security measures.
  • Finance (PCI DSS):
    • Mask sensitive data in logs.
    • Regularly review logs for suspicious activities.

Data Retention Policies

  • Define Retention Periods: Based on legal requirements and business needs.
  • Document Policies: Keep clear documentation of your data retention and archiving strategies.

User Consent and Privacy

  • Inform Users: Notify users if their actions are being logged.
  • Privacy Compliance: Ensure logging practices comply with privacy laws like GDPR.

Testing and Validation

Testing Script Triggers

  • Thorough Testing: Test all script triggers to ensure they fire correctly under all conditions.
  • Edge Cases: Consider unusual user behaviors or data inputs.

Validating Audit Log Entries

  • Accuracy: Verify that logs accurately reflect the actions taken.
  • Completeness: Ensure that no significant actions are omitted.

Performance Testing

  • Load Testing: Simulate high user activity to assess performance.
  • Monitoring: Use performance metrics to identify bottlenecks.

Case Studies and Examples

Implementing Audit Logs in a Medical Database

Challenges Faced

  • Compliance: Needed to meet HIPAA requirements for patient data.
  • Performance: Large number of fields and records led to slow logging processes.

Solutions Implemented

  • Field-Level Logging: Prioritized essential fields for detailed logging.
  • Optimization: Used lean design principles to improve performance.
  • Custom Scripts: Overrode default behaviors to ensure all actions were logged.

Audit Logging in Financial Applications

Compliance Requirements

  • Data Security: Required masking of sensitive financial data.
  • Audit Trails: Needed comprehensive logs for all financial transactions.

Performance Considerations

  • Asynchronous Logging: Implemented server-side scripts to handle logging without affecting user experience.
  • Data Archiving: Regularly archived logs to maintain system performance.

Common Pitfalls and How to Avoid Them

Overloading the Audit Log

  • Problem: Logging every single action can lead to overwhelming amounts of data.
  • Solution:
    • Prioritize: Focus on critical data changes.
    • Conditional Logging: Implement logic to skip insignificant changes.

Inefficient Script Design

  • Problem: Poorly designed scripts can slow down the system.
  • Solution:
    • Optimize Scripts: Use efficient coding practices.
    • Reduce Script Steps: Keep scripts as lean as possible.

Ignoring User Experience

  • Problem: Intrusive logging can disrupt workflow.
  • Solution:
    • User-Centric Design: Ensure logging doesn’t interfere with usability.
    • Feedback Mechanisms: Provide clear, unobtrusive indicators.

Conclusion

Implementing a comprehensive audit log in FileMaker is a complex but essential task for many applications. By carefully planning, leveraging FileMaker’s features, and following best practices, you can create an audit logging system that meets your organization’s needs without compromising performance or user experience.

Remember to:

  • Plan Thoroughly: Understand your requirements and constraints.
  • Optimize for Performance: Use efficient design and coding practices.
  • Ensure Compliance: Stay informed about relevant laws and regulations.
  • Test Rigorously: Validate your system under various conditions.

With the right approach, your audit log will be a valuable asset, enhancing security, accountability, and trust in your FileMaker solutions.

References and Further Reading

  • FileMaker Script Triggers Guide: FileMaker Documentation
  • Best Practices for FileMaker Development: FileMaker Community
  • Understanding HIPAA Compliance: HIPAA Journal
  • GDPR Compliance Guidelines: EU GDPR Information Portal
  • PCI DSS Requirements: PCI Security Standards Council

Sample file: Audit Log

Tagged: Account Alerts API Audit Log Automation AWS Backup Balance Best Compliance Container Documentation FileMaker Pro FM Training Videos GDPR Integrity Load Logging Login Maintenance Management Monitoring Plan Practice Principle Privacy Privilege Recovery Response Restore Role Scalability Server Step-by-Step Storing Test Tracking Training Transactions UPS Usability YouTube

Dimitris Kokoutsidis

Post navigation

January 6, 2021
FileMaker Server Command Line Reference
January 6, 2021
Emergency Procedures for FileMaker Server Crashes

Related Articles

FileMaker’s Built-in Audit Logs

Dimitris Kokoutsidis1 year ago3 months ago0