FileMaker Audit Trails: What to Log, Who Can See It, and How Long to Keep It

A useful FileMaker audit trail answers five questions about every change: who made it, what record and field it touched, when it happened, the old value, and the new value. FileMaker 2025 and FileMaker 2026 provide building blocks but not a finished, field-level audit log, so you build or install one, lock it down, and review it on a schedule.

Picture a quality manager three days before a customer audit. The auditor wants to know why the tolerance on a part specification changed in March. The record shows the current value and a “last modified by” name. It does not show the old value or the two edits before the last one. That gap is what an audit trail closes.

Quick takeaways

• Check whether your system captures all five facts: who, what, when, old value, new value.
• List integrations that write through the Data API or OData and confirm those changes get logged.
• Open your log table’s record access privileges and make sure everyday users cannot edit or delete entries.
• Agree on a retention period with whoever owns compliance, and put it in writing.
• Put a 30-minute monthly log review on someone’s calendar.

What does an auditor actually ask for?

Whether the audit comes from a customer, your quality system, or a regulator, the questions reduce to the same facts:

• Who. The account that made the change, not a shared login or a guess.
• What. The table, the record, and the specific field that changed.
• When. A timestamp you can trust, ideally from the server clock rather than a laptop.
• Old value. What the field said before the edit.
• New value. What it says now.

Capture those five facts for creates, edits, and deletes. A deleted line item that leaves no trace is the hardest change to explain, because nobody can see that it is missing.

FileMaker gives you the parts, not the finished log

No single native FileMaker feature produces a field-level history with old and new values. Our earlier overview of audit logging and activity monitoring in FileMaker 2025 covers the compliance case; here is what the platform provides.

The OnWindowTransaction script trigger. Added in version 20.1 and available in FileMaker 2025 and 2026, this file-level trigger runs a script after records are committed. Claris documents that it passes a JSON parameter with the file, base table, record ID, and operation (“New”, “Modified”, or “Deleted”) for each record, plus an optional context field, and suggests it for “an audit log of changes, who makes them, and when.”

{

“FileName” : {

“BaseTableName” : [

[ “Operation”, RecordID, FieldContent ],

…

]

}

}

Two documented limits matter. Reverted records do not fire it, which is correct. Direct access through the FileMaker Data API or OData API (the web interfaces other software uses to read and write your data) does not fire it either, although scripts run through those APIs can, so an integration writing straight to your tables goes unseen. The trigger also reports only that a record changed, without the old field values, so capturing them takes additional design.

Get functions. Get(AccountName) returns the authenticated account of the current user. Pair it with a server-side timestamp such as Get(CurrentHostTimestamp) so every entry uses one clock.

Auto-enter modification fields. A field can auto-enter the modification timestamp and account name. Each edit overwrites it, so it only tells you who touched the record last.

FileMaker Server logs. Claris documents that the Access.log records clients connecting and disconnecting, which databases they opened, and which account they used. It answers “who was in the system at 11 p.m.” but not field changes, and when it reaches the size limit it becomes Access-old.log and a new file starts. It is not a long-term archive.

The FileMaker 2025 and 2026 release notes we reviewed (2026 centered on Standby Server, Remote Backup, PDF script steps, and AI context) do not add a built-in, field-level audit log.

Build it yourself, or install one that already works

A homegrown log usually starts as a history table and an OnWindowTransaction script. The hard part shows up later. Someone adds a field and forgets to log it, or adds a table and nobody wires it in, and a change to a related record can leave the parent looking untouched. The gap surfaces when an auditor asks for history you never captured.

Kyo built the free Audit Log & Version History add-on for exactly that problem. Bringing a table under logging takes two script triggers. The add-on then captures every non-container field that changed, plus who changed it and when, even if the field was not on the layout. Two optional features extend it:

• Related Record Logging records changes to related records, including creation and deletion, so a deleted line item leaves evidence.
• Record Versioning & Restoration stores the previous version of a record on each change and lets an authorized user restore it.

A user edits an order line

↓

Every changed non-container field is captured with old and new value

↓

The log records the account and the time

↓

An authorized reviewer filters the history by record, field, or user

If your audit scope includes documents or images in container fields, plan for those separately.

Who can see the log, and who can change it?

An audit log that anyone can edit is a note, not evidence. Privilege sets make it trustworthy.

Record access privileges can be set per table, with separate View, Edit, Create, and Delete settings. A reasonable starting point for the log table:

• Everyday users: no access to view, edit, create, or delete log records.
• Reviewers (quality, operations, an auditor’s account): view only.
• The logging script: set to run with full access privileges, so it can write entries the user cannot. Only Full Access accounts can grant this.

Use record access privileges, not just layout privileges. Claris notes that layout privileges protect only a single view of the data.

Then keep the Full Access list short, because those accounts can still change anything, log included. A shared “admin” login undoes the “who” in every entry.

Your FileMaker audit trail needs a written retention policy

There is no single correct number. Retention depends on customer contracts, your quality system, and regulations that apply to your industry and data, and can differ by record type. To set it:

1. List every requirement that applies: customer agreements, quality manual, regulations, legal holds.
2. Take the longest period for each record type and confirm it with whoever owns compliance.
3. Write the policy down, including who approved it.
4. Archive older entries to a read-only file instead of deleting them, and include it in backups.
5. Export any server logs you need before they roll over.

For a broader pre-audit checklist, see FileMaker for year-end compliance and audit readiness.

A monthly review routine catches problems before an audit does

The log only helps if someone looks at it. A 30-minute monthly review is a reasonable starting point:

1. Confirm logging still works. Make a test edit on a logged table and find it in the log.
2. Check coverage. Compare tables and fields added this month against what is logged. Our post on using the Admin API to audit your database shows one way to pull schema details.
3. Review deletions. Every deleted record in a sensitive table should have an obvious reason.
4. Scan high-risk fields. Prices, quantities, specifications, and approvals changed by unexpected accounts or after hours.
5. Check access. Skim the Access.log for unfamiliar accounts and confirm the Full Access list has not grown.
6. Record the review. Note the date, reviewer, and follow-ups. Auditors often ask whether logs are reviewed as well as whether they exist.

Kyo Logic builds custom Claris/FileMaker and manufacturing software for New England companies. Our audit work starts with one question: which changes could you not explain today?

Frequently asked questions

Does FileMaker have a built-in audit trail?

Not as a finished feature. FileMaker provides building blocks such as the OnWindowTransaction script trigger and FileMaker Server access logs, but a field-level history with old and new values requires a custom build or an add-on.

Can an audit log track changes made through the FileMaker Data API?

It depends on how the change arrives. Claris documents that direct Data API or OData access does not activate OnWindowTransaction, while scripts run through those APIs can. Route integration writes through scripts if they need to be logged.

Can users delete their own entries from the audit log?

Not everyday users, if privilege sets are set up as described above. Accounts with Full Access can still change the log, which is why that list should stay short. Give everyday users no access to the log table, give reviewers view-only access, and let the logging script run with full access privileges so everyday users cannot write or change entries.

If you want the log without building it, download the free Audit Log & Version History add-on, or talk with Kyo Logic about which tables to log first.