Un’app Salesforce è «a collection of items that work together to serve a particular function»: un nome, un logo, una navigation bar, una utility bar e i profili che possono aprirla. Non contiene campi, non contiene sicurezza, non contiene record — contiene scorciatoie. Sapere dove finisce l’app e dove comincia la pagina risolve metà degli scenari di questo punto d’esame.

App Manager: cosa vive dentro l’app

In Setup → App Manager convivono app Classic e Lightning. La colonna che conta è Visible in Lightning Experience: un’app senza spunta è un’app Classic, «enabled only for our Salesforce Classic UI», e nell’App Launcher di Lightning Experience non comparirà mai, per nessun profilo. Non è un permesso mancante né la visibilità delle tab: la risposta è creare una New Lightning App.

I passi del wizard sono l’elenco esatto di ciò che si definisce nell’app stessa:

Passo Cosa definisci
App Details & Branding nome, descrizione, logo custom, colore del brand
App Options Standard navigation oppure Console navigation
Utility Items la utility bar: History, Macros, Notes, Flow
Navigation Items oggetti, tab e list view della navigation bar, e il loro ordine
User Profiles quali profili possono aprire l’app

Fuori dall’app restano page layout, record type, field-level security e assegnazione delle record page: sono proprietà dell’oggetto. L’unico ponte è che una record page può essere attivata per una specifica app.

Standard contro console navigation

La scelta si fa nell’app, non nella pagina.

Standard Console
Apertura di un record sostituisce quello corrente workspace tab, con i correlati come subtab dentro di essa
Lavoro in parallelo un record alla volta più record aperti, ognuno col suo contesto
Split view e template dedicati no sì (header bloccato, regioni pinned)

Lo scenario tipico — «l’operatore apre il contatto legato al caso e il caso deve restare aperto», con History e Macros a portata di mano — si risolve con Console navigation più la configurazione, in Navigation Items, dei Contact come subtab del padre. Non è un’impostazione della record page.

Lightning App Builder: pagine, template, attivazione

L’App Builder costruisce tre tipi di Lightning page: app page, home page e record page. «A Lightning page is composed of regions that contain components»: è il template a decidere quante regioni esistono. I componenti sono standard (Salesforce), custom (LWC o Aura) o presi dal marketplace; sulla record page ricorrono Highlights Panel, Path, Tabs, Accordion, Record Detail, Related Lists, Chatter, Activity. Dentro Tabs le schede non si trascinano: «You can only adjust them in the properties pane».

Salvare non attiva. In Activation ci sono org default, default di una o più app, combinazione app + record type + profilo, e per ognuna il form factor (Desktop o Phone). Il form factor è la risposta a «stessa app, stessi profili, stesso record type, ma da telefono serve una pagina più corta»: seconda record page, attivata per Phone.

E Assign as Org Default è la scelta più pericolosa dell’App Builder: vale per tutte le app. Una pagina costruita con un template da console, resa org default, arriva anche agli utenti dell’app Sales, che aprono i casi da un’app a navigazione standard e si ritrovano una pagina mutila. Una pagina da console si assegna all’app console.

Dynamic Forms

Dynamic Forms «breaks the Record Detail component on your Lightning pages into individual field and section components that you can put anywhere on the page». Si seleziona Record Detail e si clicca Upgrade Now; il wizard chiede da quale page layout importare campi e sezioni. Da lì ogni Field Section e ogni campo sono componenti autonomi, collocabili in regioni e tab diverse; dalla palette Fields si scende nei lookup per portare in pagina campi cross-object.

Due cose da tenere ferme. La migrazione non svuota il page layout: quel layout continua a governare le related list ereditate, i bottoni standard e custom e le quick action della sezione Salesforce Mobile and Lightning Experience Actions. E Record Detail non convive coi campi singoli sulla stessa pagina: se il blocco monolitico è ancora lì, va tolto.

Dynamic Forms richiede inoltre che l’oggetto sia supportato: se nella palette manca la tab Fields e sul Record Detail non c’è Upgrade Now, quell’oggetto usa ancora il page layout e nessuna configurazione lo aggira. L’elenco si è allargato release dopo release — verificalo nella tua org, non su una lista scritta altrove.

