Savant automatically records an audit event for every significant action taken in your organization - sign-ins, permission changes, workflow edits, runs, and data downloads. These logs provide a tamper-evident, UTC-timestamped record of who did what and when, designed to support SOX and other compliance audits.
Anatomy of an Audit Event
Every audit event is a JSON record with the same top-level structure. Here is an example of a completed workflow run:
Event ID | 1021b3d3-22d5-4979-a020-dbfad12e25e6 |
Timestamp | 2026-07-11T10:20:39.533Z |
Trace ID | f6167e1a85a0a7b4999f9d4cb7314cbe |
Organization ID | vghqrjoxbt |
Organization Name | Savant |
Workspace ID | general |
Workspace |
|
Actor Email | |
Actor Name | |
Actor Role | Analyst |
Actor Role (Metadata) | Analyst |
Event Category | CANVAS |
Action | node_added |
Result | SUCCESS |
Event Type | CANVAS_NODE_ADDED |
Login Method |
|
Session End Reason | NA |
Failure Reason | Wrong email or password |
Affected User | NA |
Affected User Role | NA |
Before Role | 9 values, but they are JSON config/state snapshots (node config, data edges, connection status), not role names — likely a field-mapping issue worth flagging |
After Role | {"config":{"connector":"csv","id":"ngzyxlymzx","name":"athletes new.csv","type":"csv"},"id":"source_xmd29w","name":"athletes new.csv","type":"source"} |
Role Scope | NA |
Permission Source | NA |
Deactivation Type | NA |
Flow ID | source_xmd29w |
Folder ID |
|
Flow Name | Analysis 2026-07-11T10:13Z |
Flow Version | 1 |
Governance Status | NA |
Node Count | 0 |
Previous Name | NA |
New Name | NA |
Submitter | NA |
Comment | NA |
Source Folder | NA |
Destination Folder | NA |
Export Format | NA |
Export Filename | NA |
Cloned Flow ID | NA |
Cloned Flow Name | NA |
Run ID | 32 distinct 16-char IDs, e.g. |
Trigger | manual |
Run Type |
|
Duration (ms) | numeric, 29 distinct, range ~ |
Nodes Executed |
|
Error Message | NA |
Error Node | NA |
Flow Creator | |
Connector |
|
Connection Name | NA |
Connection Type | application |
Path | NA |
Namespace | NA |
Node ID |
|
Node Name |
|
Node Type |
|
Canvas Node Count |
|
Canvas Edge Count |
|
Config | null |
Config Truncated | NA |
Schedule Frequency | NA |
Schedule Time | NA |
Schedule Timezone | NA |
Schedule Enabled | NA |
Reading this event top to bottom:
Who —
user_emailandactor_typeidentify the acting user and their workspace role.What —
event_typenames the exact event;actiongives a plain-verb summary.Where —
organization_idandworkspace_idplace the action in your tenant.When —
timestamprecords the moment in UTC.Outcome —
resultstates whether the action succeeded, andmetadatacarries the event-specific details, e.g., which workflow ran, how long it took, and how many rows were processed.
Field Glossary
Every audit event contains the following top-level fields. Fields marked required are always populated.
event_id(required) — Unique identifier (UUID) for the event. Use it to deduplicate records and reference a specific event with support.timestamp(required) — When the event occurred, in ISO 8601 format. All timestamps are UTC.organization_id(required) — The organization (tenant) where the action occurred. ShowsN/Awhen no organization context exists, e.g., an event recorded before sign-in completes.workspace_id(required) — The workspace where the action occurred. ShowsN/Awhen no workspace context applies.organization_name— Human-readable organization name.workspace_name— Human-readable workspace name.user_email— Email address of the user who performed the action. Automated actions, e.g., scheduled workflow runs, show[email protected].actor_username— Carries the same value asuser_email; retained for backward compatibility.actor_type— The workspace role of the acting user at the time of the action, e.g.,ADMIN,ANALYST, orSYSTEMfor automated actions.trace_id— Identifier that links all events generated by the same request. Useful when investigating an incident with support.event_type(required) — The specific event that occurred, e.g.,LOGIN_SUCCESS,FLOW_CREATED. See the full reference below.action— Short human-readable description of the action, e.g.,login,create_workflow.result— Outcome of the action:SUCCESSorFAILURE.failure_reason— Why the action failed. Populated only whenresultisFAILURE.before_state— JSON snapshot of the resource before the action, used for change tracking, e.g., a user's previous role or a schedule's previous configuration. Empty for events that create or access a resource.after_state— JSON snapshot of the resource after the action, e.g., the newly assigned role or updated schedule. Empty for events that delete or access a resource.metadata— JSON object with event-specific context. It always identifies the affected resource (resourceType,resourceId,resourceName) and itscategory, plus additional keys that vary by event type, e.g., login method for authentication events or run metrics for workflow executions.
Event Categories
Every event belongs to one of seven categories, recorded in metadata.category:
AUTHENTICATION — Sign-ins, sign-outs, sessions, MFA, and password changes.
RBAC — User lifecycle, role assignments, permission grants and revocations, and access denials.
SYSTEM — Workspaces, folders, connections, datasets, secrets, governance settings, notifications, and data downloads.
FLOW — Workflow lifecycle, approval and publishing governance, executions, apps, and exports.
CANVAS — Edits to the workflow canvas: nodes, edges, and saves.
AUTOMATION — Workflow schedules and automation configuration changes.
API — API calls and API token lifecycle.
Events recorded by earlier versions may carry the categories DATA_ACCESS, CONFIGURATION, or ADMINISTRATIVE. These remain valid for historical records.
Event Type Reference
The complete list of event types, grouped by category.
Authentication
LOGIN_SUCCESS, LOGIN_FAILED, LOGOUT, MFA_VERIFIED, PASSWORD_CHANGED, SESSION_EXPIRED
RBAC
USER_CREATED, USER_DEACTIVATED, ROLE_CHANGED, PERMISSION_GRANTED, PERMISSION_REVOKED, ACCESS_DENIED
System
WORKSPACE_CREATED, WORKSPACE_DELETED, WORKSPACE_RENAMED, WORKSPACE_ACCESSED, FOLDER_CREATED, FOLDER_DELETED, FOLDER_MOVED, FOLDER_RENAMED, FOLDER_UPDATED, FOLDER_ACCESS_DENIED, FOLDER_MEMBER_ACTION_DENIED, SECRET_CREATED, SECRET_UPDATED, SECRET_DELETED, DATASET_CREATED, DATASET_MOVED, DATASET_COPIED, DATASET_ACCESSED, DATASYSTEM_CONNECTED, CONNECTION_MOVED, CONNECTION_COPIED, CONNECTION_DELETED, CONNECTION_MODIFIED, CONNECTION_ACCESSED, GOVERNANCE_CONFIG_CHANGED, NOTIFICATION_DISPATCHED, DATA_DOWNLOADED
Flow
FLOW_CREATED, FLOW_DELETED, FLOW_RENAMED, FLOW_CLONED, FLOW_MOVED, FLOW_MODIFIED, FLOW_EXPORTED, FLOW_SUBMITTED, FLOW_APPROVED, FLOW_REJECTED, FLOW_PUBLISHED, FLOW_UNPUBLISHED, FLOW_ACCESSED, FLOW_RUN_STARTED, FLOW_RUN_COMPLETED, FLOW_RUN_FAILED, FLOW_RUN_CANCELLED, FLOW_APP_CREATED, FLOW_APP_PUBLISHED, FLOW_TEST_RAN, PUBLISHED_APP_OPENED, TEMPLATE_MOVED, TEMPLATE_COPIED
Canvas
CANVAS_NODE_ADDED, CANVAS_NODE_REMOVED, CANVAS_NODE_RENAMED, CANVAS_NODE_CONFIG_CHANGED, CANVAS_EDGE_ADDED, CANVAS_EDGE_REMOVED, CANVAS_SAVED, CANVAS_CLEARED
Automation
FLOW_SCHEDULE_CREATED, FLOW_SCHEDULE_UPDATED, FLOW_SCHEDULE_DELETED, AUTOMATION_CONFIG_CHANGED
API
API_CALL_LOGGED, API_TOKEN_CREATED, API_TOKEN_REVOKED
Audit Log Events Troubleshoot
Why does the actor show as [email protected]?
The action was performed automatically by the platform rather than a signed-in user - most commonly a scheduled workflow run. The actor_type for these events is SYSTEM.
Why is organization_id or workspace_id shown as N/A?
The event occurred before an organization or workspace context was established, e.g., a failed sign-in attempt happens before the platform knows which organization the user belongs to.
What are before_state and after_state?
They are snapshots of a resource on either side of a change, so an auditor can see exactly what changed. For example, a role update records the previous role in before_state and the new role in after_state. Events that create a resource have no before state, and events that delete a resource have no after state.
How do I identify failed or denied actions?
Filter on result equal to FAILURE and read failure_reason for the explanation. Access denials, e.g., ACCESS_DENIED and FOLDER_ACCESS_DENIED, are always recorded as failures and include the action the user attempted.
Why do metadata fields differ between events?
The metadata object carries context specific to each event type — a sign-in records the authentication method, while a workflow run records duration and row counts. The resource identifiers (resourceType, resourceId, resourceName) and category are present on every event.
What timezone are timestamps recorded in?
All timestamps are UTC, in ISO 8601 format. Convert to your local timezone when correlating with user reports.