Far entrare i dati: template, formati e mapping
Prima che un agente possa fare qualcosa di utile, i dati devono essere dentro Dataverse. Nelle model-driven app l’import parte quasi sempre da un Excel template: si apre la tabella, sulla command bar si sceglie Excel Templates > Download Template, si seleziona il tipo di tabella e la view (oppure si usa Edit Columns), si compila il file e lo si reimporta. La documentazione è esplicita nel raccomandare di non aggiungere né modificare colonne nel template, perché è proprio lì che nascono gli errori di mapping.
I formati supportati sono tre: Excel workbook (.xlsx), Comma-separated values (.csv) e XML Spreadsheet 2003 (.xml). La dimensione massima è 8 MB, che sale a 32 MB per i file .zip. Sulla command bar troverai di conseguenza tre comandi distinti — Import from Excel, Import from CSV, Import from XML — e un solo file per volta: per portarne altri si rilancia il wizard.
Durante la procedura decidi se Allow Duplicates; per i file CSV scegli data delimiter e field delimiter; per CSV e XML puoi indicare una alternate key, che serve a identificare in modo univoco e aggiornare le righe esistenti invece di crearne di nuove. È il meccanismo giusto quando stai facendo un aggiornamento massivo e non un caricamento iniziale.
Il passaggio decisivo è Review Mapping. Le colonne obbligatorie compaiono sotto Primary Fields, quelle facoltative sotto Optional Fields (dove puoi scegliere Ignore); le colonne mappate correttamente hanno una spunta verde, quelle non riconosciute un punto esclamativo rosso. Le colonne a valori fissi si mappano su un campo di tipo Option Set, e le colonne che puntano ad altri record si risolvono con Lookup Reference, scegliendo per ogni tabella correlata le colonne su cui cercare. Con Name your data map salvi la configurazione per la volta successiva. Dopo il lancio, Track Progress apre la pagina My Imports, dove lo stato passa per Submitted, Parsing, Transforming, Importing e Completed, e le colonne Success, Failures e Partial Failures dicono com’è andata: dalla scheda Failures puoi usare Export Error Rows, correggere e reimportare. Se qualcosa va storto ci sono Delete import source file, Delete imported records e Delete All.
Attenzione ai limiti dichiarati: l’import da Excel non è supportato con le virtual table né con le elastic table, aggiorna i campi della tabella primaria ma ignora quelli delle tabelle correlate, e i job girano in parallelo solo con file sotto 1 MB.
Far uscire i dati: Excel, e le soluzioni degli agenti
Sul lato opposto c’è Export to Excel, con quattro opzioni che non sono intercambiabili: Excel Online per analisi ad hoc o modifiche massive rapide, Static Worksheet per una fotografia da condividere, Dynamic Worksheet quando serve poter aggiornare i dati in Excel, Dynamic PivotTable per l’analisi a tabella pivot. Due dettagli che l’esame ama: le colonne calculated e roll-up e le secured columns sono modificabili in Excel ma non possono essere reimportate; e l’export non supporta le virtual table. In caso di timeout la documentazione suggerisce di esportare a lotti più piccoli restringendo i filtri, ridurre i lookup e ridurre il numero di colonne. Da amministratore ricorda che l’export verso Excel ricade fra i privacy-related privileges di un security role, quindi è un permesso che si concede, non un diritto naturale.
Non confondere l’export dei dati con l’export delle soluzioni degli agenti, che è tutto un altro capitolo: usa l’ALM di Power Platform per spostare Sales Qualification Agent, Sales Opportunity Agent, Sales Close Agent, Recommended Actions Agent e Data Enrichment Agent da un ambiente all’altro. Si crea una solution nel maker portal, si aggiungono i componenti SalesAgentProfile e SalesAgentConfigurationV2 (più il componente Sequence con il record AgenticSequence, che riguarda solo il Sales Qualification Agent), si esporta come managed solution e la si importa nell’ambiente di destinazione. La documentazione raccomanda una solution per profilo di agente e filtri organization-agnostic nei selection criteria. L’agente arriva sempre in draft state e va confermato con Apply changes; la Dataverse application user e le app registration non viaggiano nella solution e vanno ricreate a mano, mentre assignment rules, selection criteria e knowledge sources vanno riverificati perché possono puntare a utenti, team o librerie che nel nuovo ambiente non esistono. Tieni presente che nella documentazione Sales Close Agent e Sales Opportunity Agent sono ancora indicati come preview, e la study guide avverte che l’esame verte soprattutto sulle funzionalità in general availability.
Ruoli, privilegi e livelli di accesso
Il security role è l’unità di misura dei permessi. Un utente può averne più di uno e i privilegi si sommano: non esiste un ruolo che toglie ciò che un altro concede. I privilegi di tabella sono Create, Read, Write, Delete, Append, Append to, Assign e Share — dove Append significa collegare il record corrente a un altro e Append to significa esserne il destinatario. Ogni privilegio ha poi un access level che ne stabilisce la profondità: Organization (tutti i record dell’organizzazione), Parent: Child Business Unit (la propria business unit e tutte quelle subordinate), Business Unit (solo la propria), User (i record posseduti, quelli condivisi con l’utente e quelli condivisi con un team di cui è membro) e None. Per accelerare la configurazione esistono i permission settings preconfezionati: No Access, Full Access, Collaborate, Private, Reference, Custom.
Sales porta i suoi ruoli predefiniti, divisi per categoria. Fra i primary sales roles ci sono Vice President of Sales, Sales Manager e Salesperson per Sales Enterprise e Sales Premium, e Sales Professional Manager e Sales Professional Person per Sales Professional: qui sta una confusione tipica, perché i ruoli non sono gli stessi fra i piani, e una domanda d’esame può giocare esattamente su questo. Fra i functional roles trovi Forecast Manager, Forecast User e Sequence Manager (che va abbinato a Basic User o simile), mentre gli app access roles — Sales team member, Sales Professional app access, Sales, Enterprise app access — servono ad aprire l’app, non a lavorare sui dati. Ricorda infine l’avvertenza sui ruoli custom: se ne crei uno copiando Sales Manager, non erediterà automaticamente i privilegi aggiunti in futuro al ruolo predefinito.
Business unit, team, condivisione e il perimetro dell’AI
La business unit è il raggruppamento logico che dà senso ai livelli di accesso. Il vertice è la root business unit, ogni business unit ha un solo parent e può avere più figlie, e ogni utente appartiene a una e una sola business unit. Ogni business unit ha un default team che non si può rinominare né eliminare e a cui non si aggiungono o rimuovono membri a mano, ma a cui si può assegnare un security role per dare un accesso comune a tutti. Un team invece appartiene a una sola business unit ma può raccogliere utenti provenienti da business unit diverse, ed è la struttura giusta quando persone di reparti differenti devono lavorare sugli stessi record. Assegnando un ruolo al team, i membri ne ereditano i privilegi.
Sopra tutto questo puoi attivare la hierarchy security, nei due modelli Manager hierarchy (basata sul campo Manager dell’utente, con il manager nella stessa business unit o in quella parent) e Position hierarchy (basata su posizioni definite dall’amministratore, che attraversa le business unit), entrambi limitabili con Depth e comunque subordinati ad avere almeno il privilegio Read a livello User sulla tabella.
Il punto da portarsi dietro per tutto il resto del percorso è che questo modello decide anche che cosa l’AI potrà vedere. Gli agenti non hanno un accesso privilegiato: girano come application user di Dataverse. Per il Sales Qualification Agent, per esempio, la procedura prescrive di registrare un’applicazione in Microsoft Entra e di creare in Settings > Users + permissions > Application users un app user con la root business unit e il security role AIsalesperson. La pagina dei ruoli predefiniti di Sales elenca inoltre gli AI agent user creati dal Sales Qualification Agent (D365 Sales LeadQual, D365 Sales AcctRsrch, D365 Sales OutrchAgt) e avverte che eliminarli può compromettere il deployment. Per Copilot, invece, il controllo è a quattro livelli: tenant per le model-driven app, tenant per Dynamics 365 Sales, gruppo Entra e app-level dalle App Settings del Sales Hub. Se un venditore lamenta che l’agente non vede un’opportunità, la risposta corretta all’esame quasi mai è una impostazione dell’agente: è un access level troppo stretto, una business unit sbagliata o un record semplicemente mai condiviso.