Configurare la timeline sul form
La timeline è il controllo che raccoglie in un unico flusso la storia di un record: attività, note e post. Si aggiunge da Power Apps aprendo la tabella, poi Forms, e trascinando il componente Timeline da Components dentro una sezione del form; le modifiche diventano visibili solo dopo Save e Publish. Su uno stesso form puoi mettere più timeline, e ogni form della stessa tabella si configura in modo indipendente.
Le impostazioni sono raggruppate in tre aree. In Display options trovi Records shown on page (di default 10, fino a un massimo di 50, oltre i quali compare Load more) e Record types to show, che governa i tre tipi primari: Activities, Notes e Posts. Attenzione: i post richiedono un’app Dynamics 365, quindi un ambiente Dataverse “nudo” non li mostra.
L’area Advanced vale per tutti i tipi di record e contiene le opzioni che gli scenari di contact center toccano più spesso: Quick entry record type (nota o post in cima al riquadro), Sort order default, Enable filter pane, Expand filter pane, Enable search bar, Expand all records, Edit filter pane per decidere quali filtri sono già applicati all’apertura, e il riepilogo What you’ve missed.
In Record settings si scende sul singolo Activity type: lo abiliti o disabiliti, decidi se consentire Create directly from timeline, imposti Create activities using e Open activities using, scegli la card form e l’ordinamento con Sort activities by. La card è divisa in ColorStrip, Header, Details e Footer, ma sul record della timeline compaiono solo le prime due colonne dell’Header e le prime tre dei Details: il Footer non si vede. Per le tabelle account e contact esiste inoltre l’activity rollup type, con i valori Extended, Related e None.
Due limiti sono ottimi candidati d’esame: superati i 10 activity types selezionati compare un avviso esplicito sull’impatto in termini di prestazioni, e una timeline non può essere associata a più di 15 tabelle diverse, oltre le quali il caricamento fallisce. Se sull’app sono attivi i timeline highlights, Copilot genera in cima alla timeline un elenco puntato delle attività principali del record; la funzionalità è dichiarata per Dynamics 365 Customer Service e per Dynamics 365 Contact Center nella sola versione standalone, e richiede un ambiente con l’impostazione Enable Dynamics 365 apps.
Portare dati esterni con i connettori custom
Quando la storia del cliente vive anche fuori da Dataverse, la timeline si estende con i connettori custom. Tecnicamente si tratta di una web resource JavaScript che implementa l’interfaccia IRecordSource: il TimelineWallControl la carica, ne istanzia il constructor e poi la interroga per inizializzarsi, chiedere pagine di record, chiedere i dettagli dei filtri e la resa visiva del singolo record. La registrazione avviene nel parametro UClientRecordSourcesJSON del FormXML, ma dall’esperienza maker la si gestisce nel riquadro Properties della timeline, in Custom connectors, con Add connector oppure selezionando un connettore esistente e scegliendo Edit.
I connettori custom possono aggiungere un tipo di filtro a un gruppo esistente, aggiungere un nuovo gruppo di filtri, aggiornare i conteggi e filtrare sulla chiave di ricerca. Sono supportati su form a sessione singola e multisessione delle app model-driven in Unified Interface, mentre restano fuori scenari offline, dashboard e tutti i contesti dove il TimelineWallControl non esiste, come canvas app, Power Pages e custom page. Due avvertenze importanti: le web resource configurate non risultano dipendenze formali del form, quindi esportando il form non partono da sole e vanno aggiunte a mano all’export; e poiché il modello di sicurezza considera non attendibili le web resource JS e JSON, non vanno mai messi token o segreti al loro interno, che resterebbero in chiaro. Per i dati dentro Dataverse si usa l’oggetto context ricevuto in init.
Il channel integration framework e le sue due versioni
Il Dynamics 365 Channel Integration Framework è un framework estendibile cloud-to-cloud che integra provider di canale non Microsoft nelle app Unified Interface tramite una libreria JavaScript. Va detto con precisione che cosa non è: non è un softphone, non effettua chiamate né invia messaggi, non gestisce le sessioni di chiamata o chat e non funziona con il vecchio client web. Qui sta la confusione tipica che l’esame cerca: il framework serve a portare dentro l’app il widget di un provider di telefonia di tua scelta, non è il modo per aggiungere un canale digitale supportato, che si configura invece dal workstream nel Copilot Service admin center.
La versione 1.0 si usa con le app model-driven a sessione singola come Customer Service, Sales, Project Service e Field Service, tiene il pannello di comunicazione a destra, ammette un solo provider per volta e prevede le modalità Minimized ed Expanded; nel record del provider si trovano le griglie Select the Unified Interface Apps for the Channel e Select the Roles for the Channel. La versione 2.0 è quella delle app multisessione, cioè Omnichannel for Customer Service e Copilot Service workspace: pannello a sinistra, modalità Docked, Minimized e Hidden, supporto a più provider di telefonia contemporaneamente, channel analytics e template di notifica, application tab e sessione. In 2.0 quelle due griglie non compaiono più, perché i provider sono associati agli app profile assegnati ai representative; e dopo un deploy o un aggiornamento dell’app profile di Copilot Service workspace il campo Channel URL può essere sovrascritto, quindi va sempre riverificato. Un widget costruito con le API 1.0 continua a funzionare in 2.0 previa riconfigurazione, ma il widget 1.0 non è caricabile in Omnichannel for Customer Service.
Feedback: i survey agent di Copilot Studio
La raccolta del feedback passa oggi da agenti AI creati in Copilot Service admin center e rifiniti in Copilot Studio. Dalla site map, in Customer Support si apre Customer settings e si sceglie Manage per Customer feedback; con New si parte da un template Customer Satisfaction (CSAT) Survey, Net Promoter Score (NPS) Survey, Customer Effort Score (CES) oppure Blank Template. Nella pagina Properties si indicano nome e lingua primaria e si decide l’interruttore Enable for Voice Channels. Salvato il sondaggio, l’applicazione crea un survey agent omonimo che resta in stato In Progress finché non lo pubblichi da Copilot Studio, dopodiché passa a Ready; perché la pubblicazione riesca serve la connection reference Dataverse dedicata al sondaggio.
Modificando l’agente vale una regola secca: si edita solo il topic di sistema Conversation Start, gli altri sono disabilitati. Le variabili di risposta che vuoi salvare in Dataverse devono avere nome che inizia per MCS_, e il contesto aggiuntivo si passa in mcs_additionalcontext come coppie chiave-valore JSON. Per i canali di messaggistica digitale il sondaggio si aggancia dal workstream selezionando l’opzione Powered by Microsoft Copilot Studio; per la voce si attiva l’interruttore Post-call survey nella scheda Behaviors del voice workstream e si sceglie il sondaggio in Customer feedback survey, con consenso implicito o esplicito raccolto dall’IVR agent. Le risposte finiscono nella tabella Customer feedback survey response. Non confondere questo percorso con il post-conversation survey basato su Dynamics 365 Customer Voice, che è un meccanismo distinto con prerequisiti propri.