A cosa serve questa sezione #
La sezione Audit permette al Provider di consultare lo storico degli eventi registrati dalla piattaforma per il proprio ambiente Provider e per i tenant collegati.
Questa sezione serve a garantire tracciabilità sulle principali azioni operative, amministrative e di sistema.
L’Audit non è una sezione per modificare dati, ma una vista di controllo che permette di verificare:
- quando è stata eseguita un’azione;
- quale tenant è coinvolto;
- quale entità è stata modificata o generata;
- se l’azione è stata eseguita da un utente o dal sistema;
- quali metadati tecnici sono collegati all’evento.
È utile soprattutto per attività di controllo, troubleshooting, supporto tecnico e governance operativa.
Accesso alla sezione #
Dal menu Provider, selezionare la voce Audit.
La pagina mostra il titolo:
Audit
con la descrizione:
Rivedi l’attività di audit per il tuo provider e tenant.
Questo significa che il Provider può consultare eventi relativi sia al proprio livello Provider sia ai tenant che appartengono al suo perimetro.
Filtri disponibili #
La parte superiore della pagina contiene i filtri che permettono di restringere la ricerca degli eventi.
Ambito #
Il filtro Ambito permette di selezionare l’area funzionale degli eventi.
Esempio:
Tutti
oppure eventi appartenenti a un ambito specifico, come Business.
L’ambito aiuta a distinguere la tipologia generale dell’evento registrato.
Tenant #
Il filtro Tenant permette di visualizzare:
- eventi di tutti i tenant;
- eventi relativi a un tenant specifico.
È utile quando il Provider vuole analizzare cosa è accaduto all’interno di un singolo tenant.
Azione contiene #
Il campo Azione contiene permette di cercare eventi in base a una parte del nome dell’azione.
Esempio:
tenant.update_feature_flag
oppure:
provider_simulation
Questo filtro è utile quando si conosce il tipo di evento da cercare.
Cerca #
Il campo Cerca permette di cercare per azione, entità o metadati.
Può essere usato per trovare rapidamente eventi collegati a:
- una simulazione;
- una runtime;
- un tenant;
- un’azione specifica;
- un identificativo tecnico.
Data da / Data a #
I campi Data da e Data a permettono di filtrare gli eventi per intervallo temporale.
Questa funzione è utile per ricostruire cosa è accaduto in un periodo preciso, ad esempio durante:
- una pubblicazione;
- un test interno;
- una modifica di risorse;
- una distribuzione verso tenant;
- un problema operativo.
Tabella eventi audit #
La tabella mostra gli eventi registrati.
Le colonne principali sono:
Ora #
Mostra la data e l’ora in cui l’evento è stato registrato.
Esempio:
18/06/2026, 15:59:22
Questa colonna permette di ricostruire la sequenza temporale delle azioni.
Ambito #
Mostra l’ambito funzionale dell’evento.
Esempio:
Business
L’ambito aiuta a classificare il tipo di attività registrata.
Provider #
Mostra l’identificativo tecnico del Provider a cui l’evento appartiene.
Questo ID è utile per verifiche amministrative o supporto tecnico.
Tenant #
Mostra il tenant coinvolto nell’evento.
Può essere:
- il nome del tenant;
- un ID tecnico;
- un valore vuoto o non disponibile, quando l’evento riguarda solo il Provider o un test interno Provider.
Attore #
Mostra chi ha generato l’evento.
Può essere:
- un utente;
- un amministratore;
- il sistema.
Quando compare system, significa che l’evento è stato generato automaticamente dalla piattaforma.
Esempi di eventi generati dal sistema possono essere:
- rebuild;
- attivazioni automatiche;
- allocazioni;
- generazione di runtime;
- completamento di processi interni.
Azione #
La colonna Azione descrive cosa è accaduto.
Esempi:
- tenant_entitlements_allocated
- provider_internal_test_runtime_activate
- stimulus_simulation_internal_test_created
- provider_simulation_published
- provider_simulation_approved
- provider_simulation_syscheck
- provider_simulation_unpublished
Questa è la colonna più importante per capire il tipo di evento registrato.
Entità #
La colonna Entità mostra l’oggetto tecnico collegato all’evento.
Può essere, ad esempio:
- tenant_entitlements;
- runtime_simulation;
- simulation.
Accanto al tipo di entità può essere mostrato anche l’ID tecnico dell’oggetto.
Questa informazione permette di collegare l’evento a una risorsa specifica della piattaforma.
Visualizza JSON #
Il pulsante Visualizza JSON apre i metadati tecnici dell’evento.
Questi dati sono utili soprattutto per supporto tecnico, debugging o verifica avanzata.
Metadati audit JSON #
Cliccando su Visualizza JSON, si apre una finestra con i Metadati audit.
Questa finestra mostra informazioni tecniche in formato JSON.
I metadati possono includere, ad esempio:
- dati sintetici sull’evento;
- conteggi interni;
- scope dell’evento;
- URL o hash di manifest;
- ambito di fatturazione;
- ambito di capacità;
- contesto runtime;
- ID della simulazione sorgente;
- ID della simulazione Provider;
- informazioni utili alla ricostruzione tecnica dell’evento.
A cosa servono i metadati JSON #
I metadati JSON servono a ricostruire con precisione cosa è accaduto dietro le quinte.
Sono utili quando bisogna verificare:
- quale manifest è stato generato;
- quale simulazione ha prodotto una runtime;
- se un test interno ha consumato risorse Provider;
- quale scope di billing è stato applicato;
- quale capacità è stata usata;
- se un evento è collegato a una simulazione Provider o a un tenant;
- se il sistema ha registrato correttamente un’azione automatica.
Normalmente questi dati non devono essere modificati o interpretati dall’utente finale.
Sono pensati soprattutto per analisi tecnica e supporto.
Esempi di eventi audit Provider #
tenant_entitlements_allocated #
Indica che sono state allocate o aggiornate risorse per un tenant.
Può riguardare:
- minuti assegnati;
- utenti assegnati;
- runtime assegnate;
- limiti;
- overage;
- configurazioni di entitlement.
provider_simulation_syscheck #
Indica che è stato avviato o registrato un controllo SysCheck su una simulazione Provider.
Serve a tracciare la verifica tecnica della simulazione prima di approvazione o pubblicazione.
provider_simulation_approved #
Indica che una simulazione Provider è stata approvata.
Dopo l’approvazione, la simulazione può proseguire verso la pubblicazione, se non ci sono altri vincoli.
provider_simulation_published #
Indica che una simulazione Provider è stata pubblicata.
Una simulazione Provider pubblicata può essere distribuita verso uno o più tenant dello stesso Provider.
provider_simulation_unpublished #
Indica che la pubblicazione di una simulazione Provider è stata annullata.
Questo evento può comparire quando una simulazione deve essere corretta, aggiornata o temporaneamente rimossa dalla distribuzione.
stimulus_simulation_internal_test_created #
Indica che è stata creata una sessione di test interno collegata a una simulazione.
Questo evento è utile per tracciare quando il Provider ha preparato un test interno.
provider_internal_test_runtime_activate #
Indica che una runtime di test interno Provider è stata attivata.
Questo evento può essere collegato al consumo di minuti Provider e all’occupazione di uno slot condiviso durante il test.
Differenza tra eventi manuali ed eventi di sistema #
Non tutti gli eventi presenti nell’Audit derivano da un click diretto dell’utente.
Alcuni eventi sono generati automaticamente dalla piattaforma come conseguenza di un’azione precedente.
Esempio:
- il Provider avvia un test interno;
- il sistema crea la sessione interna;
- il sistema attiva la runtime;
- il sistema registra eventi audit collegati.
In questo caso, alcuni eventi possono apparire con attore system, anche se il processo è stato originato da un’azione del Provider.
Quando usare l’Audit Provider #
È utile consultare la sezione Audit quando:
- si vuole verificare se una simulazione Provider è stata approvata;
- si vuole controllare quando una simulazione è stata pubblicata;
- si vuole capire quando è stato avviato un SysCheck;
- si vuole verificare la creazione di un internal test;
- si vuole controllare se una runtime interna ha consumato risorse;
- si vuole ricostruire una sequenza di eventi;
- si vuole verificare una modifica sulle risorse di un tenant;
- si sta analizzando un problema operativo;
- il supporto tecnico richiede un ID evento, entità o metadato.
Cosa non mostra l’Audit Provider #
L’Audit Provider non è una reportistica formativa.
Normalmente non mostra:
- readiness dei Player;
- Skill Comunicative raggiunte;
- report individuali;
- trascrizioni;
- momenti chiave;
- performance dei Player;
- valutazioni della Griglia di Osservazione.
Per questi dati bisogna usare le sezioni Report dedicate, rispettando le policy privacy configurate.
Come leggere correttamente l’audit #
Per interpretare correttamente un evento audit:
- controllare la colonna Ora per capire quando è avvenuto;
- controllare la colonna Azione per capire cosa è successo;
- verificare il Tenant coinvolto, se presente;
- leggere l’Attore per capire se l’evento è stato generato da un utente o dal sistema;
- controllare l’Entità per identificare l’oggetto coinvolto;
- aprire Visualizza JSON solo se servono dettagli tecnici.
Buone pratiche #
Per usare correttamente la sezione Audit Provider, è consigliabile:
- usare i filtri data per restringere il periodo;
- filtrare per tenant quando si analizza un ambiente specifico;
- usare “Azione contiene” per cercare eventi noti;
- non interpretare gli eventi system come azioni manuali dirette;
- aprire i metadati JSON solo quando serve un controllo tecnico;
- usare l’Audit insieme alle sezioni Report e Piano e Risorse per ricostruire problemi di utilizzo o consumo;
- non usare l’Audit come strumento di valutazione formativa dei Player.
Risultato finale #
La sezione Audit Provider offre una vista cronologica e tecnica delle attività registrate nel perimetro del Provider e dei suoi tenant.
Permette di controllare cosa è successo, quando è successo, quale entità è stata coinvolta e se l’azione è stata eseguita da un utente o dal sistema.
È uno strumento di governance, tracciabilità e supporto operativo, utile per ricostruire eventi e verificare il corretto funzionamento dei processi della piattaforma.
