Due sostrati, due catene di rilascio
Le app Dynamics 365 per finance e supply chain e quelle per customer experience e service sembrano condividere lo stesso ALM, perché entrambe poggiano su Dataverse. L’architetto però deve trattarle come due catene distinte. Sales, Customer Service e Contact Center vivono nativamente in Dataverse: l’unità di trasporto è la solution di Power Platform, che viaggia fra environment di sviluppo, test e produzione con connection reference ed environment variable. Le app per finance e supply chain hanno invece una catena propria — pacchetti distribuibili governati da Lifecycle Services e funzionalità accese in Feature management — a cui la parte agentica si aggancia attraverso l’ambiente Dataverse collegato.
La documentazione di Microsoft descrive l’ambiente concettuale, quando è attiva la Power Platform Integration, come composto da due metà: una in Lifecycle Services e una nel Power Platform admin center. Cambia persino il vocabolario delle operazioni di ciclo di vita: Deploy in Lifecycle Services corrisponde a Provision nel Power Platform admin center, Database Refresh corrisponde a Copy, e l’operazione Reset è bloccata sulle istanze Dataverse collegate perché nelle app finance e operations non esiste un equivalente. Chi progetta il percorso dev-test-prod deve sincronizzare le due metà, non solo la solution.
Nota di disambiguazione: qui si parla di agenti forniti da Microsoft dentro le app Dynamics 365, non dei declarative agent dell’estensibilità di Microsoft 365 Copilot e nemmeno di agenti costruiti nel Microsoft Foundry Agents service, il cui ciclo di vita di deployment è un’altra cosa.
Finance e supply chain: il lavoro lo fa l’ambiente, non il pacchetto
Gli agenti Dynamics 365 sono rilasciati come managed solution, ma non si installano a mano. L’agent deployment wizard, dentro Copilot Hub nel Power Platform admin center, esegue una sequenza fissa: verifica dei prerequisiti, configurazione dell’agent identity, connessione dell’agente, configurazione delle mailbox quando l’agente le usa, abilitazione finale. La documentazione precisa che questi passaggi si completano tipicamente una volta per agente e per ambiente — la frase che demolisce l’idea di “esportare l’agente già configurato”. Del wizard esiste anche un’esperienza separata in public preview.
I passaggi che l’esame usa come distrattori stanno tutti nei livelli due e tre. L’identità è un agent user dedicato: si crea nel Microsoft 365 admin center, riceve le licenze prodotto, viene aggiunto all’ambiente Dataverse con i relativi security role e, per le app finance e operations, anche all’ambiente finance and operations con i suoi ruoli. Le connessioni Dataverse si creano con quell’identità e si agganciano alle connection reference dell’agente, verificando che i connettori siano ammessi dalle policy di governance in vigore, e attivando i flow di Power Automate. Nessuno di questi oggetti è contenuto esportabile.
Sul lato applicativo servono poi condizioni d’ambiente: la funzionalità Agent management si abilita in Feature management e richiede Immersive Home, un ambiente Dataverse collegato, la solution Copilot for Finance and Operations apps e il feature flag Copilot attivo nel Power Platform admin center. La pagina Agent activity conserva lo storico per 90 giorni per impostazione predefinita, con un system job di Dataverse che ripulisce i record: la retention è una scelta di governance che si prende ambiente per ambiente. Chi progetta soluzioni con virtual entities ha un vincolo di sequenza in più: la managed solution MicrosoftOperationsERPVE deve già esistere nell’ambiente di destinazione, altrimenti l’import fallisce, e l’aggiunta di campi richiede un refresh manuale dell’entità virtuale.
Customer experience e service: la solution porta il disegno, non l’ambiente
Sul versante Sales il percorso è quello classico di Power Platform: si crea una solution, si aggiungono i componenti dell’agente — per esempio SalesAgentProfile e SalesAgentConfigurationV2, più gli agenti che portano le knowledge source — e si esporta come managed verso la produzione. Le raccomandazioni sono architetturali: una solution per profilo di agente, così ogni profilo si rilascia in modo indipendente, e filtri indipendenti dall’organizzazione nei criteri di selezione, altrimenti dopo la migrazione vanno riscritti a mano.
Quello che non viaggia è esplicito nella documentazione: l’application user di Dataverse e le app registration in Microsoft Entra vanno creati manualmente nell’ambiente di destinazione perché sono specifici dell’ambiente e non fanno parte della solution esportata; i prerequisiti non sono inclusi perché contengono valori d’ambiente; le regole di assegnazione possono puntare a team o utenti inesistenti; e le knowledge source ricompaiono come riferimento, ma il contenuto può non esserci. L’agente arriva sempre in stato draft e va riaperto per applicare le modifiche prima di essere avviato. Microsoft Copilot Studio aggiunge la sua lista di elementi non solution-aware, da rifare a valle: impostazioni di Application Insights, autenticazione manuale, sicurezza dei canali Direct Line e Web, canali pubblicati e condivisioni. Per Customer Service e Contact Center l’adozione progressiva ha uno strumento suo, il rollout manager dentro l’Agent hub del Copilot Service admin center, con piani attivabili, disattivabili e pianificabili per agenti come Customer Intent Agent e Case Management Agent.
Che cosa verifica l’esame
Lo scenario tipico è questo: un’azienda ha validato un agente in sandbox e vuole promuoverlo in produzione senza fermare il servizio, e ti chiede quali passaggi restano dopo l’import. La risposta sbagliata plausibile è “nessuno, la managed solution contiene tutto”. Identità dell’agente, connessioni e licenze si ricreano in ogni ambiente. Attenzione anche a non confondere l’ALM di Power Platform, fatto di solution, environment e pipeline, con il ciclo di vita di un deployment in Microsoft Foundry, e a non scambiare il collaudo funzionale con l’evaluation o con il monitoraggio in esercizio: sono tre attività diverse, in tre momenti diversi del rilascio.