Every change has a name attached
37 audit event types cover the workflow, deployment, approval, permission and membership lifecycles. They are recorded as the change happens — not reconstructed from application logs afterwards.
37 event types covering edits, deployments, approvals, permissions and membership — with the actor, the timestamp and the payload.
What gets recorded
- Change history per workflow — Created, updated, deleted and deployed are recorded at the workflow level, and nodes, edges and transformation scripts are recorded individually. When a workflow starts behaving differently, the edit that changed it is in the history rather than in someone's memory.
- Deployment and approval trail — A deployment is audited across its whole lifecycle — planned, executed, completed or cancelled — and the individual resource changes it made are correlated back to it by deployment id. Approvals record who released a paused run, and when.
- Access and membership events — Invitations, removals, role changes and permission changes are audit events in their own right. The question an auditor actually asks — who had access to this workspace in March, and who granted it — is answered from the record rather than from a current-state screenshot.
- Judgement calls, not just successes — When someone accepts a failure as known and acceptable, or spends a locked workflow's retry override, that decision is recorded too. These are the privileged, cost-bearing calls that a plain execution log loses entirely.
Platform capabilities
- 37: Audit event types
- Actor + time: Attached to every recorded event
- Configurable: Retention window, per workspace
What exactly does the audit log capture?
37 distinct event types spanning five areas: workflow and node edits, execution outcomes, deployments, approvals and access changes. Each event carries the actor, the timestamp and a sanitised payload describing the change.
Can I tell which deployment caused a specific change?
Yes. Resource-level events carry the id of the deployment that produced them, so a deployment and everything it touched read as one correlated set rather than as two unrelated lists you have to line up by timestamp.
How long is the audit history kept?
Retention is configured per workspace, with a standard and an extended window in days, and the sweep that enforces it is itself an audited event. That means the record of what was removed, and when, survives the removal.