Who did what: the audit log and execution history

Execution history

Every instance keeps a timeline, oldest event first: the instance started, a step was visited, a job was created and completed, a task was claimed, a timer fired. Each event carries the variables as they were at that moment.

Manual interventions appear in the same timeline. If someone edits variables, moves a token or cancels the instance, the event names the person who did it.

Audit log

Every state-changing request is recorded automatically — new features are covered without extra work. Reads are not recorded.

Filtering

In the app's Audit Log page, or through the API, filter by person, action, resource, outcome and date range. Filtering by action matches the start of the name, so "process-instances" finds every action on instances.

curl -G http://localhost:3000/api/v1/audit-events \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "action=process-instances" \
  --data-urlencode "outcome=DENIED"

What is left out

• Request bodies, query strings, tokens and variable values are never stored.
• High-volume calls that change nothing meaningful — worker polling, heartbeats, test evaluations and draft autosave — are not recorded.
• A request with a missing or invalid token is rejected before it reaches the audit log. A request refused for lacking a role is recorded as Denied.