Who changed this record, and when they changed it

A price is wrong, a date has moved, or a status went back a step. Somebody asks what happened, and the honest answer from everybody is that they do not know.

That conversation is not about blame, whatever it feels like. It is about a missing fact, and the fact is cheap to keep.

What history has to record to be worth having

A log that says the record was updated is not much better than no log. Four things make it useful.

• Which field changed, rather than that something did.
• What it was before, because the old value is usually the one you need back.
• Who made the change, as a person rather than as the system.
• When, in your own timezone, so the entry can be matched to a shift or a phone call.

With those four, most questions answer themselves. Without the old value, you know who to ask and still have to reconstruct the number.

It has to be written by the database, not by the screen

A history written by each screen that saves a record misses every other way a record can change: an import, an automation, a phone app, a background job. Those are exactly the changes nobody remembers making.

In Diract the history is written by the database itself, on the record and on its values, so no write path can skip it. A change made by an import appears the same way a change made by a person does.

A change made for somebody still names them

Some changes are made by the system on a person's behalf: a route that runs as a service, a rule that fires. A history that records all of those as automatic is a history that goes blank at the moments you most want it.

Where a request is a person doing something, the entry names that person even when a server did the writing. Where nothing was acting for a person, a cron sweep or a webhook, it is recorded as automatic, which is honest rather than blank.

Use it for the boring questions, not just the disputes

History gets built for arguments and earns its keep on ordinary work. When did this job actually get marked complete. Has this customer's address changed since we quoted. Who set this status, so I can ask them what they saw.

Each of those is a question somebody would otherwise ask in a group chat and get three answers to.

It respects what each person can see

History is a record of your data, so it follows the same rules the data does. Somebody who cannot see a field does not learn its old value from the history, and somebody who cannot open a record does not read its changes.

That matters most for the fields you deliberately restrict. A history panel that leaked a salary to everybody who could see the person would be a worse problem than the one it was built to solve.

Notifications are the other half

History answers what happened after somebody noticed. A notification is what makes them notice, and the two solve different halves of the same problem.

Choose the events that genuinely need somebody told, and leave the rest to the history. A notification for every change trains people to ignore all of them, and then the record of what happened is all you have left.

What to do first

• Check that your history records the field, the old value, the person and the time
• Make sure imports and automations are recorded the same way as people
• Open the history before asking the team, on the next wrong number
• Restrict history the same way you restrict the fields themselves
• Notify on the few changes that need acting on, and let history hold the rest