--- title: Audit – Tenant Admin description: "## What this section is for The **Audit** section allows the Tenant Admin to consult the history of events recorded by the system for the tenant. This page serves to ensure traceability of the main operations performed on the platform,…" url: "https://www.learningbydoingxr.com/help/audit-tenant-admin/" updated: "2026-06-23" category: Tenant Admin --- # Audit – Tenant Admin ## What this section is for The **Audit** section allows the Tenant Admin to consult the history of events recorded by the system for the tenant. This page serves to ensure traceability of the main operations performed on the platform, such as the creation, publication, activation, or modification of simulations, runtimes, resources, and configurations. Audit is not an operational section for modifying data: it is a control and verification view. It can be useful for: - checking when a simulation was created; - verifying when a simulation was submitted for review; - seeing when a simulation was published; - checking when a runtime was created or activated; - verifying resource updates or allocations; - reconstructing the sequence of actions that occurred in the tenant; - supporting troubleshooting activities or administrative verification. --- ## Audit event list ![](https://www.learningbydoingxr.com/wp-content/uploads/2026/06/audit-tenant-it-1024x618.webp) The page shows the list of recorded events. The number of events shown relative to the total available is indicated at the top. Example: **Showing 1-50 of 401 events** This means that the page is showing the first 50 events out of a total of 401 recorded events. --- ## Table columns The audit events table consists of several columns. --- ### Time The **Time** column shows the date and time the event was recorded. Example: **11/06/2026, 13:23:45** This information allows for the reconstruction of the chronological sequence of actions. --- ### Scope The **Scope** column indicates the functional area to which the event belongs. Example: **Business** The scope helps to understand in which part of the platform the action took place. --- ### Provider The **Provider** column shows the technical identifier of the Provider linked to the event. This value is useful for distinguishing which Provider the tenant belongs to, especially in multi-tenant or white-label environments. The identifier is technical and normally should not be modified or interpreted by the end user. --- ### Tenant The **Tenant** column shows the technical identifier of the tenant affected by the event. This value allows the event to be linked to the correct tenant. In this case as well, it is a technical ID, useful primarily for administrative checks or technical support. --- ### Actor The **Actor** column indicates who generated the event. It can be: - a user; - an administrator; - an automated system process. When **system** is shown, it means the event was automatically generated by the platform. Example: **system** This can happen during automated processes such as publications, activations, configuration rebuilds, or resource allocations. --- ### Action The **Action** column describes the type of event recorded. Examples of actions: - **tenant_entitlements_allocated** - **runtime_simulation.create** - **intent_runtime_capability.simulation_rebuild** - **runtime_simulation.activate** - **simulation_published** - **submitted_for_review** This column is the most important for understanding what happened. --- ### Entity The **Entity** column shows the technical object linked to the event. Examples: - tenant_entitlements - runtime_simulation - simulation Next to the entity type, the technical ID of the object may also be shown. Example: **runtime_simulation:7a3400b6-15f1-476a-9cc8-26ce972e001d** This allows the event to be linked to a specific simulation, runtime, or configuration. --- ## Examples of events ### tenant_entitlements_allocated Indicates that resources and limits for the tenant have been allocated or updated. It may concern elements such as: - minutes; - users; - active runtimes; - assigned capacities; - configured limits. --- ### runtime_simulation.create Indicates that a runtime simulation has been created. A runtime represents operational access to a published simulation, configured with channel, language, voice, avatar, authorized Players, and access policies. --- ### runtime_simulation.activate Indicates that a runtime has been activated. An active runtime can become available to Players if it also meets the conditions for publication, allowlist, dates, and access policies. --- ### intent_runtime_capability.simulation_rebuild Indicates that the system has rebuilt or updated the operational capabilities linked to the runtime simulation. This type of event can be generated automatically when the system prepares or updates the configurations necessary for the simulation's execution. --- ### submitted_for_review Indicates that a simulation has been submitted for review. This event is part of the approval flow prior to publication. --- ### simulation_published Indicates that a guided simulation has been published. Publication makes the simulation available as content in the tenant's library. Important: a published simulation is not automatically accessible to Players. To make it available to participants, it is necessary to create a runtime simulation or dedicated Player access. --- ## How to read the audit correctly The audit should be read as a technical chronology of operations. To reconstruct what happened, it is useful to follow these steps: 1. start from the **Time** column to sort events chronologically; 2. read the **Action** column to understand what happened; 3. check the **Entity** column to identify the object involved; 4. verify the **Actor** to understand if the action was performed by a user or by the system; 5. use Provider and Tenant to confirm the correct administrative context. --- ## Difference between user events and system events Not all events derive from a manual user action. Some events are automatically generated by the platform. Example: - a user submits a simulation for review; - the system records the event; - after publication, the system may perform automatic rebuild or activation activities; - these events appear in the audit with the actor **system**. This distinction is important so as not to confuse manual actions with internal automatic processes. --- # When to use this section It is advisable to consult the Audit section when: - a simulation appears published but you want to verify when it was published; - a runtime has been created or activated and you want to check the sequence of events; - you want to understand if a change was correctly recorded; - you are analyzing an operational problem; - you want to check the allocation of tenant resources; - an administrative trace of the activities performed is needed. --- # What the Audit does not show The Audit section is not intended to show training content or Player reports. Normally it does not contain: - transcriptions of conversations; - detailed Player evaluations; - full simulation content; - readable reports; - extended narrative data. To analyze results and performance, you must use the **Reports** section. To modify simulations, runtimes, or resources, you must use the respective operational sections of the platform. --- # Best practices To use the Audit correctly, it is advisable to: 1. read events in chronological order; 2. focus on the **Action** column to understand the type of event; 3. use the **Entity** column to link the event to the correct object; 4. consider events with the actor **system** as automatic platform operations; 5. use technical IDs only for verification or support; 6. do not interpret the audit as a training report; 7. consult the audit in case of doubts about recent publications, activations, or modifications. --- # Final result The **Audit** section offers the Tenant Admin a chronological and traceable view of the main activities recorded in the tenant. It allows you to verify what happened, when it happened, which object was involved, and whether the action was performed by a user or by the system. It is a useful tool for administrative control, operational transparency, and support in resolving any issues.