Versioning Records via Relationships

Expert

Implement record versioning in FileMaker -- tracking every change to a record over time -- with efficient storage, retrieval, and comparison of historical versions.

What you'll learn

  • How to design a version snapshot table
  • How to capture and store record state on each commit
  • How to retrieve and compare versions via relationships
  • How to implement rollback from a historical version

Record versioning preserves every state a record has ever been in, enabling rollback, change attribution, and compliance auditing. The approach differs from temporal data patterns: versioning captures the entire record snapshot at each change, not just one changing field. The FileMaker implementation uses a Versions table with serialized record state and a relationship back to the current record.

1/4
1

Version snapshot table design

The Versions table stores a complete snapshot of a record at each commit. Key fields: the source record ID, a version number, the snapshot as JSON, and metadata (who, when, what changed).

TEXT
// Table: RecordVersions
// Fields:
//   VersionID        -- auto-enter serial (primary key)
//   SourceTable      -- text ("Contacts", "Invoices", etc.)
//   SourceRecordID   -- the primary key of the versioned record
//   VersionNumber    -- number, auto-incremented per SourceRecordID
//   Snapshot         -- text (JSON serialization of all field values)
//   ChangedBy        -- text (Get(AccountName))
//   ChangedAt        -- timestamp (Get(CurrentTimestamp))
//   ChangeNote       -- text (optional description of what changed)

Sign in to track your progress and pick up where you left off.

Sign in to FM Dojo