Platform activity
What this screen is for
Platform activity shows what the platform's operators changed on your tenant, and when they read your tenant's audit trail. It applies on every deployment type. Both lists are read-only and show the newest first.
What must exist first
Nothing needs to be configured. Open Platform Activity under Monitoring & audit. Each section is shown only to a person who holds its permission:
- Actions by the platform needs a permission to read the tenant's administrative audit trail.
- Reads of this tenant's audit trail needs the permission to read the audit-access log, which the tenant administrator and tenant auditor roles hold.
A platform administrator working inside your tenant sees the same sections through the platform audit permissions. Without either permission the screen says that your role does not include reading the platform's activity on this tenant.
Decisions you make here
Actions by the platform
This section lists the changes a platform operator made to your tenant: its status and closure, its key backend and key backend edition, its notification providers, its observability backend and observability export entitlement, its email domains and integration settings, its administrative workloads and their keys, its trusted issuers, and the federated identities of its workloads and Actors.
The platform does not disclose which operator acted. Not every platform step appears here: an internal step of a key custody move, for example, is not listed. Use Show to narrow the list to one of those types, or Everything.
Each row gives When, Action (Created, Changed or Deleted), Acted on and Outcome (Succeeded, Failed or Denied). The operator always reads Platform operator.
A row shows the attributes of what changed: for example the Status, the Assigned edition, the Backend type, the Destination backend of a custody move, the KEK version, or the Domain and whether it is Verified. A trusted issuer row shows its Issuer; a binding row shows the Issuer, the Subject and the Actor.
A key-encryption key destruction row reads Key encryption key destruction requested or Key encryption key destruction scheduled, with its Reason and, when a platform quorum approved it, the number of approvals, never who approved.
- When a record does not match its signature, or cannot be checked against it, its details are not shown and the reason is stated. The action itself is still listed.
- A value longer than 2048 characters is shortened, and the row says so.
Reads of this tenant's audit trail
This section lists each time a platform operator read your tenant's audit trail, refused reads included. Each row shows When, Operator, Records returned and Outcome.
- On a deployment your organization operates, the operator is named by login. When the read ran inside a support session, it is the login of the operator who opened the session.
- On a deployment ANKATech operates, or for a platform token that carries no tenant, the operator reads Platform operator with a Reference: a stable identifier of the operator's platform identity, which ANKATech support can resolve.
- A record that does not match its signature shows an unknown outcome and says why.
A read that names no tenant is not attributed to any tenant, so it is not listed here: the platform-wide audit reads, the platform event feed and its export, and correlation lookups. Platform auditors and super administrators can read your trail that way too.
How it relates to other screens
Your tenant's own trail. Changes a platform operator makes on your tenant's workloads and federated identities are listed on this screen instead:
An Actor's federated identities panel points here for the bindings the platform made:
The support sessions a platform operator can open on your tenant, and the grant that admits them: