L’intent diventa un attributo del work item

La prima trappola è il nome. L’obiettivo d’esame parla di intent-based routing, ma la documentazione corrente descrive l’intent-driven routing, in preview production-ready, e dice testualmente: “Intent-driven routing replaces the intent-based routing experience”. Il cambiamento non è cosmetico: sparisce la mappatura fra gruppi di intent e gruppi di utenti, perché l’intent diventa un normale attributo del work item, utilizzabile nella stessa interfaccia di authoring che usi per tutto il resto.

I campi disponibili sono tre: Intent, Intent group e Line of business. Li usi in due punti dell’unified routing. Nelle classification rules arricchisci il work item, per esempio agganciando una skill quando l’intent vale cancel-order. Nelle route-to-queue rules scegli la coda, magari combinando Line of business e Intent group con altri attributi. Poi il motore di skill-based routing valuta il pool eleggibile della coda e assegna al representative più qualificato.

I prerequisiti sono agenti AI, non regole: serve il Customer Intent Agent abilitato e l’intent discovery configurata. Un punto che l’esame ama: l’unified routing non calcola l’intent da solo. La doc lo scrive senza ambiguità — “Unified routing doesn’t perform intent determination for live chat or voice work items” — perché è l’agente Copilot configurato nel workstream a rilevarlo e a scriverlo sul work item prima che parta il routing. In preview i canali supportati sono live chat, voce e case; per il case l’intent viene determinato al momento del routing.

Preferred representative routing: la persona batte la regola

Questa funzionalità vale sia per Dynamics 365 Contact Center (embedded e standalone) sia per Dynamics 365 Customer Service; la doc precisa però che le informazioni relative ai case si applicano solo a Customer Service.

La configurazione sta nel Copilot Service admin center: nella site map scegli Routing, poi Manage accanto a Preferred representative routing, e attivi Enable preferred representative routing. Subito dopo decidi il fallback, e la scelta non è indifferente: Next best representative based on assignment logic è consigliato per live chat e chiamate voce, mentre No one. Let the work remain unassigned in the queue è pensato per i canali asincroni, dove lasciare il lavoro in coda non penalizza nessuno.

Nella Preferred representatives matrix aggiungi i contatti con Add a contact e mappi le persone con Add user. Puoi mappare fino a tre representative per contatto, e l’ordine conta: ricevono il work item nell’ordine in cui sono elencati, riordinabile con Move up e Move down. Il ruolo richiesto cambia col prodotto: CSR Manager per Customer Service, Omnichannel Administrator per Contact Center; con un ruolo custom servono anche gli accessi alle tabelle msdyn_preferredagent e msdyn_preferredagentcustomeridentity.

Il comportamento a runtime è il fatto più verificabile di tutta l’unità: se esiste un preferred representative disponibile, con una presenza fra quelle ammesse dal workstream, il sistema salta il controllo su capacity, skill e assignment rule. Inoltre funziona solo con conversazioni instradate da workstream push-based, e i representative devono comunque essere membri della coda.

Record, intake rule e il vincolo del rule set unico

Per instradare un record servono tre livelli. Prima la tabella va abilitata alle code: in Power Apps, nelle Table properties, sotto Advanced options, si seleziona Can be added to a queue nella sezione Rows in this table. Attenzione, è una scelta a senso unico: una volta selezionata, la casella viene disabilitata e non si torna indietro.

Poi, in Routing, scegli Manage per Record routing e aggiungi il tipo di record. Infine crei un workstream con Type impostato su Record, scegli Push o Pick come work distribution mode, e definisci le intake rules, che decidono quale workstream prende in carico il work item. Le intake rule si possono mappare a un workstream oppure a un basic routing rule attivo, e si riordinano nella Decision list dopo aver selezionato See more.

I basic routing rule set restano la strada legacy per i case in Customer Service: crei un ruleset, aggiungi i Rule Items, che vengono valutati dall’alto verso il basso finché uno risulta vero, e imposti l’azione Route to verso una coda, un utente o un team. Qui sta il fatto che l’esame usa volentieri: quando l’unified routing non è abilitato può essere attivo un solo routing rule set alla volta, e attivarne un altro disattiva automaticamente quello corrente. Corollario spesso dimenticato: dopo aver abilitato l’unified routing, il basic routing rule attivo non instrada più i record finché non configuri le intake rule.

Capire perché non ha funzionato

Qui la confusione tipica è grave, perché riguarda due strumenti con nomi simili. La vecchia pagina Routing diagnostics nel Copilot Service admin center, che scriveva i log in Dataverse, è deprecata dal 9 maggio 2024. La sostituta indicata è Conversation diagnostics su Azure Application Insights, ed è esattamente ciò che l’obiettivo d’esame chiede.

Prerequisiti concreti: l’ambiente deve essere un Managed environment, serve accesso Contributor o superiore sui servizi Azure, e si può creare una sola configurazione di data export per ambiente. I dati arrivano nella tabella Traces entro circa 15 minuti e si interrogano in KQL filtrando su powerplatform.analytics.subscenario. L’export non è disponibile nei cloud sovrani come GCC, GCC High e DoD.

Il flusso da leggere è Intake, Classification, Route to queue, Assignment — e lo stage Intake esiste solo per il record routing. Il discriminante più utile in fase di debug è il RuleHitPolicy: la classification lavora in “First Match”, mentre il route-to-queue lavora in “Run All”. Di conseguenza gli stati differiscono: nel route-to-queue esiste Matched, che indica una regola vera il cui output però non è stato scelto, mentre Applied indica quella effettivamente vincente. Se leggi un messaggio di fallback queue, la regola non c’era o non era valida nel workstream: non è un problema di capacity.