Il ciclo di vita del case e le regole che lo alimentano

Un case è il record di servizio che traccia una richiesta dalla presa in carico alla chiusura, da non confondere con la conversation, la sessione di dialogo su un canale. Si classifica con subject, product e priority, può essere legato a un entitlement e può vivere in una relazione parent-child con propagazione configurabile. La queue è il contenitore dove il lavoro attende; il workstream governa invece l’ingresso e la classificazione di ciò che arriva dal canale.

L’automazione d’ingresso più esaminata è la record creation and update rule: agganciata a una queue e a un source type, trasforma un’attività in arrivo in un record, tipicamente un case. Il nome dice tutto: la regola non si limita a creare. La seconda metà, update, riconosce che l’attività appartiene a un record già esistente e la accoda lì invece di duplicarlo, il caso classico della risposta del cliente su un case ancora aperto. I rule item portano le condizioni e sono valutati in ordine; le channel property riversano i valori dell’attività sulle colonne del record. La regola va attivata per avere effetto ed è legata a una specifica combinazione di queue e source type: canali diversi si governano agendo su quella combinazione.

Chiudere un case: la tabella Case Resolution

Ogni chiusura genera un record a sé sulla tabella Case Resolution, non un semplice cambio di stato: il case passa a Resolved e nasce un record di risoluzione con descrizione, resolution type e tempi (billable time, total time). La conseguenza è ciò che l’esame verifica: i dati raccolti alla chiusura, come causa radice o codice di garanzia, vanno come colonne su Case Resolution, perché è lì che il valore viene scritto. E per vederle nel dialogo serve abilitare l’esperienza di case resolution personalizzabile, che sostituisce la finestra classica con un form gestibile come ogni altro form Dataverse, con validazioni e logica custom.

Ruoli di sicurezza: privilegi e livelli di accesso

Un ruolo di sicurezza è una matrice: per ogni tabella un insieme di privilegi (Create, Read, Write, Delete, Append, Append To, Assign, Share) e per ciascun privilegio un livello di accesso (nessuno, utente, business unit, business unit padre-figlie, organizzazione). I due assi sono indipendenti, ed è da lì che nascono i requisiti d’esame: “il representative vede i case dei colleghi ma modifica solo i propri” significa Read a livello business unit e Write a livello utente sulla stessa tabella. I ruoli sono cumulativi: chi ne ha più d’uno, diretto o ereditato da un team, ottiene l’unione dei privilegi e il livello più ampio. Accanto ai ruoli agiscono la proprietà del record, le business unit e lo sharing, che concede accesso a un singolo record senza toccare il ruolo; le identità restano in Microsoft Entra ID.

Timeline control e card form

Il timeline control è il diario del record: email, phone call, task, appointment, note e post in ordine cronologico. La sua configurazione sul form decide quali record entrano, l’ordinamento e i filtri disponibili. Il livello sotto è quello che l’esame chiede più spesso: il contenuto della singola voce è deciso dal card form della tabella dell’attività, non dal main form del case. Se ogni phone call deve mostrare anche l’esito, si modifica il card form di Phone Call e la timeline cambia ovunque, senza toccare il form principale. Sulla stessa base lavorano i riepiloghi di timeline, case e conversation generati dagli agent AI nel Copilot Service workspace.

Trappole tipiche d’esame

  • Le risposte dei clienti aprono un nuovo case ogni volta → record creation and update rule: la parte update accoda l’attività al case esistente, senza flow custom né seconda regola.
  • Serve registrare la causa radice alla chiusura → colonna sulla tabella Case Resolution: il dato di chiusura vive sul record di risoluzione, non sul case.
  • La colonna esiste su Case Resolution ma il dialogo non la mostra → esperienza di case resolution personalizzabile: senza abilitarla resta la finestra classica, con i soli campi standard.
  • Vedere i case della business unit ma modificare solo i propri → livelli diversi per Read e Write: stessa tabella, Read a livello business unit e Write a livello utente.
  • Restringere chi ha già un ruolo ampio → rimuovere il ruolo, non aggiungerne uno stretto: i privilegi si sommano e vince sempre il livello di accesso più ampio.
  • Cambiare le informazioni mostrate da ogni voce di timeline → card form dell’attività: il timeline control decide cosa entra e in che ordine, la card cosa si legge dentro.