Change Tracking

Shared draft

Every project has exactly one draft changeset that is shared across all team members. When anyone creates, updates, or deletes an entry, the change is automatically recorded in this shared draft.

The draft is visible to every member of the project in real time. There is no need to merge branches or resolve conflicts — the whole team works on the same draft simultaneously. The draft persists until it is committed, at which point a new empty draft is created automatically.

The database enforces the one-draft-per-project invariant: a unique partial index ensures only one changeset with status draft can exist per project at any time.

Change events

Each individual edit is recorded as a change event within the draft changeset. A change event captures:

• Change type — what kind of modification was made
• Diff — the before/after state of the entry data, stored as a JSON diff
• Summary — an optional human-readable description of the change
• User — who made the change
• Timestamp — when the change was made

Change types

Committing changes

When the team is satisfied with the accumulated changes in the draft, a member with the changeset:commit permission (Member role or higher) can commit the changeset.

A commit requires a message describing what changed — similar to a Git commit message. You can optionally attach links (e.g. to a Jira ticket or design document) to provide context.

When committed, the changeset's status moves from draft to committed, the committer and timestamp are recorded, and a new empty draft is created for subsequent changes.

Changelog & history

The Change Log page shows the complete history of committed changesets for a project. Each entry displays:

• The commit message and any attached links
• Who committed and when
• The number and types of changes included
• The current review status

Click on any changeset to see its individual change events with full diffs showing the before and after state of each modified entry.

Diff views

Every change event includes a JSON diff showing exactly what changed. Diffs are stored as structured data (not text patches), making them precise and queryable. For each modified entry, you can see:

• Which fields were added, removed, or modified
• The old and new values for each changed field
• The tab and entry context (which bundle and entity was changed)

Approval workflow

Committed changesets enter an optional approval workflow. Admins and Owners can review changesets and provide their decision.

Approval decisions

Each approval includes the reviewer's identity, timestamp, and an optional comment explaining their decision. One reviewer per changeset — the unique constraint ensures a user can only have one active decision per changeset.

Review status

Beyond the approval decision, each committed changeset carries a review status that tracks the implementation lifecycle. The reviewer (or the team) can mark each changeset to indicate its current state:

A reviewer can also attach review notes explaining their decision, and link a changeset to a related changeset (e.g. pointing a superseded changeset to the one that replaces it).

Rollback

Admins and Owners with the changeset:rollback permission can roll back a committed changeset. A rollback reverses the changes and marks the changeset status as reverted. The individual entries are restored to their prior state, and the rollback itself is recorded as change events with the rolled_back change type.

Permission summary