Audit reference

The Audit folder of the Security branch holds one screen, the Audit Log: the workspace's central record of who did what and when. Other audit views cover narrower subjects and are documented with their own screens: Audit Logs under Users and Access for sign-ins and account changes, the Permission Audit Log for permission rule changes, and Logging for operational log lines.

Audit Log

Where to find it

Workspace > Security > Audit > Audit Log. Page key audit-log.

What is recorded

Each audit event is one row with these fields.

Field	Description
Occurred	When the event happened.
Category	One of login, logout, crud, configuration, workflow, permission, plugin, other.
Action	What was done, for example a record change or a sign-in.
Entity type and key	The kind of thing affected and its identifier.
Actor	The user or service that did it.
Module	The part of the platform that produced the event.
Source	The origin of the event.
IP address	The caller's address when known.
Success	true or false; sign-in failures and refused actions are recorded as false.
Correlation ID	Links every event of one request or one business event. The same identifier appears in the response header X-Correlation-Id and in the server log.
Detail	A JSON document with what changed.
Region code and residency violation	The region that processed the event, and a flag set when that region violated the workspace's declared data residency at the time of writing.

Screen layout

Summary chips at the top show today's counts: Total today, Logins, Failed logins, Config changes, Permission changes, Workflow events, Record updates, Plugin events. The chips API calls, AI requests and Security alerts are shown only when their counters are available. Below them the screen lists the most active actors, entity types and modules.

Settings

Setting	Values	Effect
Processing mode	sync (safest, blocks the request briefly), async (lower latency)	Whether an event is written before the request returns or queued for a background writer. Applies to the whole workspace.
Category switches	one per category	A category that is switched off stops recording new events of that category. Existing events stay.

Filters

Filter	Type	Description
Category	list	All categories, or one.
Action	text	Exact action.
Entity type	text	Exact type.
Actor	text	Exact actor.
Module	text	Exact module.
Correlation ID	text	All events of one request or business event.
IP address	text	Exact address.
Success or failure	list	Any, Success only, Failure only.
Date range	date and time	Events from and to a moment, interpreted as UTC.

Result columns: Occurred, Category, Action (with the entity type and key underneath), Actor, Module. Expanding a row shows the detail JSON.

Procedures

Find who changed a record

1. Set Entity type to the record kind, for example employee.
2. Optionally set Actor.
3. Open the row and read the detail JSON for the changed fields.

Follow one business event from end to end

1. Take the correlation id from a failed request (response header X-Correlation-Id) or from a workflow or integration trace.
2. Enter it under Correlation ID. Every audit event written during that request is listed in time order.

Investigate failed sign-ins

1. Set Category to login and Success or failure to Failure only.
2. Narrow by IP address or Actor.

Permissions

The audit endpoints are under /api/v1/authoring/audit/. Reading events and the summary passes the privileged action gate on audit.read; reading or changing the settings passes it on audit.manage. The actor must hold STUDIO_STAFF, TENANT_OWNER or TENANT_ADMIN, or have the permission granted explicitly, and no rule may deny it; otherwise HTTP 403 with actor "x" lacks audit.read permission. To let an auditor who is not an administrator read the log, grant audit / read to their role in the Permission Designer. You can still restrict the screen itself with a screen permission on its page (see Screen Permissions).

API

Purpose	Endpoint
Query events	GET /api/v1/authoring/audit/events with category, action, entityType, actor, module, ipAddress, success, correlationId, search, from, to, pageIndex, pageSize
Today's counts	GET /api/v1/authoring/audit/kpis
Processing mode	GET and PUT /api/v1/authoring/audit/settings/processing-mode with {"processingMode": "sync"} or "async"
Category switches	GET /api/v1/authoring/audit/settings, PUT /api/v1/authoring/audit/settings/{category} with {"enabled": false}

Page size is limited by the platform's standard grid limits. The grid filter bar sends equality filters on category, action, entityType, actor, module, success and correlationId, and range filters on occurredAt; unknown filter fields are ignored rather than rejected.

From the command line:

erp api get "/api/v1/authoring/audit/events?category=crud&entityType=employee&pageSize=20"
erp api get /api/v1/authoring/audit/kpis
erp trace <correlationId>

erp trace follows flow runs, events and queue messages of one business event.

Limits and behaviour

• Events are tenant scoped. A workspace never sees another workspace's events.
• With processing mode async, an event can appear shortly after the action; with sync, it is written before the response.
• Switching a category off is not retroactive and not reversible for the period it was off.
• Every request, entity change and plugin change that the platform audits carries the correlation id of its request, which is how the Trace an Event screens and this log relate.

Related

Users and Access, Permissions, Logging, Trace an Event.