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 sounds like to the person answering. It is about a missing fact, and the fact is cheap to keep.

What history has to record to be worth having

A log saying only that somebody updated the record barely beats 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 matches 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 route. An import, an automation, a phone app, a background job. Those are exactly the changes nobody remembers making.

In Diract the database itself writes the history, 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 acted for a person, such as a cron sweep or a webhook, the entry reads automatic. That 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 collect three answers.

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 never learns its old value here. Somebody who cannot open a record never reads its changes.

That matters most for the fields you deliberately restrict. A history panel leaking a salary to everybody who can see the person creates a worse problem than the one it solves.

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.

The events that genuinely need telling get chosen, and the rest stay in 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
• Imports and automations record the same way people do
• The history opens before the team gets asked, 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