When someone from the team behind Pyron signs in to your organisation to help, they act under a shared support identity, and everything they do is recorded. The internal audit view shows the same events as the audit trail, with the real person behind each one named alongside.
What extra it shows
The view lists the actions taken under support access, one event per row. Each row carries what you would see in the audit trail — the time, the shared support identity your organisation sees, the action, the object it touched, and the source address the request came from. It adds the detail the trail holds back: the individual member of the platform team who was signed in, and their email address — on what they looked at as well as on what they changed. It also shows when each support session started and ended, and who held it.
Search accesses finds events by the object they touched or the identity that acted, across the whole history rather than the rows already on screen. Select an event — or choose Open from its ⋯ menu — to see it in full, with the fields it changed.
That personal attribution is the point of the view. In the audit trail your organisation reads, support work appears under one shared identity; here, each event traces back to a named person, so the platform team can always say who looked at your organisation's data. What a session looked at before 21 October 2026 is recorded under the shared support identity only.
When no one from the platform team has signed in to your organisation, the view stays empty and says so.
Attribution covers the actions a support session takes directly. When one of those actions starts an automation or an AI assistant task, the follow-on work is attributed to the system rather than to the support session — so this view is not a complete trace of everything a session set in motion.
Why it is separate
Both views draw on the same history, and they are kept apart deliberately. The audit trail your organisation reads shows support work under a single shared identity and leaves out the personal details of the platform staff behind it. The internal audit view is the only place those names and email addresses appear.
The split protects both sides. An administrator in your organisation runs the Setup area — roles, security, and the audit trail — without ever seeing a support staff member's personal details. The platform team, in turn, keeps a complete, named account of its own access to your data: who looked at what, and who changed what.
Because it exposes those identities, the view is walled off to the platform team itself: it opens only for platform staff signed in with Google, and no role inside your organisation — however senior — can reach it.