Accendere il pannello e i tool di produttività custom

Il productivity pane di Copilot Service workspace mostra in una vista unificata knowledge search, script e smart-assist card. Non si accende una volta per tutta l’organizzazione: si accende per experience profile. In Copilot Service admin center vai in Support experience > Workspaces > Experience profiles, apri il profilo e nella sezione Productivity pane seleziona On; da lì attivi i singoli toggle — fra cui Copilot, Knowledge search, Agent scripts, Smart assist, Teams chats, Join a Teams call, Case handling time, Screen Recording e Timeout Rules — e imposti Default mode su modalità espansa o compressa.

Oltre agli strumenti pronti, il pannello ospita i custom productivity tools: pagine custom oppure controlli Power Apps component framework. Prerequisiti dichiarati: ruolo di sicurezza Productivity tools administrator per chi configura, Productivity tools user per representative e supervisor. La registrazione avviene in Support experience > Productivity, scegliendo Manage su Productivity tools e poi New: nella scheda New Pane tool configuration compili Name, Unique Name, Type (Control oppure Custom Page) con il rispettivo Control Name o Custom Page Name, più Icon, Global, Description e Learn More Link. Registrare però non basta: lo strumento diventa visibile solo quando lo abiliti nel Productivity pane di un experience profile.

Due limiti che la documentazione dichiara nero su bianco. Gli strumenti custom ospitati nel productivity pane non sono legati contestualmente alla sessione e non dispongono di un meccanismo per recuperare informazioni dal contesto di sessione. E productivity pane e productivity tools non sono disponibili in Omnichannel for Customer Service su Unified Service Desk.

Nota sui due prodotti: le pagine di productivity tools, custom productivity tools, script e macro si applicano a Dynamics 365 Customer Service e a Dynamics 365 Contact Center solo nella variante standalone, mentre la pagina degli experience profile copre anche Contact Center embedded. Le informazioni sui case, precisa la doc del pannello, valgono solo per Customer Service.

Script: guidare la persona, passo per passo

Uno script dice al representative che cosa fare davanti a un problema del cliente, così che vengano condivise solo informazioni accurate e approvate dall’azienda. Lo crei in Productivity > Manage su Scripts > New, indicando Name, Unique Name (formato prefisso più underscore più nome, con prefisso alfanumerico da 3 a 8 caratteri), Language — scelto fra le lingue abilitate in Microsoft Dataverse — e Description. Dopo il salvataggio compare la sezione Script steps: ogni passo si aggiunge con New Script step e ha Name, Unique Name, Owner, Script, Order e soprattutto Action Type, che vale Text instruction, Macro o Script.

Sono tre comportamenti diversi a runtime. Un passo Text instruction mostra l’istruzione da eseguire a mano e la persona lo chiude con Mark as done; un passo Macro espone l’icona Run; un passo Script carica un altro script al posto di quello corrente. Gli step eseguiti correttamente sono contrassegnati con un segno di spunta verde, quelli in errore con una croce rossa, e lo stato finale è quello dell’ultima esecuzione.

Perché lo script compaia davvero, va associato a un session template: lo apri in Workspaces > Session templates, vai alla scheda Scripts e usi Add Existing script. Se allo stesso tipo di sessione sono associati più script, decidi quale mostrare per primo impostando Enable build expression su Yes, aprendo Build Expression e usando, nei rami If true e If false, l’azione Set default script.

Slug: valori dinamici dentro il testo

Uno slug è un parametro di sostituzione che il sistema popola a runtime in base al contesto, e fa parte dell’automation dictionary, il dizionario che mantiene i dati contestuali della sessione. Lo usi nel nome del passo e nel testo dell’istruzione, così una riga generica diventa un saluto con il nome vero del cliente.

Fra gli slug supportati da macro e script ci sono ${customerName}, ${caseId}, ${caseTitle}, ${LiveWorkItemId}, ${queueId}, ${visitorLanguage}, ${visitorDevice}, ${customerEntityName}, ${customerRecordId} e ${entityRoutingLogicalName}, più uno slug per ciascuna domanda della pre-conversation survey configurata sul workstream. Il formato cambia col contesto: ${slug} nel contesto productivity automation, ${$session.slug} nel session connector, ${$oc.slug} nell’omnichannel connector. Per dati che stanno in Dataverse ma non nel contesto usi una query OData nella forma {$odata.entityName.entityAttributeName.?options}.

Tre trappole. I template di sessione, notifica e tab usano le graffe singole, macro e script il dollaro davanti. Per Copilot Service workspace la doc precisa che in macro e script è supportato solo lo slug ${anchor.<attribute_name>}. E il session context viene popolato solo con i valori dell’anchor tab: i record aperti nelle schede successive non ci finiscono.

Macro: eseguire al posto del representative

Una macro è un insieme di azioni sequenziali che dicono al sistema come completare un compito. La crei in Productivity > Manage su Macros > New, e devi sempre iniziare la costruzione con lo step Start macro execution. Le azioni arrivano da quattro famiglie: Productivity automation (per esempio Open a new form to create a record, Autofill form fields, Update an existing record, Save the record, Resolve a case, Open an email form with predefined template, Set Script focus, Execute JavaScript), Session connector, Omnichannel connector — che collega e scollega record dalle conversazioni — e Flow connector, per innescare un flusso Power Automate. Per progettarle serve il ruolo Productivity tools administrator o System Administrator; per eseguirle, Productivity tools user o Customer Service representative. Una macro parte dal pannello Productivity in Copilot Service workspace oppure da una chiamata API.

Quando qualcosa non funziona, apri lo script step con il target macro e seleziona View history: vedi quante volte è stata eseguita, con esito, e il passo esatto in cui si è fermata. Le esecuzioni sono registrate nella tabella Macro Run History (msdyn_macrosession), su cui puoi costruire report di utilizzo e tasso di successo.

Che cosa verifica l’esame. Quasi sempre chiede di scegliere fra script e macro leggendo uno scenario. La regola è semplice: lo script guida una persona, che deve comunque agire e marcare il passo come fatto; la macro esegue. Se il testo dice “senza che il representative debba fare nulla” o “con un solo clic”, la risposta è la macro. La seconda confusione tipica riguarda i tool custom: registrarli in Productivity tools non li rende visibili, serve il toggle nel Productivity pane del profilo giusto.