Every state change, every assignment, every approval, every login, every permission grant. Recorded with actor, target, and metadata. Cannot be edited. Cannot be deleted. Included on every workspace — not tier-gated to Enterprise.
Most agency engagements don't need an audit log. Right up until they do — usually a client dispute, a compliance review, or an unexpected SOC 2 questionnaire from a client's procurement team.
By the time you need it, you can't go back and create it. Either it's been recording all along or it isn't there.
Anything that changes state in a way that someone could later need to verify.
Created, status changed, assignee changed, due date changed, visibility changed, archived, restored, deleted. Every step.
Requested, approved, change-requested, declined — with actor, target, comment, and timestamp.
Created, edited, deleted. Edit history is preserved separately from the live comment text.
Login, login failure, password reset, email verification, session creation.
Role assignments, role changes, role deletions, custom role creation, permission grants and revocations.
Workspace renamed, team created/archived, member invited/removed/role-changed, impersonation grant created/revoked.
Every audit log entry has the same shape, regardless of action type. That consistency is what makes it queryable years later.
task.status_changed, approval.decided, role.created).Two surfaces, one event table.
User-facing. Per-task and per-client timeline. Visibility-aware — clients see the events that affect their work; the team sees the full feed. Renders the events as human-readable timeline entries.
Admin-only. Workspace-wide, including events not surfaced in any activity feed (auth, permissions, workspace admin). Compliance-shaped. Searchable by actor, target, action, and time range.
A “mutable” audit log is not an audit log. If administrators can edit or delete entries, the log can't function as a defense in any dispute — anyone challenging an entry can point to the possibility of tampering.
Workhouse's audit log is append-only at the database layer. There is no UI that edits or deletes entries. There is no API that edits or deletes entries. The only way an entry leaves the log is through workspace deletion (which removes the whole workspace, including the log).
Workspace members with the workspace:view_audit_log permission. By default, that's Owner, Admin, and the Read-only Auditor built-in role. Clients never see it; team members without the permission never see it.
Yes. Export as CSV or JSON, filtered by date range. Useful for compliance reviews, dispute prep, and yearly SOC 2 evidence collection.
Indefinitely, for the life of the workspace. We don't auto-prune the audit log — that defeats its purpose.
Yes. API key actions are recorded with actor_type='api' and the key ID. Useful for tracking automated webhook deliveries, scheduled task runs, and integration writes.
The audit log is the evidence. Export the time range they ask about, attach to your SOC 2 questionnaire response. For more formal procurement, our security@workhouse.app handles DPA requests and security questionnaires directly.
The action namespace is server-side — you can't add custom actions today. Most agency-relevant events are already covered. If you have a workflow that produces events worth recording, email us and we'll add the action.
Related: visibility model → · security → · privacy policy →