Commits and versions

Grunddata never overwrites data. Every save appends. This gives you a complete, attributable history of your data without having to configure anything.

Two concepts do the work: commits and versions.

Commits

A commit is a single save operation. It does not matter whether it covers one row typed in the web app or five thousand rows uploaded from Excel — it is one commit.

A commit records:

Part	Description
Message	What the change was for. Supplied by the user or the web app’s editable default.
Author	The signed-in user, resolved to a name and email.
Timestamp	When the commit was created.
Sequence	A monotonically increasing number giving a strict chronological order.
Record versions	Every record version the save produced.

Write a useful commit message

The Excel plugin and the Google Sheets add-on both ask for a message before uploading. This is your audit trail talking to your future self.

• Good: Add Q3 counterparties from onboarding list
• Good: Correct currency on 14 EUR accounts flagged in reconciliation
• Useless: update, fix, .

Where to see commits

Open a table’s overview page. The Recent commits panel lists the latest commits touching that table, with the message, the author and the timestamp. Choose View all to search the table’s commit history.

From commit history you can:

• View the active records as they were at a selected commit.
• Compare a commit with the preceding table commit or with the current records.
• Restore the table to a selected commit. A restore replaces the current table state and is recorded as a new commit with an editable default message.

Snapshots and comparisons load records a page at a time, so large tables do not need to be downloaded all at once.

When saving records or adding/editing attributes in the web app, the commit message is shown inline with the save controls. Each form starts with a short editable default, which can be replaced or cleared before saving. Attribute defaults include the attribute name, such as Counterparty attribute updated.

Note

Commits are listed per table. A single upload that changed rows in one table appears against that table; the commit itself is the unit of work.

Versions

Every record has a version. It starts at 1 and increments on every change.

Saving a change appends a new row rather than updating the existing one:

id	source_id	version	account_name	is_deleted	commit
018f…a1	018f…77	1	Nominal amount	false	Initial load of chart of accounts
018f…b4	018f…77	2	Nominal amount (SEK)	false	Clarify account names for reporting
018f…c9	018f…77	3	Nominal amount (SEK)	true	Retire unused accounts

Reading this table:

• source_id is identical in all three rows. It is the same account throughout.
• id identifies one version row. It changes each time.
• version counts the revisions.
• The current state of a record is simply its highest version.

This is why identifiers matter

Everything above hinges on source_id staying constant. If a source_id is overwritten during an upload, the chain breaks and you get an orphan instead of a new version. See Identifiers.

Soft deletes

Deleting a record does not remove anything. It appends a new version flagged as deleted.

The record then:

• Disappears from the records grid.
• Is excluded from Excel and Google Sheets downloads.
• Is excluded from the OData feed.
• Keeps its full history, attributable to whoever deleted it and why.

Deleted is not gone

Do not use a delete to remove sensitive data that should never have been entered. It is still in the history. Contact your administrator if you have a genuine erasure requirement.

What this gives you

1. Answer “who changed this?” — every version carries its author and its commit message.

2. Answer “when did this value change?” — versions are ordered, and commits have a strict sequence.

3. Answer “what did this look like at year end?” — the versions in place at that time are still there.

4. Recover from a bad bulk edit — the previous values were never destroyed.

Practical guidance

One logical change, one commit

Do not batch unrelated changes into a single upload just to save a click. Uploading the Q3 counterparty additions and an unrelated currency correction together produces one commit whose message can only describe half of it.

Correct data, do not delete and re-add

Editing a row keeps its source_id and adds version 2. Deleting it and adding a new one creates a brand new source_id, breaking every reference pointing at the old record and splitting its history in two.

Version numbers are per record, not per table

Record A can be on version 7 while record B is still on version 1. There is no table-wide version number. If you need a frozen snapshot of a whole structure, see the model copying approach in Coming from Microsoft MDS.