Dove si accende: una sola configurazione per environment

Le conversation diagnostics registrano ogni evento del ciclo di vita di una conversazione e li spingono fuori da Dataverse, dentro un’istanza di Azure Application Insights. La configurazione però non si fa dove ci si aspetterebbe, cioè nel Copilot Service admin center: si fa nel Power Platform admin center, sotto Manage > Data export, scheda App Insights, con il comando New data export. La procedura guidata chiede il Name of the export package, la sorgente dati, l’environment e infine Subscription, Resource group e l’istanza di Application Insights di destinazione. Una nota utile: la sorgente da selezionare si chiama Dynamics Customer Service, e la pipeline di diagnostica che ne esce è documentata per entrambi i prodotti, Dynamics 365 Customer Service e Dynamics 365 Contact Center.

I prerequisiti stanno a cavallo di due piattaforme, ed è la prima cosa da fissare. Sul lato Azure serve un accesso Contributor o superiore per eseguire il setup, e almeno il permesso Read per interrogare poi i dati. Sul lato Power Platform serve il ruolo Power Platform administrator oppure System Administrator per operazioni come l’esportazione, e l’environment deve essere un Managed environment. La documentazione segnala inoltre che l’esportazione non è disponibile nei cloud sovrani, quindi GCC, GCC High e DoD.

Il vincolo da mandare a memoria è però un altro, ed è secco: “You can create only one data export configuration from Customer Service to Application Insights per environment”. Una sola, per environment. Se un secondo team vuole gli stessi eventi non crea una seconda esportazione verso una propria istanza: deve farsi dare accesso all’istanza di Application Insights già collegata. È esattamente la forma di vincolo su cui un esame costruisce una domanda di scenario, con il distrattore plausibile — “configura un secondo data export” — messo lì apposta.

Che cosa arriva, e in quale tabella

Dopo il routing di un work item i dati compaiono in Application Insights entro circa 15 minuti. Non finiscono in una tabella dedicata: finiscono nella tabella Traces, e la struttura vera vive dentro customDimensions, che va deserializzato con parse_json prima di poterci filtrare sopra. Vale per le conversazioni di live chat, digital messaging, voice e canali custom.

I campi che contano sono pochi e ricorrenti. powerplatform.analytics.resource.id porta l’ID della conversazione, powerplatform.analytics.scenario vale ConversationDiagnosticsScenario, e powerplatform.analytics.subscenario è il vero discriminante, perché nomina l’evento. I sottoscenari sono decine, raggruppati per area: ingresso e routing (Intake, Classification, RouteToQueue, CSRAssignment), esito dell’offerta al representative, cioè all’operatore umano (CSRAccepted, CSRRejected, CSRNotificationTimeout), chiusura, trasferimenti e consulti, azioni del supervisore (SupervisorMonitor, SupervisorJoin) e gli eventi degli agent, gli agenti AI (BotSessionInitialization, BotTransferToAgent, CopilotAgentEscalationToCSR).

Accanto ai metadati comuni — channel type, org ID, resource ID, scenario, subscenario, duration, workstream ID, timestamp — stanno i payload ricchi: omnichannel.result con la coda finale, omnichannel.additional_info con l’esito regola per regola, omnichannel.work_item.details con capacity richiesta, presence ammesse e skill, omnichannel.assignment.status con i dettagli del representative valutato. C’è poi l’assignment snapshot, che sincronizza a parte la configurazione statica nei sottoscenari CSRConfiguration, QueueConfiguration, AssignmentRuleset e CSRStatusandCapacityDetails: serve proprio a rispondere alla domanda “perché quel representative non è stato scelto”, confrontando lo stato al momento del tentativo.

Interrogare la telemetria e incorporarla

La query di partenza è quella della documentazione: si parte da Traces, si espande customDimensions, si estraggono work item e sottoscenario, si filtra sull’ID conversazione.

Traces
| extend customDim = parse_json(customDimensions)
| extend workItem = tostring(customDim["powerplatform.analytics.resource.id"])
| extend subscenario = tostring(customDim["powerplatform.analytics.subscenario"])
| where workItem == "Insert conversation ID of work item"
| project timestamp, workItem, subscenario, customDim

Da qui si costruiscono le indagini tipiche: work item finiti in una fallback queue, conversazioni che hanno innescato overflow, representative con più rifiuti, assegnazioni durate oltre due minuti, chiamate terminate senza successo. Per l’incorporamento la documentazione indica due strade: dashboard KPI custom costruiti su Application Insights, oppure i dashboard di Azure Data Explorer, per i quali Microsoft pubblica un file già pronto nel repository GitHub Dynamics 365 FastTrack Implementation Assets, con una pagina Conversation diagnostics e una Unified routing diagnostics. Il dashboard si può poi condividere all’interno dell’organizzazione oppure incorporare in un portale aziendale.

Il dashboard Diagnose, e la confusione da evitare

Se la telemetria deve restare dentro il prodotto esiste il Diagnose dashboard. Non è un semplice interruttore: oltre alle conversation diagnostics già configurate richiede l’ID di Application Insights in una environment variable, un’app registrata con federated identity credentials e ruolo Monitoring Reader su Azure, e l’attivazione dell’app setting Enable Application Insights Dashboard. I supervisori lo aprono dal site map del Copilot Service workspace, in Omnichannel Realtime analytics, con il comando Diagnose; servono i ruoli Omnichannel supervisor oppure CSR Manager. Mostra Total processed conversations, Assignment time (P95), le Conversations with non-assignment reasons e la timeline evento per evento. Attenzione a due limiti dichiarati: lì la diagnostica di trasferimenti e consulti non è supportata, e le informazioni valgono solo per i metodi di assegnazione out-of-the-box.

La confusione tipica su cui l’esame può giocare è un’altra. La vecchia funzionalità di diagnostics dello unified routing, quella che si accendeva dal Copilot Service admin center sotto Routing e scriveva i dati in Dataverse, è deprecata, e la documentazione raccomanda esplicitamente di usare al suo posto le conversation diagnostics in Application Insights. Se una domanda descrive dati diagnostici che consumano capacità di storage Dataverse, sta parlando della funzionalità in uscita, non di quella da scegliere.