Creare la solution per un deployment di Contact Center
Il contenitore con cui si sposta una configurazione di contact center è la solution di Microsoft Dataverse. Si crea da Power Apps, con Solutions > New solution, compilando Display Name, Name, Publisher e Version. La documentazione raccomanda di creare un publisher proprio invece di usare quello di default, perché il publisher prefix serve a evitare collisioni di nomi fra soluzioni di provenienze diverse; e una volta che un componente è stato distribuito in una managed solution con un certo publisher, quel publisher non si cambia più.
I componenti si aggiungono con il comando Add existing sulla command bar. Per i canali, la pagina Migrate configurations for channels using solutions indica una tabella di partenza diversa per ciascuno: Chat widget (msdyn_livechatconfig) per Live Chat, Voice channel setting (msdyn_ocvoicechannelsetting) per Voice, Work stream (msdyn_liveworkstream) per Facebook, LINE, Microsoft Teams e i canali custom. Quando aggiungi quei record, la solution tira dentro da sola i correlati: work stream, capacity profile, workstream capacity profile, context variable, decision contract, decision rule set, routing configuration e routing configuration step. È esattamente per questo che la doc avverte di rivedere con attenzione i componenti prima di esportare: dentro possono finire record che contengono riferimenti ad Azure Communication Services, a canali di terze parti o ad altri componenti Microsoft come gli agenti di Copilot Studio e i sondaggi di Customer Voice.
Nota di lettura importante per l’esame: quella pagina vive sotto /dynamics365/customer-service/, ma il suo banner Applies to dichiara Dynamics 365 Contact Center—embedded, Dynamics 365 Contact Center—standalone e Dynamics 365 Customer Service. Molte procedure ALM del contact center sono documentate lì e valgono per entrambi i prodotti: non scartarle perché l’URL dice “customer service”.
Il passaggio fra ambienti: unmanaged in sviluppo, managed a valle
La regola di Best practices for application lifecycle management è secca: nell’ambiente di origine impacchetta le configurazioni in una solution unmanaged, poi esportala come managed e importa quella nell’ambiente di destinazione. La unmanaged è ciò che sviluppi e che tieni sotto controllo di versione; la managed è l’artefatto che distribuisci verso test, UAT e produzione. Non puoi importare una managed solution nello stesso ambiente che contiene la unmanaged da cui è nata: per provarla serve un ambiente separato.
Seconda regola: la environment parity. Perché l’import in destinazione riesca, mantieni allineati origine e destinazione, e assicurati che le solution installate siano della stessa versione da entrambe le parti.
Terza cosa da sapere: la solution non porta tutto. Per la parte restante si usa il Configuration Migration tool, in un ordine preciso — session e notification template, ruleset di skill-based routing, capacity profile nuovi, queue, poi workstream e impostazioni di canale. La doc dichiara fuori scope la migrazione di account, channel provider, agent configuration e impostazioni AI e analytics. Alcune cose restano intrinsecamente legate all’ambiente: i record della tabella Phone Number sono environment-specific e il numero va assegnato a mano in destinazione, e i sondaggi sono sincronizzati con Dynamics 365 Customer Voice in ciascun ambiente, quindi non attraversano il confine. Anche il consiglio generale è chiaro: le configurazioni di canale sono specifiche dell’ambiente in cui vengono create, e la raccomandazione è di crearle con il Copilot Service admin center. Se nella soluzione ci sono flow, ricorda le connection reference: durante l’import nell’ambiente di destinazione viene fornita una connection per ognuna, così i flow che le referenziano possono essere attivati automaticamente a import concluso.
Perché non si edita un record managed: il livello attivo
Questo è il punto che l’esame usa più volentieri, ed è controintuitivo. Se nell’ambiente di destinazione apri un record di configurazione arrivato con una managed solution e lo modifichi direttamente, crei una customizzazione attiva su quel record. Le conseguenze documentate sono due. La prima: quando proverai a cancellare la managed solution che conteneva quella configurazione, l’operazione può fallire, perché il record esiste ora su più livelli di solution. La seconda, più insidiosa: il livello attivo sul record managed può impedire che gli aggiornamenti successivi provenienti dall’ambiente di origine vengano applicati alla destinazione — e siccome l’import della nuova versione risulta comunque riuscito, ti ritrovi con funzionalità che “non funzionano” senza un errore che lo spieghi. La doc lo dice in modo esplicito: il livello attivo ha sempre la precedenza su quello managed.
L’approccio corretto è quindi importare ogni modifica ai record managed come parte dell’import della managed solution, tornando a cambiarli nell’ambiente di origine. Allo stesso modo, non puoi cancellare i record di configurazione managed nell’ambiente di destinazione: il modo giusto è disinstallare la managed solution che li ha portati. Confusione tipica da evitare: pensare che una modifica “veloce” fatta in produzione sia innocua perché piccola. Non è la dimensione della modifica a contare, è il livello che crea.
Gestire l’ambiente omnicanale
Copiare un ambiente non equivale a distribuirlo. Con la Minimal copy vengono copiati solo schema e customizzazioni: spegni e riaccendi i canali, poi ricrei canali e workstream in destinazione senza correzioni. Con la Full copy viene copiato tutto e servono aggiustamenti: rivedi utenti, role mapping e capacity profile, rivedi le queue e le appartenenze dei representative, aggiorna sul tuo sito gli snippet del widget di live chat perché in destinazione vengono rigenerati, e ricrea le configurazioni di canale. Attenzione al voice: la risorsa Azure Communication Services viene copiata, ma una risorsa può servire un solo ambiente, quindi va disconnessa in destinazione, altrimenti rompi il voice in entrambi. Gli agent vanno cancellati e riconnessi all’ambiente di destinazione: riconnettere lo stesso agente altrove rompe l’ambiente di origine. Infine, per far riflettere i dati giusti nei report, disattiva e riattiva Enable Omnichannel real-time analytics e Enable Omnichannel historical analytics report nel Copilot Service admin center. Dopo un reset, un restore o una migrazione tenant-to-tenant, invece, devi rifare il provisioning dei canali o riabilitare l’unified routing.