One switch per model
Whether a model is audited is decided by a switch on the model. Every create, update and delete then leaves a revision. If a request changes several objects – an order with its line items – all changes share the same revision number. Revisions are only created when the request completes successfully.
Each revision holds the state of the object plus:
- revision number and timestamp
- user name, network address and the client software used
- after a user switch, also the person who was actually signed in
- the type of change: created, updated or deleted
Reading the history
The history of a record returns all revisions, newest first, page by page if needed. It can be read by anyone with the model’s read and history permissions who would be allowed to see the record itself – the same data filters as for normal reads apply here too. Protected fields are missing from every old revision as well if the matching role is absent. A deleted record keeps its history, with the deletion as its last revision. What a single revision changed becomes visible by comparing it with the one before.
Roll back without rewriting the past
A roll back restores an earlier state by writing it as a new revision. The states in between are kept, and the roll back itself can be undone. Simple fields and single references are restored, for file models also the matching file content. Rolling back requires the corresponding permission and only works on records the person is allowed to see.
More than a modification date
Every record carries its creation and modification time. Who changed what and when, what was there before and who deleted it – only the history answers that. For people, tenants and permissions, Identity & Access keeps an audit of its own. The Data Management history shows what the data looked like.
Revisions contain personal data: who made the change and what the object contained, including values that have since been cleared. Data Management keeps them without an expiry date. Which retention periods apply and who may see the history is up to your project. So audit deliberately what must be proven or restored – such as contracts, orders and master data.
What this means day to day
Traceability is created at the moment of saving, not shortly before an audit.
- A technical basis for your evidence – the assessment within your quality and compliance processes remains with you.
- Accidental changes can be undone without touching the database.
- Clear answers to the question “who changed this, and when?”