Estendere il modello dati e l'interfaccia

Estendere con la configurazione, prima che con il codice

Customer Service è un’app model-driven che poggia su Dataverse: ogni case, ogni queue, ogni knowledge article è un record in una tabella della piattaforma. Il dominio “Extend Customer Service” pesa meno degli altri, ma è quello dove l’esame verifica se sai scegliere lo strumento minimo sufficiente: si estende con la configurazione dichiarativa (tabelle, colonne, relazioni, form, view, business rule) e si scende al codice (plug-in, custom control) solo quando la configurazione non copre il requisito. A parità di risultato, in una domanda a scelta multipla la risposta low-code batte quasi sempre quella con codice. Ricorda anche il contenitore: le personalizzazioni vivono in una solution, si sviluppano in un ambiente non gestito e si distribuiscono altrove come managed. Il passing score dell’esame è 700/1000.

Tabelle, colonne, relazioni

La prima scelta è il tipo di tabella. Una standard table conserva dati di business; una activity table eredita il comportamento delle attività (compare nella timeline, ha regarding, mittente e destinatario) ed è la scelta giusta quando il record rappresenta un’interazione; una virtual table espone dati esterni senza copiarli. La seconda scelta è l’ownership: user/team owned abilita la sicurezza a livello di riga e la condivisione, organization owned no. È una decisione strutturale, non un’impostazione da rivedere a cuor leggero dopo il rilascio.

Sulle colonne l’esame gioca sulle differenze: una choice può essere globale (riusabile) o locale alla tabella; una lookup non si crea da sola, nasce dalla relazione; una calculated column valuta un’espressione alla lettura, una rollup column aggrega record correlati ma si ricalcola in modo asincrono e schedulato. Una alternate key serve quando devi identificare un record con una chiave esterna (upsert, deduplica in integrazione).

Le relazioni 1:N portano con sé i cascade behavior: Parental propaga assegnazione, condivisione, eliminazione e reparenting ai figli; Referential li lascia indipendenti; la configurazione personalizzata permette di scegliere azione per azione. Le N:N native associano record senza attributi propri: se la relazione deve portare dati (un ruolo, una data, una nota), serve una tabella intermedia con due lookup.

Form e view

I form non sono intercambiabili. Il main form è l’esperienza completa, a tab, dove agiscono business rule e componenti; il quick create form serve la creazione rapida e richiede che la tabella la consenta; il quick view form mostra in sola lettura i campi di un record correlato tramite lookup, ed è la risposta tipica a “mostrare i dati del cliente dentro il case senza permetterne la modifica”; il card form rende compatte le righe nelle liste e nelle esperienze mobile. Su una stessa tabella possono coesistere più main form con ordine e security role diversi, così ruoli diversi vedono layout diversi.

Le view definiscono colonne, ordinamento e filtri. Distingui personal view (create e condivise dall’utente) dalle system view; e tra le system view riconosci i ruoli speciali: Lookup view, Associated view e soprattutto Quick Find view, che governa la ricerca sulla griglia e le colonne di ricerca della tabella.

Dataverse search, notifiche in-app, template di email

La Dataverse search è la ricerca unificata dell’ambiente: si abilita a livello di environment, poi ogni tabella va inclusa nell’indice, e le colonne considerate — sia quelle su cui si cerca sia quelle restituite nel risultato — dipendono in larga parte dalla configurazione della Quick Find view. Una tabella custom non trovata dalla ricerca è quasi sempre un problema di indicizzazione, non di permessi.

Le notifiche in-app vanno abilitate sull’app model-driven e recapitano a un utente specifico un messaggio con titolo, corpo, icona, eventuale azione e scadenza. Sono avvisi puntuali dentro il prodotto: non sostituiscono l’email né sono il meccanismo con cui un SLA notifica il ritardo.

I template di email standardizzano le risposte: possono essere globali o legati a una tabella (e in quel caso i placeholder dinamici risolvono i campi di quel record). Vengono richiamati da automatismi come le regole di creazione e aggiornamento automatico dei record, le warning e success action degli SLA item, o la comunicazione di risoluzione di un case.

Trappole tipiche d’esame

• Mostrare i dati del cliente dentro il form del case in sola lettura → quick view form: il quick create serve a creare in fretta, non a visualizzare un record correlato; e un main form embedded non è la risposta attesa.
• Un conteggio di record correlati che deve essere corretto all’istante → non una rollup column: le rollup si ricalcolano in modo asincrono e schedulato; se il requisito dice “in tempo reale”, la rollup è la risposta sbagliata.
• La tabella custom non compare nella ricerca globale → indicizzazione, non sicurezza: va inclusa nella Dataverse search e va sistemata la Quick Find view; aggiungere colonne a una view pubblica non la rende ricercabile.
• Eliminando il record padre devono sparire i figli → cascade behavior della relazione 1:N: è configurazione della relazione, non un flusso o un plug-in di pulizia.
• La relazione deve memorizzare informazioni proprie → non una N:N nativa: serve una tabella intermedia con due lookup, perché la N:N di piattaforma non ospita colonne aggiuntive.
• Avvisare una singola persona su un record specifico → notifica in-app, non template di email: e attenzione al vocabolario, la persona che lavora il case è il representative, mentre “agent” in questo esame indica un agente AI.