Un oggetto appena creato è una tabella isolata. «Estenderlo» vuol dire quattro cose che l’esame mescola nello stesso scenario: collegarlo ad altri oggetti (relazioni), far convivere processi diversi sullo stesso oggetto (record type), mostrare i record figli nel modo giusto (related list), e costruire tutto questo senza codice (Schema Builder, Lightning Object Creator). La domanda utile non è «quale funzionalità conosco», ma «che cosa deve essere vero dei dati».
Lookup o master-detail: decide la dipendenza, non la comodità
Un lookup «essentially links two objects together so that you can “look up” one object from the related items on another object». Nel master-detail «the master object controls certain behaviors of the detail object, like who can view the detail’s data», e il figlio «doesn’t work as a stand-alone».
| Lookup | Master-detail | |
|---|---|---|
| Autonomia del figlio | vive da solo | non ha senso senza il master |
| Owner e visibilità | owner e org-wide default propri | nessun owner: sharing dal master, OWD Controlled by Parent |
| Cancellazione del padre | il figlio resta, il campo si svuota | cascata sui figli |
| Roll-up summary sul padre | no | sì |
| Campo relazione | può essere opzionale | sempre obbligatorio sul detail |
| Cambio di padre | libero | solo con Allow reparenting attivo |
Da qui lo scenario classico: figlio legato al padre da un lookup, org-wide default Private e sharing rule mantenute a mano perché chi vede il padre veda i figli. Il difetto non è la sharing rule: è la relazione. Con un master-detail la visibilità del figlio è quella del padre. La conversione è però possibile solo se ogni record figlio ha il campo relazione valorizzato.
Puntare un oggetto a sé stesso
Per una gerarchia sullo stesso oggetto — una Position che «riporta» a un’altra Position — si crea un campo Lookup Relationship e in Related To si sceglie lo stesso oggetto. Il passo che l’esame guarda è il nome della related list: Trailhead chiama il campo Related Position e il Child Relationship Name Related Positions, ed è quest’ultimo il testo che compare sul padre. Due lookup filter completano il quadro: stesso Department, e Position: Record ID diverso da Related Position: Record ID, così un record non punta a sé stesso.
Molti-a-molti: il junction object
Quando la relazione va in entrambe le direzioni (ogni Position su molti siti, ogni sito con molte Position) non basta un campo solo: serve un terzo oggetto custom con due master-detail, uno per padre. La prima relazione creata è la primaria e governa owner e sharing del record di giunzione; cancellare uno qualsiasi dei due padri porta via i record del junction object.
Lookup filter: restringere ciò che si può scegliere
«Lookup filters limit the records available in the lookup.» I criteri possono guardare altri campi del record di partenza, campi dei record dell’oggetto puntato, e campi dell’utente, del suo profilo e del suo ruolo — ed è quest’ultima famiglia che permette «solo i record della mia divisione». Si configura sul campo, non sull’oggetto: Setup → Object Manager → oggetto → Fields & Relationships → il campo lookup → Show Filter Settings, con messaggio d’errore personalizzabile.
La scelta che conta è il Filter Type: un filtro optional governa ciò che la finestra di lookup propone, ma l’utente può chiedere di vedere tutti i risultati e salvare comunque; un filtro required è un vincolo sul dato, respinto anche quando il valore arriva da import o da API. Se lo scenario dice «i record sbagliati non devono proprio entrare», la risposta è Required.
Record type: stesso oggetto, processi diversi
Un record type si crea da Setup → Object Manager → oggetto → Record Types → New, partendo da Master o da un record type esistente. Tre passi, tre effetti distinti:
- nella colonna Make Available si selezionano i profili che potranno usarlo;
- si sceglie il page layout da applicare, uno per tutti i profili oppure uno per profilo;
- dopo il salvataggio, per ogni picklist si decide quali valori entrano nella Selected Values di quel record type.
Il terzo passo è la fonte di metà delle domande: un valore nuovo aggiunto al value set non diventa automaticamente disponibile a tutti i record type. Se un record type lo mostra e l’altro no, non è field-level security né un permesso di profilo.
L’altra metà riguarda la schermata di scelta. Dopo New l’utente la vede solo se il suo profilo ha almeno due record type abilitati; con uno solo — o se nelle impostazioni personali ha chiesto di non rivedere quella pagina — va dritto al layout di default. Creare il record type, dargli un layout e mettere il campo Record Type sul layout non basta: manca l’abilitazione sul profilo.
Related list: page layout o Lightning App Builder
Il page layout editor serve a «control which lists of related records and custom links users see» e a «control which standard and custom buttons appear on records and related lists», e si assegna «to a combination of Lightning apps, record types, and profiles». È quindi condiviso: se due profili usano lo stesso layout, un campo aggiunto arriva a entrambi, e l’unica via per servirne uno solo è clonare il layout e cambiare l’assegnazione.
| Related list sul page layout | Dynamic Related List–Single | |
|---|---|---|
| Dove si configura | page layout editor | Lightning App Builder |
| Filtri sui record mostrati | no | sì, Related List Filters → Add Filter |
| Colonne | sì | sì, Related List Fields, riordinabili |
| Ordinamento | sì | Sort Field + Sort Order (Ascending/Descending) |
| Numero di record | fisso | Number of Records to Display |
| Due liste dello stesso oggetto figlio | no | sì, due componenti con filtri diversi |
È la riga decisiva: due elenchi dello stesso oggetto figlio sulla stessa pagina — uno sugli aperti, uno sugli scaduti, con colonne e ordinamenti diversi — si ottengono solo con il componente dinamico, che dà «freedom from the page layout editor».
Schema Builder e Object Creator: due strumenti, due scopi
Schema Builder «is a tool that lets you visualize and edit your data model». Trascinare un oggetto sul canvas è solo disegno: «This doesn’t change your objects or relationships». Si crea dalla scheda Elements, trascinando un elemento Object oppure un tipo di campo sull’oggetto: «you can create relationship fields, formula fields, and normal fields». Il campo nasce sull’oggetto su cui lo lasci cadere, quindi un lookup trascinato sul figlio crea il figlio. In un’org grande il canvas apre illeggibile: la cura è Clear All e poi la spunta sui soli oggetti che servono, con Auto-Layout a rimetterli in ordine.
Lightning Object Creator parte invece da dati che esistono già: «allows any user to quickly turn spreadsheets—such as Microsoft Excel, Quip Spreadsheets, Google Sheets, and comma-separated value (.csv) files—into modern, cloud-based apps». Si lancia da Setup → Object Manager → Create → Custom Object from Spreadsheet: ispeziona il foglio, propone nome e tipo di ogni campo (modificabili) e chiede Label, Plural Label e API Name. Il risultato è un oggetto custom con il suo tab e i record già importati, senza definire i campi uno a uno. Il tab però compare nell’app solo dopo averlo aggiunto da Setup → App Manager → app → Navigation Items, dove spesso serve prima Refresh.
Trappole tipiche d’esame
- Sharing rule mantenute a mano su un figlio in lookup. Se lo scenario descrive manutenzione continua per far vedere i figli a chi vede il padre, la risposta è il master-detail (sharing e owner ereditati), non una sharing rule scritta meglio; e la conversione richiede il campo relazione valorizzato su tutti i figli.
- Valore di picklist visibile su un record type e non sull’altro. Non è field-level security né un permesso di profilo: il valore va aggiunto ai
Selected Valuesdel record type che non lo mostra. - Record type creato ma mai proposto. Layout associato e campo
Record Typesul layout non fanno comparire la schermata di scelta: serve l’abilitazione sul profilo, con almeno due record type disponibili. - Campi in più per un solo profilo su un layout condiviso. Toccare quel layout serve entrambi i profili: si clona e si cambia l’assegnazione per quel profilo su quel record type.
- Due related list dello stesso oggetto figlio con filtri diversi. Il page layout ne ammette una: la coppia filtrata si ottiene con due componenti Dynamic Related List–Single.
- Schema Builder preso per una vista statica, o per una cura al disordine. Trascinare oggetti esistenti non modifica nulla, ma dalla scheda Elements si creano davvero oggetti, campi e relazioni; un canvas illeggibile si sistema filtrando gli oggetti visualizzati.