--- title: Audit – Provider description: "## 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…" url: "https://www.learningbydoingxr.com/it/help/audit-provider/" updated: "2026-06-23" category: Provider --- # Audit – Provider ## 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 ![](https://www.learningbydoingxr.com/wp-content/uploads/2026/06/provider-audit1-it-1024x212.png) 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 ![](https://www.learningbydoingxr.com/wp-content/uploads/2026/06/provider-audit2-it-1024x557.png) 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 ![](https://www.learningbydoingxr.com/wp-content/uploads/2026/06/provider-audit3-it.png) 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: 1. il Provider avvia un test interno; 2. il sistema crea la sessione interna; 3. il sistema attiva la runtime; 4. 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: 1. controllare la colonna **Ora** per capire quando è avvenuto; 2. controllare la colonna **Azione** per capire cosa è successo; 3. verificare il **Tenant** coinvolto, se presente; 4. leggere l’**Attore** per capire se l’evento è stato generato da un utente o dal sistema; 5. controllare l’**Entità** per identificare l’oggetto coinvolto; 6. aprire **Visualizza JSON** solo se servono dettagli tecnici. --- ## Buone pratiche Per usare correttamente la sezione Audit Provider, è consigliabile: 1. usare i filtri data per restringere il periodo; 2. filtrare per tenant quando si analizza un ambiente specifico; 3. usare “Azione contiene” per cercare eventi noti; 4. non interpretare gli eventi system come azioni manuali dirette; 5. aprire i metadati JSON solo quando serve un controllo tecnico; 6. usare l’Audit insieme alle sezioni Report e Piano e Risorse per ricostruire problemi di utilizzo o consumo; 7. 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.