Context variable: creazione, limiti e utilizzo
I context variable arricchiscono la conversazione con dati pre-conversazione, dati di canale e contesto personalizzato, e si configurano per singolo workstream. Nel site map del Copilot Service admin center apri Workstreams sotto Customer support, seleziona il workstream e usa Add context variable in Advanced settings; nel riquadro Edit premi Add, indica il Name e scegli il Type, che può essere soltanto Text o Number. Due limiti da ricordare: il nome non può superare i 100 caratteri, il valore i 4.000. Il confronto è case-sensitive: il valore va passato con corrispondenza esatta.
Servono a definire le regole di routing che smistano le conversazioni verso code diverse e ad alimentare gli strumenti di produttività del representative (l’operatore umano), come macro e script. La documentazione raccomanda di non modificarli né eliminarli dopo la creazione; se è indispensabile, verifica prima che non siano usati nelle regole di classification o assignment dell’unified routing.
Oltre ai tuoi esistono variabili di sistema già pronte, per esempio msdyn_ConversationId, msdyn_WorkstreamId e msdyn_Locale. Anche le risposte a un pre-conversation survey diventano context variable, con il nome della domanda. Un agent creato in Copilot Studio può leggerle e impostarle, e le consegna a Dynamics quando la conversazione viene escalata al representative: è il meccanismo con cui si collega il caso creato dall’agent. Occhio al confine: la pagina che elenca le variabili per gli agent vale solo per Customer Service e Contact Center standalone, non per l’embedded.
Identificazione automatica del cliente
L’identificazione automatica parte dalle preconversation question dei chat widget: l’applicazione usa le risposte per cercare i record e mostra l’esito nella pagina Active Conversation. Per account e contact cerca sui campi Name, Email e Phone Number, per i case sul Case Number. Le mappature sono name, emailaddress1, telephone1 per l’account, fullname, emailaddress1, mobilephone per il contact e ticketnumber per l’incident. Il case però vale solo per Customer Service.
Tre dettagli che l’esame trasforma facilmente in domanda. Primo: la ricerca considera solo i record con status code attivo, quindi con status code personalizzati l’identificazione non funziona. Secondo: se la ricerca restituisce più di un account, contact o case il record non viene collegato, mentre se il contact o l’account identificato ha un solo caso attivo quel caso viene collegato in automatico. Terzo: sul canale voce il numero chiamante viene confrontato con il mobile phone del contact o con il telefono dell’account, e per usare altri campi telefonici bisogna aggiornare via API la record identification rule del workstream, sostituendo il fetch XML.
Chiusura automatica, consult e transfer
La chiusura automatica è il classico punto in cui si sbaglia il “dove”: non esiste una pagina dedicata nell’admin center. La durata si imposta in Power Apps: Tables, tabella Channel State Configuration, colonna Auto close conversation after. Oppure via Web API. Uno scheduler controlla le conversazioni ogni 5 minuti guardando il campo modifiedon della tabella Conversation. I default cambiano per canale e status reason: una chat in Open diventa idonea dopo 20 minuti, in Wrap-up dopo 15; una conversazione voce Active passa a Wrap-up dopo due ore. Cosa diversa è Auto-close after inactivity, che si imposta sul workstream, riguarda le conversazioni in Waiting ed è disponibile solo per persistent chat, SMS, social e Microsoft Teams.
Consult e transfer si abilitano invece in Channels > Consult and transfer. Per impostazione predefinita i representative possono già consultare altri representative e trasferire verso le code; le opzioni avanzate sono Consult to queue, che lascia al sistema la scelta del collega più adatto e chiede un countdown separato per voce e messaging, e transfer to representatives in Transfer settings per il trasferimento diretto. Nella stessa pagina ci sono Wrap up after transfer e Reroute (preview). Sulla capacity: per il consult to queue è bloccata di default, per il consult diretto va abilitata esplicitamente con l’apposita casella. Puoi infine restringere gli elenchi con quattro filtri FetchXML, uno per ogni combinazione di consult o transfer verso queue o representative. Il customer support swarming, che in passato compariva in questo scenario, è deprecato.
Masking dei dati sensibili e custom presence
Le regole di masking si creano in Productivity, Manage per Data masking, poi New Masking Rule, compilando Name, Description e Regular expression, con i campi di prova Enter test data e Masked test data; di default maschera con il cancelletto. Quelle di serie sono Credit Card, Email e SSN, il massimo è dieci in tutto e devono essere Active. Vale per chat e canali asincroni e si estende al transcript. Attenzione all’asimmetria: Mask private agent data from the customer maschera per entrambi, mentre Mask private customer data from the agent maschera per entrambi in live chat ma, sui canali asincroni, solo nell’interfaccia del representative. Ancora diverso è il flag Sensitive data sulle variabili di Copilot Studio per gli agent vocali, che mette in pausa registrazione e trascrizione.
Le custom presence si creano sempre in Productivity, Manage per Custom Presence, poi New: Name, Presence Text, Base Status e Description. Gli stati di serie sono Available, Away, Busy, Busy - DND, Inactive e Offline, non modificabili, e Inactive non è selezionabile a mano. I base status sono Available, Busy, Busy-DND, Away e Offline, gli stessi che si scelgono in Allowed Presences del workstream: a decidere la distribuzione del lavoro è il base status, non il testo visibile. Mappare una presence dall’aria disponibile su un base status Offline è l’errore che ti verrà chiesto di riconoscere.