Keeping a history of important record changes

Keep a history for fields whose past values matter to a decision, dispute or correction. Decide the question the history must answer before enabling a setting: who changed the record, what changed, when it changed and, where relevant, why. A timestamp alone rarely explains a business decision.

Choose the events worth retaining

Start with a short list: owner changes, approval decisions, status transitions, amounts used for a decision, and corrections to key identifiers may all matter in different apps. Record the old and new values where the platform supports it, the record ID, time, actor and source of the change. If an automation made the edit, identify the automation and, when possible, the action that initiated it.

The business reason may need its own field or event. An audit feed can show that a request changed from pending to rejected, but it may not explain the decision.

Capture the reason at the workflow step where a person makes it, and restrict later edits to that reason according to the app’s rules. Do not put sensitive free-text detail into a broad activity feed merely for convenience.

Check what the platform actually records

Native history can be useful, but inspect its coverage, retention and access. Dataverse auditing records changes on tables and columns where it is enabled, and Microsoft notes that audit entries may appear with a delay. Its standard auditing does not cover data retrieval or export operations. Those limits matter if the app owner expects a complete record of who viewed or downloaded information.

Airtable provides record-level revision history. Check its current coverage, retention and access limits before relying on it.

Before relying on native history for a migration or longer retention period, verify what will be preserved. Plan a separate, controlled log if needed.

Native audit capabilities across platforms

Audit history considerations by platform

Keep history usable and protected

Make the record’s current state easy to read while letting authorised staff inspect past changes. Give each event a stable link to its record and use a consistent time format. If an imported correction affects many records, retain the change job or batch reference so the individual events can be understood together.

Limit who can read histories that reveal previous personal or sensitive values. Decide how long the organisation needs the history and how it will be removed when that period ends. Check storage and retrieval limits in the chosen platform; enabling every field without a purpose can create a noisy log that is harder to investigate.

Test with a fictional record. Change one important field manually and through an automation, then check the actor, old value, new value, time and reason. Test a deletion and a restoration separately if those events matter. Document any gap and the compensating process.