Dynamic Related List - Single è il gemello emancipato del vecchio Related List - Single: si trascina dalla palette, o si ottiene selezionando quello legacy e premendo Upgrade Now.

Related list da page layout Dynamic Related List - Single
Dove si configura page layout editor Lightning App Builder
Colonne, ordinamento, numero di record sì sì
Filtri sui record mostrati no sì
Titolo custom, più liste filtrate dello stesso oggetto no sì
Regole di visibilità del componente no sì
Tipo di lista List view List view o Tile view (meno campi visibili)

«The only way to customize related list filters is to use the Dynamic Related List-Single component.» Le avvertenze che l’esame usa stanno dall’altra parte: il componente vale per i custom object e per gli oggetti abilitati a LWC, e la documentazione lo dichiara desktop only.

Le regole di visibilità non sono sicurezza

Componenti, field section e singoli campi accettano visibility rule su: valore di un campo del record, campi dell’utente che guarda ($User), profilo o permesso ($Permission), form factor del device; con più filtri si sceglie fra All filters are true e Any filters are true. Le regole sui campi sono valutate dinamicamente, anche durante l’inline editing; quelle sulle sezioni solo dopo il salvataggio. Se le regole nascondono tutti i componenti di una regione, la regione resta vuota.

La trappola vera: nascondere un campo sensibile con una visibility rule non lo protegge. Resta nei report, nelle list view, nella ricerca, nell’API e su ogni altra pagina. Per negare l’accesso serve la field-level security.

Componenti custom e misura delle prestazioni

Un LWC deployato si vede in Setup ma non compare nella palette finché il file di configurazione del bundle non lo espone all’App Builder e non dichiara il target della pagina (record page, app page, home page). È una correzione dello sviluppatore: non è un permesso, non è la FLS, non è il profilo.

Per misurare il caricamento di una pagina, Salesforce dà strumenti che restituiscono l’EPT (Experience Page Time), «the time it takes to download and display the entire content of a webpage in a browser window»:

  • il contatore EPT in Lightning Experience, via Lightning Component Debug Mode (che però rallenta la pagina: niente minificazione né cache) o aggiungendo ?eptVisible=1 all’URL, a impatto minimo;
  • la Lightning Usage App, che aggrega tempi per pagina e per browser;
  • i report custom sull’oggetto LightningUsageByBrowserMetrics;
  • l’Event Monitoring di Salesforce Shield, con l’event type Lightning Page View.

Diverso è il bottone di analisi della pagina nell’App Builder: non misura niente di reale, valuta il progetto — quanti campi, quante tab, quanti componenti, Visualforce incorporata — e avvisa prima dell’attivazione. È una previsione a tempo di configurazione, non una misura; essendo recente, nome e posizione possono differire nella tua org.

Trappole tipiche d’esame

  • App senza spunta in Visible in Lightning Experience. È un’app Classic: non apparirà nell’App Launcher qualunque cosa faccia il profilo. Si crea una Lightning app nuova.
  • «Deve restare aperto mentre ne apro un altro». È Console navigation nelle App Options, coi Contact configurati come subtab. Non è un template di pagina né un componente.
  • Assign as Org Default su una pagina da console. L’org default vale per ogni app: gli utenti a navigazione standard ereditano una pagina pensata per la console. Va assegnata all’app console.
  • Dynamic Forms non manda in pensione il page layout. Dopo la migrazione il layout governa ancora related list, bottoni e quick action; se sul Record Detail non c’è Upgrade Now, quell’oggetto non è supportato.
  • Related list dinamiche ovunque. Sono desktop only e solo sugli oggetti abilitati a LWC: in cambio dei filtri si perde copertura.
  • Visibility rule usata come sicurezza. Nascondere una sezione a chi non ha un permesso non toglie il campo da report, list view, ricerca e API. Serve la field-level security.
  • Misurare contro prevedere. EPT (contatore, Lightning Usage App, report su LightningUsageByBrowserMetrics, Event Monitoring) misura; il bottone di analisi dell’App Builder stima il progetto, non produce un tempo confrontabile fra pagine.