Record change history

A record remembers its flow

Every record keeps a trace of what happened to it. You can see who created it and when, who changed fields, and how the matter moved through the successive process stages. This is not extra work on the user's part; it happens by itself during ordinary work on the record.

The history is there so that the course of a matter can be reconstructed: what was agreed, when something changed, where a field's current value came from.

Uses of the history

• Taking over someone else's matter. Instead of asking around, you read what happened and enter the subject with context.
• Clearing up a misunderstanding. "The amount was different" is settled by looking at who changed it and when, without looking for someone to blame.
• Reconstructing a decision. You can see when a matter moved to the next stage and in what order.

Example. A client claims the deadline was different. You open the ticket's history and see that the deadline changed a week ago during an arrangement with the client, with the person and date given. The matter is cleared up in a minute, without guessing.

Limitations of the history

• The history is not comments. It shows what changed, but not always why. If a decision needs a justification, add it in a comment; the history remembers the fact of the change, the comment remembers the reason.
• The history is not a trash bin. It is a record of what happened, not an undo mechanism. Restoring data is handled by the administrator, if it is possible at all.

Additional notes

Since a record remembers changes, it is worth working as if someone might one day look at it, because they usually will. This is not surveillance, but transparency: everyone sees the same, reliable record of the matter's course, and no one has to rely solely on someone's memory.