Skip to content

Reading the audit trail

Who did what and when across the organisation, the separate trail of your own account security events, and the two things deliberately left out of both.

Updated

The audit trail records who did what, to which record, and when. It is the system of record for governed actions, and it is never pruned.

There are two trails on the page and they are deliberately separate. The organisation trail belongs to the organisation and needs the export permission to read. Your account security events belong to you: two-factor changes, device sessions and credentials. Those are listed for you alone and are not part of the organisation trail or its export.

Two things are left out on purpose. Diagnostic context is never returned, because it is supplied by whatever wrote the entry and may contain personal or third-party data. And internal user identifiers are never returned; an actor is named by their public identifier or not at all.

BEFORE YOU START

  • The "export" permission for the organisation trail. Four roles carry it: owner, organisation admin, billing admin and analyst.
  • Active membership of the organisation.
  • Nothing extra for your own security events, which need no permission.

STEPS

  1. Open Audit, or go to /app/audit for your organisation.
  2. Read the organisation trail: the action, who did it, the record it touched, and when.
  3. Filter by action to narrow it, and set a date range if you need one.
  4. Page through with Previous and Next. A page holds at most two hundred entries.
  5. Read your own account security events underneath.
  6. Where you need the data outside the product, call the audit endpoint with a token that carries the export permission.

WHAT YOU SHOULD SEE

Entries in reverse order with a named actor, or no actor where the action was taken by the system rather than a person.

WHAT THIS WILL NOT DO

  • It will not download a file. There is no export button. The export permission gates a paginated interface you can call yourself.
  • It will not show diagnostic context.
  • It will not name who took one of your own security events. Your personal trail describes the actor as a category: you, support staff, another account, or the system.
  • It will not delete anything. There is no retention window and nothing prunes it.
  • It will not exist on your phone. There is no mobile audit screen.

WORTH KNOWING

The request log on the developer page is a different thing and should not be mistaken for this. That log is a bounded operational aid kept for thirty days; this trail is the record.

IF IT DOES NOT WORK

  • "export permission required." is the refusal. The page adds that an organisation owner, admin, billing admin or analyst can export it, or grant you the permission.
  • "Your audit trail could not be loaded. Try again." means the request failed rather than that there is nothing.
  • "No audit entries match." means your filter found nothing.
  • "Showing your 100 most recent account events. Older ones are retained but not listed here." Older personal events still exist; the page just stops at a hundred.

COMMON QUESTIONS

How far back does it go?

To the beginning. Nothing removes audit entries.

Why can an analyst read it?

Because export is the permission that governs taking organisational data out, and the trail is organisational data.

  • Securing your account

    Turning on two-factor authentication, keeping recovery codes, ending browser sessions and revoking credentials, and what the step-up check is for.

  • Inviting your team

    Creating an invitation link, choosing from the fourteen roles and what each one can do, how seats are counted, and what the team page cannot do.

  • Using the developer API

    Minting an API token with read and write scopes, what the ninety-day lifetime means, where the OpenAPI contract lives, and what the request log does and does not record.