When developing a professional FileMaker solution, logging is an important part of maintaining stability, security, and traceability. Knowing who did what and when helps developers troubleshoot issues, audit changes, and understand how a system evolves over time.
With the help of the MBS FileMaker Plugin, you can implement powerful logging mechanisms directly in your solution. Below are several practical approaches to logging activity in a FileMaker system.
1. Log User Login and Logout
A simple but very useful step is logging when users start and leave the system.
You can do this by running scripts when the solution opens and closes. These scripts can store information such as:
-
Account name
-
Timestamp
-
Workstation or host
-
Database file
For example, a startup script can log when a user logs in, while a shutdown script records when they log out. This gives you a clear overview of user sessions and can help track usage patterns or troubleshoot problems.
2. Track Structural Changes with Automated XML Exports
Another powerful technique is monitoring schema and layout changes in your solution.
You can configure FileMaker Server to run a scheduled script every hour that exports the database structure as XML files into a folder. These XML snapshots can then be committed to a Gitrepository automatically.
This provides several benefits:
-
A full history of database structure changes
-
The ability to compare versions over time
-
Insight into what changed and when
-
Identification of the account responsible for a change
For example, if someone moves a button on a layout or modifies a script, the change will appear in the repository history.
Over the years, this repository becomes a valuable timeline of how your solution evolved.
Check the "Save a copy as XML" script step and our Shell functions to run git commit.
3. Log Schema Changes
The MBS FileMaker Plugin provides SchemaChange functions that allow you to detect when structural changes occur in your FileMaker solution.
These functions can log events such as:
-
Script modifications
-
Layout changes
-
Table or field changes
The logged information includes:
-
Account name
-
Internal IDs for the modified object
-
Timestamp
With the IDs you can determine which script or layout was changed. Combined with the Git-based XML history described earlier, you can even inspect the exact modifications made on a specific day. A simple call to FM.InsertRecord may do the logging.
4. Audit Data Changes in Records
Structural changes are important, but so are data changes.
The MBS FileMaker Plugin includes audit functions that allow you to log modifications to records. This makes it possible to track:
-
Which user changed a record
-
When the change occurred
-
Which fields were modified
-
The previous and new values
This kind of auditing is essential for many business systems, especially where traceability and compliance are required.
5. Automatically Handle Idle Users
Another practical logging and workflow tool is the Idle Timer functionality.
Sometimes a user begins editing a record and then walks away from their desk. In FileMaker, that record remains locked while it is being edited, which prevents other users from modifying it.
Using the Schedule.StartScriptOnIdle function from the MBS FileMaker Plugin, you can run a script after a defined period of inactivity. For example, after two minutes of idle time, the script could:
-
Automatically commit the record
-
Release the record lock
-
Optionally log the event
This keeps the system running smoothly and prevents records from being locked unnecessarily.
Conclusion
Implementing proper logging in FileMaker solutions provides valuable insights into both system behavior and user activity. By combining built-in scripting with features from the MBS FileMaker Plugin, developers can log:
-
User sessions
-
Schema modifications
-
Structural version history
-
Data record changes
-
Idle user behavior
These tools help developers maintain reliable systems and understand how their solutions evolve over time.
Happy FileMakering!