Il controllo di integrità che lavora in background
Il primo agente che incontri in un progetto Dynamics 365 Contact Center non serve i clienti: serve chi la piattaforma la sta configurando. Nel Copilot Service admin center la pagina Home espone la sezione Contact center health, da cui si lancia Run health check. La documentazione lo presenta come un health checker integrato che individua errori, avvisi e best practice consigliate nella configurazione, e aggiunge che è possibile ricevere notifiche proattive di problemi emergenti grazie ai controlli che girano in background: è questa la parte “proattiva” richiesta dall’obiettivo d’esame. Il prerequisito è il ruolo System Administrator, e la capacità vale sia per Dynamics 365 Contact Center (embedded e standalone) sia per Dynamics 365 Customer Service.
L’esito arriva in tre categorie con il numero di occorrenze: Errors, Warnings e Suggestions. Espandendo una categoria vedi il problema e il link all’impostazione difettosa, che si apre in una nuova scheda perché tu la corregga. Le regole sono operative, non astratte: coda predefinita disattivata, coda senza representative (l’operatore umano, da non chiamare mai “agent”), workstream privo di intake rule, coda senza un assignment method valido. Dopo aver risolto, si rilancia il controllo finché errori e avvisi non arrivano a zero.
Attenzione a due confusioni tipiche. La prima riguarda il nome: gli obiettivi d’esame parlano di Health Agent, mentre nel prodotto la capacità si raggiunge come health check dalla Home dell’admin center — se in una domanda cerchi una voce di menu chiamata così, non la trovi. La seconda riguarda l’ambito: il health check verifica la configurazione, mentre il Diagnose dashboard serve ai supervisor per capire perché una conversazione non è stata assegnata a runtime. Quest’ultimo si apre dal Copilot Service workspace, da Omnichannel Realtime analytics con il comando Diagnose, richiede Application Insights e la configurazione delle conversation diagnostics, e chiede i ruoli Omnichannel supervisor o CSR Manager. Sono due strumenti diversi con prerequisiti diversi.
Configurazione conversazionale, trasformazione e migrazione di environment
Il Service Operations Agent è l’agente che esegue la configurazione al posto tuo, ed è dichiarato applies to Dynamics 365 Contact Center only: non aspettartelo in Customer Service. Si apre selezionando Launch nel riquadro Conversational Setup del Copilot Service admin center; alla prima apertura la pagina chiede di connettersi a Dataverse tramite server MCP e occorre selezionare Allow once. I prerequisiti sono espliciti: il ruolo Omnichannel administrator per accedere all’agente, il ruolo System Administrator per gestire le connessioni Power Apps e MCP, un piano pay-as-you-go per il consumo, e Application Insights collegato se vuoi che l’agente aiuti anche nel troubleshooting. È disponibile solo in inglese.
Nella pratica crea e aggiorna workstream, code, ruleset di route-to-queue, operating hours, capacity profile, skill e utenti in linguaggio naturale. Conta però sapere anche che cosa non fa: l’assegnazione custom non è supportata, le condizioni nelle regole non si creano dall’agente, e classification ruleset, assignment rule e overflow rule vanno configurate a mano nel Copilot Service admin center.
Il pezzo che sorprende in aula è la migrazione fra environment: non c’è un agente che la esegue, si usa l’application lifecycle management di Power Platform. La raccomandazione è impacchettare le configurazioni in una soluzione unmanaged nell’environment di origine, esportarla come managed e importarla nel target, mantenendo la parità fra gli ambienti e senza modificare direttamente i record di configurazione managed nel target (creeresti un active layer che ha la precedenza e blocca gli aggiornamenti futuri). Anche i survey agent di Copilot Studio si spostano così, aggiungendo alla soluzione Customer feedback survey oppure msdyn_surveyconfig e attivando Allow customizations sul topic Conversation Start. E se copi un environment: la risorsa Azure Communication Services viene copiata ma può essere usata in un solo environment, quindi va disconnessa nel target, i canali digitali vanno ricreati e i survey agent dell’origine non risultano funzionanti nel target.
Agent hub e rollout plan: tre azioni da non confondere
L’Agent hub è il punto unico da cui un amministratore governa gli agenti autonomi. Offre una vista unificata su Learn (panoramiche guidate su agenti, sicurezza, compliance e adozione, da leggere prima di abilitare), Rollout manager, Agent insights per misurare l’impatto, più Security, Architecture e Privacy and compliance.
Il Rollout manager è una procedura guidata per un’adozione graduale e controllata. Il percorso è: Home, Open nell’Agent hub, Create a rollout plan, quindi Create. Puoi creare un piano per singolo agente o un piano unico per più agenti, fra Customer Intent Agent, Case Management Agent, Customer Knowledge Management Agent e Quality Evaluation Agent. Sui piani esistenti agiscono Edit, Deactivate or activate, Delete e Schedule, quest’ultimo per attivare il piano a una data futura.
Qui l’esame gioca sulla distinzione fra tre azioni. Primo, l’abilitazione: gli agenti autonomi devono già essere abilitati per poter creare un rollout plan, e ognuno ha la sua pagina di impostazioni (la quality evaluation, per esempio, si abilita da Customer Support > Quality management > Manage su Quality evaluation). Secondo, la distribuzione: il rollout plan riusa le impostazioni esistenti dell’agente e ne governa la portata, non le sostituisce. Terzo, la disattivazione: per Customer Intent Agent e Customer Knowledge Management Agent, disattivare o eliminare un rollout plan non disattiva né elimina l’impostazione dell’agente corrispondente — l’agente resta acceso. Fa eccezione il solo Case Management Agent, per cui disattivando o eliminando il piano vengono disattivate o eliminate anche le regole. Se una domanda ti chiede come fermare davvero un agente, la risposta non è quasi mai “disattiva il rollout plan”.