Due famiglie di app, due catene di controllo
Sotto il marchio Dynamics 365 convivono due architetture che non si comportano allo stesso modo. Le app per finance e supply chain — Dynamics 365 Finance, Dynamics 365 Supply Chain Management, Commerce, Project Operations — appartengono alla famiglia finance and operations apps: la funzionalità AI si abilita nel workspace Feature management dentro l’ERP, ma l’esperienza conversazionale è un agente di Microsoft Copilot Studio distribuito nell’ambiente Microsoft Dataverse collegato. Le app per customer experience e service — Dynamics 365 Sales, Dynamics 365 Customer Service, Contact Center — sono model-driven e native su Dataverse: si governano dal Copilot Service admin center, dai profili di esperienza e dai security role.
Per un architetto la differenza non è cosmetica: è il numero di piani di controllo da allineare. Attivare Agent management (production ready preview) in finance and operations richiede la feature Immersive Home, una versione minima dell’ambiente, un ambiente Dataverse collegato, l’installazione della soluzione Copilot for Finance and Operations apps e il feature flag Copilot attivo nel Power Platform admin center. Un piano che promette agenti autonomi in Supply Chain senza aver verificato quella catena è già scivolato.
Attenzione a due coppie che l’esame ama scambiare: Copilot for Sales e Copilot for Service sono prodotti Microsoft 365, distinti dal Copilot dentro le app Dynamics 365, che è funzionalità dell’app; e Service Agent in Customer Service estende Microsoft 365 Copilot, tanto che l’abilitazione richiede due amministratori diversi, uno in Microsoft 365 e uno in Dynamics 365.
L’agent chat di finance and operations e le knowledge source aggiuntive
Il sidecar di generative help and guidance with Copilot non nasce ancorato ai dati aziendali: è ancorato alla documentazione pubblica del prodotto. La catena è dichiarata in tre passi — riscrittura della domanda, ricerca dei documenti sul dominio learn.microsoft.com tramite l’indice di Bing, generazione della risposta con citazioni.
Estenderlo significa lavorare sull’agente Copilot for finance and operations apps in Copilot Studio, che espone il topic out-of-box conversational boosting. Nella scheda Knowledge si caricano file (PDF, RTF, Word); quando lo stato passa a Ready si prova con Test e si rilascia con Publish. Per SharePoint o per altre sorgenti la documentazione chiede invece di aggiungere un proprio topic nell’agente. L’AI general knowledge è disattivata per impostazione predefinita e la pagina avverte esplicitamente che accenderla aumenta il rischio di contenuti errati: in produzione è una scelta da motivare, non da spuntare.
Un vincolo di progetto tipico: una manifattura vuole che i buyer chiedano al sidecar sia la politica interna di acquisto, che vive come PDF in una raccolta SharePoint governata, sia la giacenza reale. Caricare i file duplica la fonte e rompe il requisito di copia unica; il topic personalizzato la preserva, ma diventa un artefatto da versionare in una solution. E la giacenza non è documentazione: è dato strutturato, quindi appartiene a un’altra strada.
Dove la documentazione si contraddice, e come decidere lo stesso
Quella strada è la virtual entity per finance and operations apps, esposta in Dataverse con prefisso mserp_ e aggiunta come knowledge source da Add knowledge → Dynamics 365, oppure la sincronizzazione con dual-write verso tabelle Dataverse native. Il tutorial ufficiale mostra proprio questo. La pagina che spiega come aggiungere knowledge al generative help, però, dice delle virtual entity pubblicate da finance and operations che “aren’t currently supported as knowledge sources”.
Le due pagine non si conciliano a parole, e l’esame non premia chi ci prova: premia chi cita la pagina del prodotto di cui sta parlando e chi progetta in modo che la decisione non dipenda da quale pagina ha letto. Regola pratica: procedure e policy vanno su file o topic dell’agente; i dati operativi vivi vanno su virtual entity o dual-write, verificando la fattibilità nell’ambiente di destinazione prima di prometterla in un design. Ricorda anche che Chat with finance and operations data è documentata come preview.
Non confondere infine l’aggiunta di knowledge con la governance dell’esecuzione: le azioni degli agenti autonomi in finance and operations finiscono in un’entità Dataverse dedicata, con una retention predefinita modificabile via system job. Knowledge, evaluation e telemetria restano tre cose diverse.
Customer experience e service: orchestrazione distribuita fra admin center
Su questo lato la superficie è più ampia e più frammentata. Nel Copilot Service admin center si scelgono le esperienze (Copilot immersive, Copilot side pane), si configura l’agente Customer Support e, opzionalmente, l’agente Admin Management (preview), che rimanda a Copilot Studio per strumenti e knowledge. Il Customer Knowledge Management Agent genera articoli da case e conversazioni, in tempo reale o in modalità storica: le leve architetturali sono lo stato di compliance predefinito e l’auto publishing, con la scelta fra pubblico interno e interno più esterno. Se il cliente pubblica anche su un portale esterno, quella singola opzione sposta il rischio dall’operativo al legale.
In Sales la trappola è di capacity e governance: gli agenti provisionano agenti skill-based in Copilot Studio e ciascuno genera una app registration in Microsoft Entra, moltiplicata per il numero di organizzazioni del tenant. In Supply Chain il Procurement Agent (production ready preview) unisce supplier communications e impact analysis e consuma credit di Copilot Studio a ogni esecuzione. E in entrambe le famiglie va verificato lo spostamento dati fra region prima di promettere una funzionalità Copilot: la disponibilità predefinita non è uniforme.