Audit trail and administrative evidence

Purpose and access

Audit provides a read-oriented record of administrative activity available to the current workspace and role. Use it to inspect an event's action, actor, timing and associated record, then correlate those details with the relevant administrative screen. The visible audit trail is one source of evidence; it does not independently prove payment settlement, provider completion or execution success.

Before investigating, define the question you want to answer. For example: which permitted administrator changed a laboratory user's role, when was a trial extension recorded, or what happened around a worker configuration attempt? Keep the investigation within the workspace and information your role authorizes.

Locate and inspect events

1. Confirm the active account, workspace and role in the account menu.
2. Open Audit and wait for the inventory to load.
3. Use Search audit events to narrow the records by the displayed information relevant to your question.
4. Apply available column filters, checking the selected period and status where applicable.
5. Open View details for the event and inspect its visible action, actor, timestamp and subject.
6. Open the associated screen, such as Users, Tenants or Cloud workers, and confirm the current record state.
7. Refresh the audit view if you need to inspect a recent authorized action.

Columns changes presentation. Clear filters restores the broader visible inventory. Rows, Previous and Next control pagination. On mobile, use Filters and the existing table viewport rather than assuming hidden columns are absent from the record.

Build a useful evidence note

Record the administrative question, workspace scope, displayed event time, action, subject and observed result. Distinguish the recorded event from a conclusion that you infer after checking another screen. Preserve the relevant time context when comparing timestamps from different systems.

Use Export CSV only when the investigation requires an authorized export. Store the result in an approved location and share the minimum needed information. Exports may contain identifiers or account details even when the application avoids showing secrets.

Synthetic acceptance exercise

In an authorized laboratory, edit the description of an editable tenant role. Confirm the saved role in Roles & permissions, refresh Audit and locate the corresponding activity if recorded and visible to your role. The exercise succeeds when the role state and audit observation describe the same intended action within the same tenant.

If the event is absent, inspect filters, paging, workspace selection and the delay between the action and refresh. Do not invent an audit event or conclude that an action failed solely because the currently displayed page does not contain it.

Errors and recovery

A loading failure should be reported using the visible message and a bounded description of the scope and time. Retry after checking connectivity and session validity. A permission denial requires an authorized access review; switching tenants is not an evidence-preserving workaround.

For the action itself, return to Users, Roles and permissions, Subscription and billing or Cloud workers. The current record and its supported detail view remain necessary parts of the investigation.