Who Changed the Process? Your Workflow Needs a Change Log, Not Another Dashboard

Most UK tech teams would not dream of running code without version control. Most would not edit a contract without tracked changes. Yet the processes that keep the business running—how invoices get approved, how incidents get escalated, how new starters get access—often change without a record. Someone updates a rule in a workflow tool. Someone else sends a message saying the old way is dead. A third person finds out three weeks later when something breaks.

We have version control for artefacts. We have almost none for work itself. That is the gap a workflow change log fills. Not a dashboard. Not a platform. A simple, honest record of who changed what, why, and what happened next.

We track the code, not the current

A codebase has commits, branches and pull requests. A document has history and comments. A process has folklore. The current process is whatever the most experienced person says it is, until they go on holiday. Then it is whatever the last email said.

This is strange when you think about it. The workflow is the thing that turns strategy into output. It is where digital transformation either happens or evaporates. But it is also the thing we are least likely to document at the moment of change. We document the tool. We document the training. We rarely document the decision to change a step, a rule or an approval threshold.

The cost is rework, handover fog and audit gaps

Rework is the obvious cost. A problem gets fixed, then reintroduced because nobody remembers why the fix was there. A rule gets changed, then changed back because the original reason was never written down. The team spends time solving the same problem in different meetings.

Handover is the quieter cost. A new starter learns the process from a person, not a record. They inherit the workarounds but not the reasoning. When the person leaves, the process leaves with them. The organisation calls this 'tribal knowledge'. It is really undocumented change.

Then there is audit. Digital transformation is often measured by delivery: the platform went live, the training was completed, the steering group signed it off. But the question that matters later is simpler. What actually changed in the workflow, when, and who approved it? Without a log, the answer is a reconstruction. With a log, it is a record.

What a workflow change log looks like

It does not need to be fancy. A table is enough. One row for each meaningful change to a process. The fields can be as simple as: date, process, step, before, after, owner, reason, expected effect, what broke, and rollback plan. A link to the ticket or incident is useful. A review date is even better.

The important part is the reason. 'Changed approval threshold from £500 to £1,000' is a fact. 'Changed because finance was becoming a bottleneck for low-value purchases and the risk was accepted by the head of finance' is a record. One tells you what happened. The other tells you why it should stay that way—or why it should not.

Store it where the team already works. A wiki page, a shared document, a repository, a ticketing system. The tool does not matter. The habit does.

Why this is not another dashboard

Dashboards show state. A change log shows history and intent. A dashboard answers 'what is happening now?' A change log answers 'why is this like this?' Those are different questions, and most teams are drowning in answers to the first one.

A dashboard also invites performance. People tidy the numbers. A change log invites accountability. People explain the decision. That is a healthier culture for change, especially in organisations where transformation has become a series of launches rather than a continuous practice.

Start with one painful process

Do not launch a change log programme. That is how good ideas die. Pick one process that causes visible pain: expenses, onboarding, release approvals, incident escalation. Create the table. Backfill the last three changes from memory while they are still fresh. Then add a rule to the team's definition of done: no process change without a log entry.

Review it monthly. Not to police people, but to spot patterns. Are changes happening without review? Are the same steps breaking repeatedly? Is the rollback plan always 'ask Dave'? The log will tell you more about your workflow than most dashboards ever will.

The objection is usually admin, not principle

Someone will say it is too much paperwork. It is not, if you only log meaningful changes. Someone will say nobody will read it. They will, the first time something breaks and the log saves an hour of detective work. Someone will say it is not a priority. It becomes a priority when a handover goes wrong or an auditor asks for evidence.

We already accept this discipline in code. A commit without a message is considered poor practice. A pull request without context gets sent back. The workflow deserves the same courtesy. It is the operating system of the team, and right now many UK organisations are running it without a changelog.

A workflow change log is cheap, unglamorous and slightly boring. That is exactly why it works. It does not add another dashboard to ignore. It adds memory to the work. In a year of flux, that might be the most useful tool in the stack.