Il glossario non è documentazione: è un mapping fra lessico e schema dati
Un assistente generativo ancorato a Microsoft Dataverse legge lo schema, non il gergo aziendale. Se un venditore chiede “quali trattative hanno un margine di primo livello sopra soglia”, il modello non ha alcun appiglio: la colonna esiste, ma si chiama diversamente e nessuna descrizione la lega alla parola che quel venditore usa ogni giorno. È qui che entrano i business term, e la scelta che l’architetto deve saper motivare è che si tratta di un intervento di mapping semantico, non di formazione degli utenti né di sviluppo.
In Copilot in Dynamics 365 Sales — che è una funzionalità dell’app, personalizzabile in Microsoft Copilot Studio e non in Microsoft Foundry — il meccanismo vive nella knowledge source SalesSpecificQnA dell’agente Copilot in Dynamics 365 Sales. Lì trovi due sezioni distinte: Glossary, dove inserisci termine e descrizione, e Synonyms, dove aggiungi nomi alternativi per le colonne delle tabelle. La documentazione porta un esempio letterale: una colonna custom custom revenue sulla tabella opportunity a cui si associa il sinonimo opportunity revenue.
Il criterio di progettazione è questo. Se la domanda ricorrente si risolve con un semplice alias su una colonna, un sinonimo basta ed è più economico da mantenere. Se invece il termine implica una regola — un filtro, uno stato, una relazione — serve un glossary term la cui descrizione nomini esplicitamente tabella e colonna. La documentazione del Sales agent mostra proprio questo salto di livello: overdue task viene definito come un record della tabella Task in cui la colonna State code è aperta e la colonna Scheduled end date è precedente a oggi. Un acronimo come VP viene invece ricondotto al valore della colonna JobTitle della tabella Contact.
Scenario tipico d’esame: un distributore ha una colonna custom che i commerciali chiamano in tre modi diversi, il vincolo è “nessuna nuova colonna, nessun codice, rilascio in due settimane”. La risposta corretta non è un agente nuovo né un fine-tuning: è glossary più synonyms, con la revisione dei termini affidata al business.
Due Copilot, due glossari: leggere il vincolo prima di progettare
Questa è la confusione che l’esame punisce più spesso. Copilot in Dynamics 365 Sales è una capability dell’applicazione Dynamics 365; Microsoft 365 Copilot for Sales, la cui esperienza è il Sales agent, è un prodotto Microsoft 365 che affianca un CRM che può essere Dynamics 365 oppure Salesforce. Hanno entrambi un glossario, ma non lo stesso, e non si configurano nello stesso posto.
Per il Sales agent connesso a Salesforce i termini sono righe della tabella CopilotGlossaryTerms in Dataverse, nell’ambiente msdyn_viva, con i campi Term, Description e Skill. Poiché quella tabella non ha un’interfaccia propria, occorre costruire una model-driven app che la esponga. Il valore da mettere in Skill si ricava dalla colonna QnASearchConfigName della tabella msdyn_vivaorgsettings, sulle righe il cui FeatureName inizia per “SalesChatConfig” e il cui OrgId corrisponde all’istanza Salesforce: è così che il glossario resta circoscritto a una singola organizzazione CRM. Dettaglio con conseguenze progettuali: gli aggiornamenti ai termini possono richiedere fino a 15 minuti per diventare disponibili, quindi il piano di test di accettazione non può prevedere verifica immediata.
Quando lo scenario cita Salesforce, o Outlook e Teams come superficie d’uso, stai parlando del Sales agent. Quando cita l’app Sales Hub e la chat dentro Dynamics 365, stai parlando di Copilot in Dynamics 365 Sales.
Personalizzazioni: riassunti, prompt e contesto passato all’agente
Sul lato service la personalizzazione più richiesta è il formato del riassunto. In Copilot Service admin center, sotto Summaries, il collegamento Manage format permette di scegliere fra Paragraph e Structured; con Structured si compongono sezioni fra Root Cause, Customer Issue, Troubleshooting steps, Outcome ed Error codes, si aggiungono sezioni proprie con Add new info indicando titolo e istruzioni, e si decide con il toggle Remove information from the summary that can’t be found se le informazioni assenti vanno omesse. Vincolo tipico: un contratto di qualità impone che ogni chiusura riporti causa radice ed esito, e allora Paragraph non è ammissibile.
Sui prompt, il Sales agent espone Starter Prompts con set separati per il contesto Dynamics 365 e per Microsoft 365 Copilot; quelli forniti da Microsoft sono di sola lettura ma disattivabili. In Copilot in Dynamics 365 Sales la prompt guide si personalizza invece modificando il topic SalesSparks, e la personalizzazione tramite Copilot Studio è documentata come funzionalità preview.
L’estensibilità vera passa da Extend agent with Copilot Studio, dichiarata production-ready preview: apre l’agente gestito Customer Service Copilot Bot, a cui aggiungere knowledge, tool, altri agenti e topic. Copilot interroga prima l’agente Copilot Studio e ripiega sulle knowledge source configurate se non arriva una risposta confidente, mentre riformulazione, sintesi e traduzione hanno comunque la precedenza. Puoi passare custom context indicando entità, campo e descrizione — descrizione che l’orchestratore usa per capire come impiegarlo. Non puoi però cambiare il modello dell’agente, le sue istruzioni, i topic il cui nome inizia per msdyn_, né usare connettori custom con autenticazione OAuth: sono limiti architetturali, non dettagli.
Infine il perimetro: per personalizzare serve il ruolo Copilot Studio Author, i topic custom consumano credit di Copilot Studio, e le modifiche vanno racchiuse in una solution per essere promosse fra ambienti — l’ALM di Power Platform, non il ciclo di vita di un deployment in Microsoft Foundry.