Dall’account Microsoft 365 all’utente in Dataverse
Il punto di partenza non è Dynamics: è il Microsoft 365 admin center. Lì crei l’account, che registra la persona nell’ambiente Microsoft Online Services, e gli assegni una licenza. Senza licenza l’account esiste ma non accede al servizio. La documentazione è esplicita su un secondo passaggio che molti danno per scontato: con user ID e password l’utente può entrare nel Microsoft 365 admin center e vedere informazioni sul servizio, ma non ha accesso alle customer engagement app finché non gli viene assegnato un security role, direttamente oppure come membro di un team.
Da lì la sincronizzazione verso Dataverse è automatica ma non istantanea. Il record nella tabella SystemUser viene creato da un processo di background periodico, oppure al primo tentativo di accesso dell’utente all’ambiente, oppure su richiesta dell’amministratore dal Power Platform admin center (Settings, poi Users + permissions e Users). Se all’ambiente è associato un security group, l’utente deve farne parte o non entra. Chi riceve il ruolo di global administrator o service administrator ottiene in automatico il security role System Administrator.
Poi viene la parte specifica del contact center. Nell’esperienza classica, sulla scheda Omnichannel del record utente, imposti la Default Presence (lo stato con cui il representative risulta collegato in Copilot Service workspace) e la Capacity, se stai usando le capacity unit. Soprattutto: l’utente va configurato come bookable resource, altrimenti unified routing non gli assegna lavoro e non puoi nemmeno associargli un capacity profile.
Security role, ruoli custom e persona
I ruoli disponibili per Dynamics 365 Contact Center sono Basic User (richiesto a tutti), Omnichannel administrator, Omnichannel supervisor, Omnichannel agent, più Productivity tools user e Productivity tools administrator, App Profile Manager Administrator e App Profile User. Due avvertenze messe nero su bianco: il ruolo Omnichannel API access non va assegnato a un utente di tipo supervisor o representative, e per lavorare sui case serve il ruolo Customer Service Representative — ed è qui che i due prodotti divergono, perché i case sono materia di Dynamics 365 Customer Service. Simmetricamente, sul lato Copilot Service workspace i privilegi di App Profile User sono già inclusi out of the box nei ruoli Customer Service Representative e CSR Manager, mentre in Dynamics 365 Contact Center sono inclusi in Omnichannel agent e Omnichannel supervisor.
Attenzione al vocabolario. Il ruolo si chiama Omnichannel agent e la persona si chiama Agent, ma descrivono la persona in carne e ossa, cioè il representative; nel prodotto il termine agent indica ormai l’agente AI. I nomi dei ruoli non sono stati rinominati, e l’esame gioca volentieri su questa sfasatura.
Le persona — admin, supervisor e agent — sono archetipi a cui si mappano i security role per definire i permessi in unified routing. Il mapping vive in Copilot Service admin center, voce User management dentro Customer support, poi Manage per Role persona mapping: selezioni la persona, apri il pannello Edit roles, spunti i ruoli e fai Save and Close. Serve il ruolo System Administrator.
Per un ruolo custom la procedura consigliata è partire da una copia di un ruolo esistente — Omnichannel Administrator, Omnichannel supervisor, Omnichannel agent, CSR Manager o Customer Service Representative — così da non rischiare di sotto-assegnare privilegi, poi restringere gli accessi e assicurarsi che il ruolo porti il privilegio prvAgent, prvSupervisor o prvAdmin a seconda dell’archetipo. Due trappole: i ruoli da mappare alle persona vanno assegnati agli utenti direttamente e non tramite appartenenza a un team; e la mappatura da sola non dà accesso ad app e dashboard, che si abilitano a parte con MANAGE ROLES sul tile dell’applicazione.
Capacity profile: quanto lavoro regge un representative
Un capacity profile definisce tipo e quantità di lavoro che un representative può prendere. Si crea da User management, Manage per Capacity profile, poi Create new. Nella scheda Details compili Profile name, Work item limit e Reset frequency, che vale Immediate oppure End of day: con End of day la capacità si azzera a fine turno anche se il representative non ha chiuso tutte le conversazioni assegnate. Il toggle Assignment blocking su Yes blocca l’assegnazione automatica di nuovo lavoro al raggiungimento del limite, comprese le work item a capacity unit, e porta la presence a Busy-DND.
Un dettaglio che è materiale da domanda: la reset frequency non si modifica dopo la creazione. Puoi aggiungere o togliere utenti e cambiare qualsiasi altra impostazione, ma per cambiare quella devi ricreare il profilo.
Gli utenti si aggiungono dalla scheda Users e devono essere bookable resource. Per il lavoro di massa c’è Enhanced user management, che nella vista Contact center users aggiorna skill, code e capacity profile fino a 200 utenti alla volta e fino a cinque attributi per volta. Lì imposti anche il Custom limit, un limite diverso dal default per singoli representative: si applica solo alle nuove assegnazioni, non riassegna il lavoro già in corso, e la sincronizzazione può richiedere fino a 15 minuti. Esiste poi un escalation profile disponibile out of the box e non modificabile, che si attacca al work item quando una chat viene escalata a chiamata voce o video. Nota infine la raccomandazione ufficiale: capacity profile oppure capacity unit, non entrambi.
Tre oggetti diversi, tre posti diversi
Qui l’esame piazza la trappola più prevedibile. Il capacity profile decide quanto lavoro concorrente arriva, e si assegna da User management. Il security role decide che cosa l’utente può leggere e scrivere, e si assegna sul record utente o al team. L’experience profile decide come si presenta il desktop — session template, productivity pane, inbox, channel provider — e si configura in Copilot Service admin center sotto Support experience, Workspaces, Experience profiles, dove aggiungi gli utenti oppure usi Set rank and roles; per crearli serve il ruolo App Profile Manager Administrator, che va assegnato a mano.
Tradotto in scenari: se il quesito dice che il representative vede il desktop giusto ma riceve troppe conversazioni, la risposta è capacity profile. Se riceve il numero giusto di conversazioni ma non vede il pannello Copilot, è experience profile. Se non vede proprio i record, è security role. E se il routing non lo considera affatto, torna al passaggio più banale: quell’utente è configurato come bookable resource?