Internal audit

When someone from the platform team behind Pyron signs in to your organisation to help, they do so under a shared support identity, and every action they take is logged. The internal audit view is where a platform superuser sees that access in full: the same events as the audit trail, with the real person behind each action named alongside.

What extra it shows

The view lists the actions taken under support access, one event per row. Each event carries the details you would find in the audit trail — when it happened, the support identity your organisation sees, the action, the object it touched, and the source address the request came from. It adds what the trail leaves out: the individual member of the platform team who was signed in, together with their email address.

That personal attribution is the difference. In the audit trail your organisation reads, support work appears under a single shared identity; here, each event ties back to a named person.

When no one from the platform team has signed in to your organisation, the view stays empty and tells you so.

Why it is separate

Both views draw on the same history, and they are kept apart on purpose. The audit trail your organisation reads shows support work under one 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 manages the Setup area — roles, security, the audit trail — without seeing a platform staff member's personal details. The platform, in turn, keeps a complete, named account of its own access into your data. Because it holds those details, the internal audit view opens only for a platform superuser.