Roles, audit trail and reports
Grant and revoke platform roles, trace every platform command in the audit trail, and read release readiness and capability reports.
Before you begin
Platform access is separate from business permissions. Only the workspace owner (a superuser, or an administrator of every company) can grant or revoke roles. Anyone else with a role sees no Grant a role button, and the server refuses with 'Only the workspace owner can grant platform roles.'
A company member with no role sees only the note about the console and the Capabilities list. The server answers other requests with 'The platform console is for the workspace owner and people given a platform role.'
Grant a role
- Open Platform > Configuration > Platform roles.
- Press Grant a role.
- Choose the Person: an active user who is not an owner. 'The workspace owner already holds every platform role.' for an owner.
- Choose the Role: Operator, Release manager, Independent approver, Configuration owner or Viewer / auditor.
- Press OK.
The row reads Active = Yes with who granted it and when. Granting the same role to the same person again is refused: 'That person already holds this role.'
Revoke a role
Press Revoke on the row. The row stays, marked Revoked. Revoking again says 'That role is already revoked.'
When a person lacks a role, the server refuses the action with 'This needs the platform role 'Release manager'.' naming the role.
Keep roles separate. The person who creates a release should not be the only person who holds the approver role, because approvals by the preparer are refused anyway.
The audit trail
Open Platform > Configuration > Audit trail to see every platform command: when, who, the record, the action and a correlation id. Search by action, person, correlation or id, and filter by record or action. The same correlation id is returned to the browser in the X-Request-ID response header and appears in alerts and run records, so you can follow one action across screens.
For a release you will see, in order, actions such as release.submit, release.stage and release.approve, and release.reject for a send back. Use the list tools to export.
Reports
All reports are under Platform > Reporting and open the underlying record when you click a row. They share the standard list tools for search, filter and export.
| Report | What it shows |
|---|---|
| Release readiness | One row per release and package: environment, state, package version, dependencies, risk, gates failing, digest, and Traced to gate. It reconciles that deployed artifacts trace to an approved, signed gate. |
| Job health | Per job, accepted runs split by state, the oldest queued run and whether the parts reconcile. |
| Recovery evidence | Every drill with rows, file digests, ledger totals, RTO and RPO. See Run restore drills. |
| Capabilities | For any company member: the company's installed apps, what each does, the package and reviewed version, and Certified or Reviewed. The line at the bottom shows the server tier, core version and whether the schema is up to date. It never shows host names or secrets. |
Health probes
Two anonymous endpoints report only yes or no values: live and ready. Ready answers 503 when the database, schema or jobs are not ready. They never expose server details.
Good to know
- A company member sees only their own company's capabilities.
- On a staging copy, outgoing email and webhooks are switched off unless
A2N_STAGING_OUTBOUND=1is set for the server; a message such as 'This is a staging copy: outgoing ... is switched off' is shown if something tries to send. - The Viewer / auditor role reads everything and can export, but the buttons that change anything are refused.