A cosa serve questa sezione #
La sezione Audit permette al Tenant Admin di consultare lo storico degli eventi registrati dal sistema per il tenant.
Questa pagina serve a garantire tracciabilità sulle principali operazioni eseguite nella piattaforma, come creazione, pubblicazione, attivazione o modifica di simulazioni, runtime, risorse e configurazioni.
L’Audit non è una sezione operativa per modificare dati: è una vista di controllo e verifica.
Può essere utile per:
- controllare quando è stata creata una simulazione;
- verificare quando una simulazione è stata inviata in revisione;
- vedere quando una simulazione è stata pubblicata;
- controllare quando è stata creata o attivata una runtime;
- verificare aggiornamenti o allocazioni di risorse;
- ricostruire la sequenza delle azioni avvenute nel tenant;
- supportare attività di troubleshooting o verifica amministrativa.
Elenco eventi di audit #
La pagina mostra l’elenco degli eventi registrati.
In alto viene indicato il numero di eventi mostrati rispetto al totale disponibile.
Esempio:
Mostrando 1-50 di 401 eventi
Questo significa che la pagina sta mostrando i primi 50 eventi su un totale di 401 eventi registrati.
Colonne della tabella #
La tabella degli eventi di audit è composta da diverse colonne.
Ora #
La colonna Ora mostra la data e l’ora in cui l’evento è stato registrato.
Esempio:
11/06/2026, 13:23:45
Questa informazione permette di ricostruire la sequenza temporale delle azioni.
Ambito #
La colonna Ambito indica l’area funzionale a cui appartiene l’evento.
Esempio:
Business
L’ambito aiuta a capire in quale parte della piattaforma è avvenuta l’azione.
Provider #
La colonna Provider mostra l’identificativo tecnico del Provider collegato all’evento.
Questo valore è utile per distinguere a quale Provider appartiene il tenant, soprattutto in ambienti multi-tenant o white label.
L’identificativo è tecnico e normalmente non deve essere modificato o interpretato dall’utente finale.
Tenant #
La colonna Tenant mostra l’identificativo tecnico del tenant interessato dall’evento.
Questo valore permette di collegare l’evento al tenant corretto.
Anche in questo caso si tratta di un ID tecnico, utile soprattutto per controlli amministrativi o supporto tecnico.
Attore #
La colonna Attore indica chi ha generato l’evento.
Può essere:
- un utente;
- un amministratore;
- un processo automatico del sistema.
Quando viene mostrato system, significa che l’evento è stato generato automaticamente dalla piattaforma.
Esempio:
system
Questo può accadere durante processi automatici come pubblicazioni, attivazioni, rebuild di configurazioni o allocazioni di risorse.
Azione #
La colonna Azione descrive il tipo di evento registrato.
Esempi di azioni:
- tenant_entitlements_allocated
- runtime_simulation.create
- intent_runtime_capability.simulation_rebuild
- runtime_simulation.activate
- simulation_published
- submitted_for_review
Questa colonna è la più importante per capire cosa è successo.
Entità #
La colonna Entità mostra l’oggetto tecnico collegato all’evento.
Esempi:
- tenant_entitlements
- runtime_simulation
- simulation
Accanto al tipo di entità può essere mostrato anche l’ID tecnico dell’oggetto.
Esempio:
runtime_simulation:7a3400b6-15f1-476a-9cc8-26ce972e001d
Questo permette di collegare l’evento a una specifica simulazione, runtime o configurazione.
Esempi di eventi #
tenant_entitlements_allocated #
Indica che sono state allocate o aggiornate risorse e limiti per il tenant.
Può riguardare elementi come:
- minuti;
- utenti;
- runtime attive;
- capacità assegnate;
- limiti configurati.
runtime_simulation.create #
Indica che è stata creata una simulazione runtime.
Una runtime rappresenta l’accesso operativo a una simulazione pubblicata, configurato con canale, lingua, voce, avatar, Player autorizzati e policy di accesso.
runtime_simulation.activate #
Indica che una runtime è stata attivata.
Una runtime attiva può diventare disponibile ai Player se rispetta anche le condizioni di pubblicazione, allowlist, date e policy di accesso.
intent_runtime_capability.simulation_rebuild #
Indica che il sistema ha ricostruito o aggiornato le capacità operative collegate alla simulazione runtime.
Questo tipo di evento può essere generato automaticamente quando il sistema prepara o aggiorna le configurazioni necessarie all’esecuzione della simulazione.
submitted_for_review #
Indica che una simulazione è stata inviata in revisione.
Questo evento fa parte del flusso di approvazione prima della pubblicazione.
simulation_published #
Indica che una simulazione guidata è stata pubblicata.
La pubblicazione rende la simulazione disponibile come contenuto nella libreria del tenant.
Importante: una simulazione pubblicata non è automaticamente accessibile ai Player. Per renderla disponibile ai partecipanti è necessario creare una simulazione runtime o accesso Player dedicato.
Come leggere correttamente l’audit #
L’audit va letto come una cronologia tecnica delle operazioni.
Per ricostruire cosa è accaduto, è utile seguire questi passaggi:
- partire dalla colonna Ora per ordinare gli eventi nel tempo;
- leggere la colonna Azione per capire cosa è successo;
- controllare la colonna Entità per identificare l’oggetto coinvolto;
- verificare l’Attore per capire se l’azione è stata eseguita da un utente o dal sistema;
- usare Provider e Tenant per confermare il contesto amministrativo corretto.
Differenza tra eventi utente ed eventi di sistema #
Non tutti gli eventi derivano da un’azione manuale dell’utente.
Alcuni eventi sono generati automaticamente dalla piattaforma.
Esempio:
- un utente invia una simulazione in revisione;
- il sistema registra l’evento;
- dopo la pubblicazione, il sistema può eseguire attività automatiche di rebuild o attivazione;
- questi eventi appaiono nell’audit con attore system.
Questa distinzione è importante per non confondere le azioni manuali con i processi automatici interni.
Quando usare questa sezione #
È consigliabile consultare la sezione Audit quando:
- una simulazione risulta pubblicata ma si vuole verificare quando è stata pubblicata;
- una runtime è stata creata o attivata e si vuole controllare la sequenza degli eventi;
- si vuole capire se una modifica è stata registrata correttamente;
- si sta analizzando un problema operativo;
- si vuole controllare l’allocazione delle risorse del tenant;
- serve una traccia amministrativa delle attività svolte.
Cosa non mostra l’Audit #
La sezione Audit non è pensata per mostrare contenuti formativi o report dei Player.
Normalmente non contiene:
- trascrizioni delle conversazioni;
- valutazioni dettagliate dei Player;
- contenuti completi delle simulazioni;
- report leggibili;
- dati narrativi estesi.
Per analizzare risultati e performance bisogna usare la sezione Reports.
Per modificare simulazioni, runtime o risorse bisogna usare le rispettive sezioni operative della piattaforma.
Buone pratiche #
Per usare correttamente l’Audit, è consigliabile:
- leggere gli eventi in ordine cronologico;
- concentrarsi sulla colonna Azione per capire il tipo di evento;
- usare la colonna Entità per collegare l’evento all’oggetto corretto;
- considerare gli eventi con attore system come operazioni automatiche della piattaforma;
- usare gli ID tecnici solo per verifica o supporto;
- non interpretare l’audit come report formativo;
- consultare l’audit in caso di dubbi su pubblicazioni, attivazioni o modifiche recenti.
Risultato finale #
La sezione Audit offre al Tenant Admin una vista cronologica e tracciabile delle principali attività registrate nel tenant.
Permette di verificare cosa è successo, quando è successo, quale oggetto è stato coinvolto e se l’azione è stata eseguita da un utente o dal sistema.
È uno strumento utile per controllo amministrativo, trasparenza operativa e supporto nella risoluzione di eventuali problemi.
