Workflow audit trail: what to record and why
3 min read · Updated Nov 11, 2026
When a process fails or an auditor calls, you need to say who did what, when, and with which data. What a workflow audit trail should record, and the questions it must answer.
The three questions
Sooner or later someone asks about a case: a client who disputes a decision, an internal auditor, a regulator, or your own team trying to understand a failure. The questions are almost always the same:
- What data entered the process?
- What changed it, and when?
- Who made each decision, and on what basis?
A workflow audit trail exists to answer those three questions quickly, from a record rather than from memory.
Engine history is not an audit trail
Camunda keeps history: which instances ran, which steps they passed, which variables they held. That is valuable, but it is the engine's view. It does not cover everything people do around the process: who changed a form mapping, who gave someone admin rights, who reassigned a task, who retried an incident.
An audit trail covers people's actions, across the whole platform, not only the engine's steps.
What to record
For every action:
- Who: the person (or system) that acted.
- What: the action, and what it acted on (a case, a task, a user, a connection).
- When: an exact timestamp.
- Outcome: whether it succeeded or failed.
For every case:
- The data that entered at each step, from the first form submission onward.
- Each change to that data, with the step that made it.
Record failures too. A refused sign-in or a denied permission is often exactly what an auditor wants to see.
Make it searchable
An audit trail nobody can search is a log file. People ask questions in two directions: "what did this person do last month?" and "what happened to this case?" Both must be quick to answer.
Keep it long enough, and no longer
Decide how long records are kept, write it down, and make sure the system enforces it. Too short and you cannot answer a question about last year; too long and you keep personal data you no longer need. Finished cases also need a home: once a process or an engine is retired, its history still has to be readable.
Access belongs in the trail too
An audit trail is only as good as the access rules around it. Record who has which role, check permissions on the server for every action, and alert administrators to sensitive events (an account locked, admin rights granted, connection credentials changed).
Checklist
- Who, what, when and outcome for every action
- Variables tracked per case from the first submission
- Search by person and by case
- Retention defined and enforced
- Finished cases readable after the process is retired
- Sensitive events alerted, not only logged
In Bridge
Every action in Bridge is recorded with who, what, when and the outcome, searchable by person and by what they acted on, and kept for the period your plan sets. Every variable from every form submission is captured at the moment of entry, timestamped and scoped to the process instance, and token replay shows any case step by step.
Completed instances stay searchable in the Historic Archive, Camunda 7 history included after a migration. Permissions are checked on the server, and admins are told when an account is locked, an address is blocked, someone is given admin rights or a connection's credentials change.