Audit and traceability

Traceability means being able to follow work from a request to its changes and eventual release. Audit records add accountability: who acted, what was affected, and when. Together, these help an enterprise review how its AI builder is being used.

The Audit log shows meaningful events in the current Workspace, including app publishing, URL-suffix changes, role changes, and build rounds. Newest events appear first. Audit-view permission is required.

Open and filter the Audit log

Choose Audit log in the Workspace section. Use the narrowest useful filters:

• Event type accepts comma-separated names such as app.published or app.slug.changed.
• Actor user id limits results to one UUID. Leave it blank for any actor.
• Since excludes events before the selected date.
• Significance shows all events or Major events only.

Choose Refresh to request the first page again, Clear to reset filters, or Load older when more events are available.

Read an event

Each row shows the event type, subject kind, actor kind, timestamp, and summary. Major events have a major badge. These fields distinguish a user action from a system event.

Some events include Show payload with structured details that may contain sensitive identifiers. The Audit log describes what occurred; open the relevant app or Workspace setting to check its present state.

Audit log versus app history

Use the Workspace Audit log to learn who performed an action, what subject it affected, and when.

Use app history in the editor for one app’s work sequence or build rounds. The Audit log combines events across the Workspace.

Neither view proves that a published journey works. Open the production URL and test it; a publish event does not replace the app’s current status.

If no events match, clear the filters, confirm the selected Workspace, and try a shorter Since range. If the page is absent, your role may not include audit-view permission.

Define a complete enterprise audit

For enterprise oversight, agree on the events your review must cover: access and sharing changes, model configuration, build activity, and releases. Confirm coverage and retention for your tenant rather than assuming the workspace list is an exhaustive record of every action.

For a release review, identify the project and deliverable, find the relevant build history, and connect the release to its actor and timestamp. Review configuration and access decisions alongside that work. Keep access to audit details limited to authorised reviewers.

See enterprise governance for the controls surrounding that record. Auditability does not by itself establish a regulatory certification or prove that an app is secure.