Page layout, record type e Lightning App Builder

In Lightning Experience una record page non è governata da un solo strumento. Il page layout editor (Object Manager, Page Layouts) e il Lightning App Builder convivono sulla stessa pagina e fanno cose diverse: capire chi controlla cosa è metà del punto d’esame, perché gli scenari sono quasi sempre costruiti su “l’amministratore ha cercato nel posto sbagliato”.

Chi controlla cosa

Il caso più insidioso è quello delle related list. Il componente Related Lists dell’App Builder è solo il contenitore: decide dove compaiono le liste, non quali. Se manca la related list Contacts sulla Account record page, la si aggiunge nel page layout editor, sezione Related Lists del layout assegnato a quell’utente. Nell’App Builder si regola semmai il tipo di lista (Basic List mostra pochi campi, Enhanced List di più, con ordinamento e azioni di massa).

Il compact layout è un terzo strumento ancora: governa i campi del highlights panel, quelli della card che appare passando sopra un campo lookup e quelli della timeline delle attività. Il primo campo va in evidenza, quindi conviene metterci il Name; quanti ne entrino dipende dallo schermo, ma l’importante è sapere che il highlights panel non si tocca dal page layout editor.

Creare e assegnare un page layout

Il layout si crea da Object Manager, oggetto, Page Layouts, New, di solito clonando un layout esistente (Existing Page Layout); dentro si trascinano sezioni, campi, related list, report chart e le due sezioni delle azioni.

Ma un layout non serve a nulla finché non è assegnato. Page Layout Assignment è una matrice profilo per record type: ogni cella punta a un layout. Due profili possono quindi vedere lo stesso record type con layout diversi, e viceversa. Anche il compact layout si assegna per record type.

Record type e business process

Un record type determina tre cose: quali valori di picklist sono disponibili, quale page layout si applica (per profilo) e quale business process si segue. Serve quando lo stesso oggetto ospita casistiche diverse: Customer Account e Partner Account, Product Support e Inquiry.

Il business process è il pezzo che si dimentica: esiste solo su quattro oggetti e governa i valori del campo di stato principale.

L’ordine di costruzione conta, ed è quello che l’esame verifica: prima il business process, poi il record type che lo referenzia, poi il page layout e i valori di picklist. Creando il record type si sceglie il processo, si spunta Make Available per i profili che potranno usarlo e si assegna il layout (Apply one layout to all profiles, oppure uno diverso per profilo). Solo dopo, da Picklists Available for Editing, si restringono i valori delle altre picklist. Nota che Make Available rende il record type disponibile: quale sia quello di default per un utente si imposta nelle record type settings del profilo o del permission set.

Lightning record page: creazione e attivazione

Una Lightning record page si crea dall’App Builder (New, poi Record Page, oggetto e template), da un record aperto con Setup e Edit Page, o clonandone una esistente. Salvare non basta: finché non la attivi, non la vede nessuno. In Activation hai quattro strade:

1. renderla org default per l’oggetto;
2. renderla default per una o più app Lightning;
3. assegnarla a una combinazione di app, record type e profilo;
4. in tutti i casi, scegliere il form factor: desktop, phone, o entrambi.

È la terza strada la risposta agli scenari del tipo “solo il profilo Sales User, solo sul record type Customer, solo dentro l’app Sales, gli altri restano come sono”: Assign to Apps, Record Types, and Profiles. Più l’assegnazione è specifica, più prevale; l’org default è l’ultima spiaggia. Per disfarla si usa Remove Assignments, non si cancella la pagina.

Dynamic Forms e regole di visibilità

Con Dynamic Forms il blocco monolitico Record Detail si spezza in singoli componenti Field e Field Section, posizionabili ovunque, anche dentro tab e accordion. La migrazione parte selezionando il componente Record Detail e cliccando Upgrade Now: il wizard chiede da quale page layout prendere campi e sezioni. Da quel momento quei campi si gestiscono nell’App Builder e non più nel page layout editor, che resta necessario per related list, azioni e bottoni. Attenzione: i campi universalmente obbligatori assenti dal layout di partenza non vengono migrati, e vanno aggiunti a mano. È una funzionalità recente e non copre tutti gli oggetti: se manca la tab Fields nel palette, quell’oggetto usa ancora il page layout.

Le visibility rule si applicano a componenti, campi e sezioni. I criteri disponibili sono:

• valore di un campo del record, per esempio Amount maggiore o uguale a una soglia, oppure Stage uguale a Closed Won;
• utente che sta guardando: campi dello user, profilo, permessi ($User, $Permission);
• device, cioè il form factor: Desktop, Phone, Tablet.

Con più filtri si sceglie la logica (All filters are true oppure Any filters are true). Due comportamenti da ricordare: le regole sui campi sono valutate dinamicamente, anche durante l’inline editing, mentre quelle sulle sezioni solo dopo il salvataggio; e se le regole nascondono tutti i componenti di una regione, la regione resta vuota.

Quick action e global action

Se lo scenario dice “dal record che sto guardando, aggiorna un campo di questo record”, la risposta è una object-specific action di tipo Update a Record messa sul page layout dell’oggetto: una global action non aggiorna nulla. Ogni azione ha un proprio action layout e può avere predefined field values che precompilano i campi; togliere un campo obbligatorio dall’action layout senza dargli un valore predefinito impedisce di completare l’azione. Se la sezione azioni del page layout non viene personalizzata, le azioni sul record si ereditano dal global publisher layout; una volta sovrascritta, anche i bottoni standard e custom vanno inseriti lì come azioni.

Trappole tipiche d’esame

• Manca una related list e il componente Related Lists c’è già. Si va nel page layout editor, sezione Related Lists del layout assegnato a quel profilo e record type. L’App Builder non crea related list, le ospita soltanto.
• Stati diversi per tipi di caso diversi. Non bastano i record type: servono due support process (che definiscono i valori di Status), poi due record type che li referenziano, poi i due page layout.
• “Assegnare un layout” non è “assegnare una record page”. Il page layout si assegna per profilo e record type; la Lightning record page per app, record type, profilo e form factor. Due assegnazioni distinte, spesso da fare entrambe.
• Un solo page layout con oltre cento campi e team diversi. La risposta è Dynamic Forms (Upgrade Now sul componente Record Detail) più le visibility rule, non moltiplicare layout e record type.
• Criteri di visibilità. Valore dei campi del record, utente che guarda (profilo e permessi), form factor del device. Non sono criteri il ruolo nella role hierarchy né l’owner: il record type entra in gioco nell’assegnazione della pagina, non come filtro di un componente.
• Global action che “aggiorna”. Non esiste: le global action creano record, registrano chiamate o inviano email, e il record creato non è collegato a nulla. L’aggiornamento è prerogativa delle object-specific action, esposte sul page layout dell’oggetto.