Le relazioni hanno conseguenze

🌐 Disponibile anche in 28 lingue

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Immagine generata con l'IA

Tradotto con l'IA. Non ancora rivisto dalla comunità. Leggi in inglese

Modulo 7 di 10 del capitolo Architettura dei dati Salesforce, capitolo 3 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Anche i campi sono architettura · Successivo: Titolarità e ciclo di vita

La domanda a cui risponde questo modulo: Cosa sto scegliendo davvero quando collego due oggetti Salesforce?

Disegnare una relazione è facile. Nel capitolo 2 abbiamo tracciato linee e dato loro un nome: un Partner retail invia molti manifesti di carico, una consegna porta molti articoli, squadre e camion si incontrano in un’Assegnazione della squadra. Abbiamo parlato di cardinalità, opzionalità e storico. Ora implementiamo quelle linee su Salesforce, e una linea in un diagramma inizia a portare molto più peso.

Quando scelgo un tipo di relazione su Salesforce, non sto solo dicendo questi due record sono collegati. Posso anche decidere chi è titolare del figlio, se può esistere senza il padre, chi può vederlo, cosa succede quando il padre viene eliminato, se può passare a un altro padre, se posso riepilogarlo sul padre, e cosa succede quando i figli sono centinaia di migliaia. Una relazione non è solo una linea. Porta con sé un comportamento.

Parti dalla relazione di business

Prima di relazione di ricerca o master-dettaglio, torna al business. Prendi una Consegna e i suoi Articoli della consegna, il frigorifero, l’installazione, il ritiro dell’usato. Un articolo può esistere senza la sua consegna? No. Se la consegna viene eliminata, devono sparire anche gli articoli? Sì. Gli articoli hanno bisogno di un proprio titolare o di una propria sicurezza? Non proprio. Qualcuno dovrebbe spostare un articolo da una consegna a un’altra? Si spera non per sbaglio.

Ora prendi una Consegna e il Percorso su cui si trova. La consegna esiste prima di essere assegnata a un percorso, può essere spostata su un altro percorso quando il piano cambia, ed eliminare un percorso non dovrebbe mai eliminare le consegne che contiene. Due linee uno-a-molti che sembrano uguali in un diagramma, con un comportamento completamente diverso. Nota che non abbiamo ancora detto “relazione di ricerca” o “master-dettaglio”. Descrivi prima il comportamento. La configurazione lo implementa.

I tipi di relazione

Apri la schermata Nuovo campo e Salesforce ti offre una manciata di tipi di relazione (Object Relationships Overview (opens in a new tab)):

• Ricerca (lookup): collega due oggetti. Il pane quotidiano delle relazioni Salesforce.
• Master-dettaglio: un legame padre-figlio in cui il padre controlla il figlio.
• Molti-a-molti: non è un tipo di campo a sé, ma un pattern: un oggetto di giunzione di Salesforce (Salesforce Junction Object), un oggetto personalizzato con due master-dettaglio.
• Relazione con se stessi: una relazione di ricerca da un oggetto verso se stesso.
• Gerarchica: una relazione di ricerca speciale che esiste solo sull’oggetto Utente, come il responsabile di un utente.
• Ricerca esterna e ricerca indiretta: le relazioni verso e da gli oggetti esterni, gli oggetti __x del modulo 4. Una ricerca esterna punta a un oggetto esterno padre; una ricerca indiretta punta da un oggetto esterno a un oggetto standard o personalizzato, con la corrispondenza su un ID esterno univoco.

La maggior parte del tuo tempo di progettazione va ai primi tre. Vediamoli uno alla volta.

Relazione di ricerca: questi record sono collegati

Una relazione di ricerca dice: questo record è associato a quel record. Il figlio conserva la propria identità, il proprio titolare e la propria vita. Una Consegna punta al suo Percorso. Se il percorso viene annullato, le consegne non spariscono; tornano a essere assegnate a un percorso.

È curioso: il campo di ricerca sta sul figlio, ma anche il padre riceve qualcosa, un elenco correlato dei suoi figli. Quindi quando ne crei uno, dai un nome a entrambe le estremità. L’etichetta dell’elenco correlato (Related List Label) è ciò che le persone vedono sul padre, e il nome della relazione figlio (Child Relationship Name) è ciò che sviluppatori e integrazioni usano per andare dal padre ai figli. Non accettare i valori predefiniti.

Una relazione di ricerca può essere obbligatoria o facoltativa. Quando è facoltativa, decidi tu cosa succede se il record a cui punta viene eliminato, e le scelte sono tre (Considerations for Object Relationships (opens in a new tab)):

• Cancella il valore di questo campo, l’impostazione predefinita. Il figlio resta, con una relazione di ricerca vuota.
• Non consentire l’eliminazione del record di ricerca. Prova a eliminare il percorso, e Salesforce dice di no: fa parte di una relazione.
• Elimina anche questo record, un’eliminazione a cascata, come in una master-dettaglio. Viene offerta solo per una relazione di ricerca personalizzata su un oggetto personalizzato, è disattivata per impostazione predefinita, e deve essere Salesforce ad attivarla per la tua org, perché un’eliminazione a cascata scavalca la sicurezza e la condivisione: gli utenti possono eliminare record che non potevano nemmeno vedere.

È una decisione sul ciclo di vita nascosta in una schermata di configurazione.

I filtri di ricerca (lookup filters) restringono ciò che un utente può scegliere. Diciamo che la Consegna ha una relazione di ricerca Installatore verso Contatto, e gli installatori sono un tipo di record di contatto fra tanti. Un filtro di ricerca mostra solo gli installatori, e può filtrare sul record corrente, sul record cercato e sull’utente: il suo profilo, il suo ruolo o le sue autorizzazioni (Lookup Filters (opens in a new tab)). È un modo economico per mantenere onesta una relazione di ricerca.

Master-dettaglio: questo figlio appartiene a quel padre

La master-dettaglio fa un’affermazione molto più forte. In aula la chiamo un legame molto stretto. Non puoi avere un dettaglio senza il suo master; il campo master è obbligatorio. Il dettaglio perde il proprio campo Titolare ed eredita il titolare del padre. Non c’è una tabella di condivisione separata per il dettaglio, quindi non puoi condividere un figlio da solo; eredita la condivisione del padre. Per questo un oggetto di dettaglio non può avere regole di condivisione, condivisione manuale o code: richiedono tutte un campo Titolare (Object Relationships Overview (opens in a new tab)). In Imposta la sua impostazione di condivisione dice Controllato dall’elemento principale (Controlled by Parent). E sul campo master-dettaglio stesso scegli un’impostazione di condivisione (Sharing Setting): se un utente ha bisogno dell’accesso in Sola lettura o in Lettura/Scrittura al master per creare, modificare o eliminare i suoi dettagli. Eliminare il master ne elimina i dettagli. E il master ottiene i campi di riepilogo roll-up.

Quindi se l’Articolo della consegna è un dettaglio della Consegna, sto dicendo: questo articolo appartiene a questa consegna per tutta la sua vita. È la domanda a cui voglio una risposta prima che qualcuno scelga Relazione master-dettaglio in Imposta.

La domanda sull’eliminazione

Ecco il mio modo preferito per capire se ci abbiamo pensato bene: cosa dovrebbe succedere ai figli se qualcuno elimina il padre? Tutti si sentono a disagio. Bene. Ora stiamo facendo architettura.

Un Partner retail ha centinaia di migliaia di consegne storiche. Qualcuno elimina il partner. Le consegne devono sparire? Quasi certamente no: i reclami, la fatturazione e lo storico dipendono tutti da loro. Forse eliminare un partner non dovrebbe proprio essere consentito, e il partner andrebbe invece disattivato. Con la master-dettaglio, eliminare il master si propaga a cascata sui dettagli e sui loro dettagli; ripristinare il master li riporta indietro (Considerations for Object Relationships (opens in a new tab)). Quindi quando qualcuno dice “la master-dettaglio ci dà i roll-up”, la mia risposta è: ottimo. A cos’altro hai appena acconsentito?

La titolarità viene con il pacchetto

Con una relazione di ricerca, il figlio può avere un proprio titolare. Con la master-dettaglio no; l’accesso segue il master. È esattamente giusto se il dettaglio fa davvero parte del padre. Ma se il figlio ha bisogno di un proprio titolare, di una propria condivisione o di un proprio ciclo di vita, il modello ti sta dicendo che la master-dettaglio è la scelta sbagliata. Il prossimo modulo approfondisce la titolarità, e il corso Sharing and Visibility va ancora oltre. Per ora: la progettazione delle relazioni e la progettazione della sicurezza non sono conversazioni separate. Il modello dati dà forma al modello di sicurezza prima che qualcuno scriva una regola di condivisione.

Padre obbligatorio o facoltativo?

Il figlio può esistere prima che conosciamo il suo padre? Conta più di quanto sembri. Se le consegne arrivano con il manifesto di carico la sera prima e i percorsi vengono costruiti dopo, un Percorso obbligatorio sulla Consegna significherebbe che l’assegnazione ai percorsi deve avvenire prima ancora che il record possa essere creato. La relazione fisica deve sostenere il ciclo di vita reale. Quindi non progetto le relazioni solo a partire da un diagramma statico. Voglio sapere: come nascono, possono esistere da sole, possono spostarsi, e come muoiono?

Il figlio può cambiare padre?

Per impostazione predefinita, un figlio in una master-dettaglio non può essere spostato su un altro padre. Puoi consentirlo selezionando Consenti riassegnazione dell’elemento principale (Allow reparenting) sulla relazione (Considerations for Object Relationships (opens in a new tab)). Il mio istinto è prudente: se il business dice che il figlio appartiene a un solo padre per tutta la vita, non rendo facile spostarlo. Un articolo che passa da una consegna a un’altra dovrebbe essere un evento di business deliberato, non la modifica di un campo. Di nuovo, l’impostazione non è l’architettura. Lo è la regola sul ciclo di vita, e l’impostazione la implementa.

Altre due cose che sorprendono i team più tardi. Non puoi creare una relazione master-dettaglio su un oggetto che contiene già dati; crei una relazione di ricerca, la compili su ogni record, poi la converti. E puoi riconvertirla in relazione di ricerca solo se sul master non ci sono campi di riepilogo roll-up. Guarda anche cosa fa la conversione alla sicurezza: trasformare una relazione di ricerca in master-dettaglio imposta la condivisione del figlio su Controllato dall’elemento principale, e riportare una master-dettaglio a relazione di ricerca imposta l’impostazione predefinita a livello di organizzazione del figlio su Lettura/Scrittura pubblica (Public Read/Write) (Considerations for Object Relationships (opens in a new tab)). Record che ieri erano privati oggi sono aperti, finché qualcuno non se ne accorge. Scegli presto.

I roll-up sono utili, ma non sono gratis

Mi piacciono i roll-up. Contare gli articoli di una consegna, sommare gli importi delle righe di una fattura, trovare la data più recente: nativo, senza codice. Il campo master-dettaglio sta sul figlio, ma il roll-up sta sul padre. Hanno però le loro clausole in piccolo (Roll-Up Summary Field (opens in a new tab)):

• Calcolare i valori dei roll-up dopo certe modifiche (un nuovo campo roll-up, una formula modificata da cui dipende, un ricalcolo forzato) può richiedere fino a 30 minuti, a seconda di quanti record sono coinvolti. Ho visto persone chiedersi perché il numero sul padre non fosse ancora cambiato.
• Non possono riepilogare tutto. Una numerazione automatica non può essere il campo che aggreghi. E un roll-up può riepilogare un campo formula solo se quella formula non raggiunge un altro oggetto e non usa una funzione che cambia da sola, come NOW() o TODAY(). Una formula “giorni di ritardo” costruita su TODAY() cambia ogni notte senza che nessuno salvi un record, quindi non c’è nulla da cui il roll-up possa ricalcolare. Quel tipo di numero ha bisogno di un flusso pianificato, o di un report.
• Anche il filtro ha dei limiti: niente aree di testo lunghe, elenchi di selezione a selezione multipla, Descrizione, campi di sistema come Ultima attività, formule tra oggetti o campi di ricerca.
• I roll-up non compaiono nelle pagine di modifica, quindi una regola di convalida può usarne uno ma non può mostrare lì il suo errore.

E non invertire la decisione. Non dire: “Ci serve un roll-up, quindi deve essere una master-dettaglio”. Di’: “Questo figlio appartiene davvero a questo padre, titolarità e ciclo di vita si adattano, e uno dei vantaggi sono i roll-up nativi”. Se la semantica non si adatta, risolvi il calcolo in un altro modo. Non distorcere il modello dati per ottenere una funzionalità.

Quindi qual è l’altro modo? Il roll-up lo costruisci tu: un campo sul padre che contiene il valore calcolato, e un’automazione che lo tiene aggiornato. Diciamo che il Partner retail è una relazione di ricerca dalla Consegna, come deve essere, e il business vuole le Consegne aperte sul partner. Aggiungi al partner un campo numerico, Consegne aperte. Poi un flusso attivato da record, o un trigger Apex quando il volume o la logica richiedono codice, lo ricalcola ogni volta che una consegna cambia. Funziona attraverso una relazione di ricerca, può filtrare su qualsiasi cosa, e può usare date e formule che un roll-up nativo non può usare.

Ma ora tocca a te farlo bene, ed è lì che queste soluzioni vanno storte. L’automazione deve scattare a ogni modifica che conta: un nuovo figlio, un figlio modificato, un figlio eliminato, un figlio ripristinato, e un figlio spostato su un altro padre, il che significa ricalcolare sia il vecchio padre sia quello nuovo. Deve reggere un caricamento di dati di 200 record alla volta senza toccare i limiti. Riconta invece di aggiungere e sottrarre, così un singolo evento perso non lascia il numero sbagliato per sempre. Prevedi un modo per ricalcolare tutto, per il primo caricamento e per il giorno in cui il valore si discosta. E ricorda che ora ogni salvataggio di un figlio aggiorna il padre, quindi un padre con migliaia di figli riporta i blocchi che vedremo tra un momento. Un roll-up nativo fa tutto questo per te; uno personalizzato è un piccolo software di cui sei responsabile.

Tre livelli di profondità: master-dettaglio in pila

La piattaforma ha una forma, e la master-dettaglio ne ha due dimensioni. La prima è la profondità.

Puoi impilare master-dettaglio fino a tre livelli di dettaglio personalizzati, e quello è il fondo (Considerations for Object Relationships (opens in a new tab)). In aula lo disegno come un account con un ordine (uno), l’ordine con i suoi articoli (due), e gli articoli con i loro dettagli (tre), e poi provo ad aggiungerne un quarto e Salesforce non me lo lascia fare. Su Steve Trucking potrebbe essere così: una Consegna è il master; i suoi Articoli della consegna sono il primo livello; le Attività di installazione (Install Task) di un articolo sono il secondo; e i Passaggi dell’attività (Task Step) di ogni attività sono il terzo. Un quarto livello, diciamo una Nota del passaggio (Step Note), deve essere una relazione di ricerca.

Click to enlarge

Con la pila arrivano alcune regole:

• Gli oggetti standard non possono stare sul lato dettaglio di un oggetto personalizzato. Un oggetto personalizzato può essere un dettaglio di Account; Account non può essere un dettaglio del tuo.
• Un oggetto può comparire una sola volta in una pila a più livelli. Salesforce non vuole che tu ritorni su te stesso: un sottodettaglio non può essere anche il master del proprio master.
• Il master non può fare il roll-up direttamente dell’ultimo livello. Se la Consegna vuole il numero di Passaggi dell’attività, l’Attività di installazione fa il roll-up dei suoi passaggi, l’Articolo della consegna fa il roll-up di quei roll-up, e la Consegna fa il roll-up degli articoli: un livello alla volta.
• Titolarità e condivisione vengono dall’alto. Ogni livello eredita il titolare e l’accesso del master.
• Eliminare il master elimina tutto ciò che sta sotto, e ripristinarlo riporta indietro tutto.

Tre livelli di solito bastano e avanzano. Se il tuo progetto continua a volerne un quarto, chiediti se ogni livello appartiene davvero per tutta la vita a quello sopra. E ricorda che puoi scegliere quale legame spezza la catena. Il quarto livello non deve per forza essere la relazione di ricerca: forse un’Attività di installazione non appartiene davvero al suo Articolo della consegna, viene pianificata e assegnata per conto suo, quindi quel legame diventa una relazione di ricerca, e ora l’Attività di installazione inizia una nuova catena con Passaggio dell’attività e Nota del passaggio sotto di sé. Scegli il legame in cui il figlio ha davvero una vita propria, e rendi quello la relazione di ricerca.

Click to enlarge

Ora l’Attività di installazione ha un proprio titolare e una propria condivisione, una consegna può essere eliminata senza portarsi via le sue attività di installazione, e l’Attività di installazione può avere altri due livelli sotto di sé. Ecco lo scambio: la catena è più corta, e la vita dell’attività di installazione è sua.

Due padri di larghezza: l’oggetto di giunzione di Salesforce

Prima, una parola sulle parole, perché “oggetto di giunzione” significa due cose, e le insegno entrambe.

Nel capitolo 2 abbiamo trovato l’oggetto di giunzione logico: la giunzione di due idee chiave che diventa una cosa a sé, con i propri attributi. Un cane conosce molti esercizi, un esercizio è conosciuto da molti cani, e l’Esercizio del cane sta in mezzo con il livello di abilità e la data. Quello è un oggetto di giunzione logico, nel modello logico, molto prima che qualcuno decida tra ricerca e master-dettaglio.

Salesforce usa il termine in modo più ristretto. Quando Salesforce dice oggetto di giunzione, intende un oggetto personalizzato con due relazioni master-dettaglio (Create a Many-to-Many Object Relationship (opens in a new tab)). Io lo chiamerò oggetto di giunzione di Salesforce (Salesforce Junction Object). Ogni oggetto di giunzione di Salesforce è un oggetto di giunzione logico, ma non ogni oggetto di giunzione logico diventa un oggetto di giunzione di Salesforce: costruiscine uno con una master-dettaglio e una relazione di ricerca, o con due relazioni di ricerca, ed è comunque un oggetto di giunzione logico, solo non del tipo Salesforce. (Salesforce stessa non è del tutto coerente: il suo riferimento sugli oggetti chiama “oggetti di giunzione” alcuni oggetti standard costruiti con relazioni di ricerca. All’esame, assumi la definizione ristretta.)

Da sapere per l’esame. Un oggetto di giunzione di Salesforce è un oggetto personalizzato con due relazioni master-dettaglio, ed è questo che Salesforce intende quando dice “oggetto di giunzione”. L’oggetto di giunzione logico è l’idea di modellazione più ampia: qualsiasi oggetto che unisce altri due in una molti-a-molti e porta i propri attributi, comunque sia costruito.

La seconda dimensione è la larghezza. Un figlio può avere due padri master-dettaglio? Sì. Tre? No. Ogni oggetto personalizzato può avere al massimo due relazioni master-dettaglio (Considerations for Object Relationships (opens in a new tab)). Due padri master-dettaglio sono il modo in cui costruisci un oggetto di giunzione di Salesforce per una molti-a-molti. Squadra e Camion si incontrano in un’Assegnazione della squadra, e come abbiamo visto nel capitolo 2, non è una tubatura: ha una data, un percorso, magari uno stato. La giunzione è il punto in cui la relazione diventa un concetto di business. I consigli di Salesforce per costruirne una: dalle un nome che dica cos’è, rendi il nome del suo record una numerazione automatica, e rinomina l’elenco correlato di ciascun master con il nome dell’altro master, così la pagina della Squadra mostra “Camion” e la pagina del Camion mostra “Squadre” (Create a Many-to-Many Object Relationship (opens in a new tab)).

Ecco la sottigliezza. Uno dei due padri è il primario, ed è quello il cui campo master-dettaglio hai creato per primo. Non c’è alcuna indicazione visiva di quale sia, quindi è una classica domanda d’esame, e una classica sorpresa.

Cosa decide il primario? Tre cose (Create a Many-to-Many Object Relationship (opens in a new tab)):

• Aspetto. Le pagine della giunzione usano il colore e l’icona del master primario.
• Titolare. I record della giunzione ereditano il titolare del record master primario. Non lo vedi mai, perché un dettaglio non ha un campo Titolare; conta solo se in seguito rimuovi entrambe le relazioni master-dettaglio.
• Divisione, se la tua org usa le divisioni, allo stesso modo.

E l’altro è il secondario. Cosa significa?

• È il prossimo a diventare primario. Elimina il campo master-dettaglio primario o convertilo in relazione di ricerca, e il secondario diventa il primario.
• Definisce il perimetro dei report. Salesforce ti dà due tipi di report: “Master primario con oggetto di giunzione e master secondario” e “Master secondario con oggetto di giunzione e master primario”. Il master indicato per primo decide quali record il report può mostrare.
• Conta altrettanto per l’accesso. Io la metto così: la titolarità dal primario, l’accesso da entrambi, e vince il più restrittivo. Una giunzione, come ogni dettaglio, non ha una propria tabella di condivisione. Salesforce controlla l’accesso dell’utente a entrambi i record master, tramite l’impostazione di condivisione su ciascun campo master-dettaglio. Se entrambi sono impostati su Lettura/Scrittura, l’utente ha bisogno di Lettura/Scrittura sulla squadra e sul camion per modificare l’Assegnazione della squadra (Considerations for Object Relationships (opens in a new tab)).
• Elimina altrettanto. Elimina uno qualsiasi dei due master, la squadra o il camion, e i suoi record di giunzione finiscono nel Cestino. Eliminali entrambi e spariscono per sempre.

Click to enlarge

Qualche altra regola: entrambi i master possono avere riepiloghi roll-up dalla giunzione, e le formule e le regole di convalida della giunzione possono raggiungere i campi di entrambi. Ma una giunzione non può essere il master di nient’altro, quindi non può stare nel mezzo di una pila, e i due master non possono essere lo stesso oggetto; una molti-a-molti da un oggetto verso se stesso richiede un progetto diverso. E se un padre ha più di 200 record di giunzione e la giunzione fa il roll-up verso l’altro padre, Salesforce non ti lascia eliminare quel padre finché non ne hai rimossi abbastanza.

Quindi: quale padre dovrebbe essere il primario? Crea per primo quello che porta il significato. Per un’Assegnazione della squadra, è la squadra che fa il lavoro, quindi creerei prima Squadra. E poi scrivilo, perché niente sullo schermo lo dirà alla prossima persona.

Detto tutto questo, non mi ritrovo con molti oggetti di giunzione di Salesforce. Di solito un oggetto ha un solo padre master-dettaglio, ed è lo stesso tipo di dati: dati dei clienti sotto dati dei clienti, transazionali sotto transazionali (ricorda i tipi di dati del capitolo 2: dei clienti, transazionali, di riferimento). Quando l’altro padre è di un tipo diverso, di solito un oggetto di riferimento, quella relazione è una relazione di ricerca. Un Articolo della consegna appartiene alla sua Consegna: master-dettaglio, entrambi transazionali. Punta al Prodotto che trasporta con una relazione di ricerca, perché un prodotto è un dato di riferimento con una vita propria, e nessuno vuole che eliminare un prodotto si porti via anni di storico delle consegne. L’Articolo della consegna resta un oggetto di giunzione logico tra una consegna e i prodotti che contiene; solo non è un oggetto di giunzione di Salesforce.

Relazioni con se stessi: quando la linea torna indietro

Un oggetto può collegarsi a se stesso: un account principale, un responsabile, un centro di distribuzione che fa capo a un hub regionale. Salesforce ne integra due che incontrerai in quasi ogni org: da Account ad Account, il campo Account principale che costruisce la gerarchia degli account, e da Caso a Caso, il Caso principale (Parent Case) del modulo 2 che raggruppa i casi correlati. Una relazione con se stessi deve essere una relazione di ricerca, e un record non può puntare a se stesso, anche se due record possono puntare l’uno all’altro (Considerations for Object Relationships (opens in a new tab)). Sull’oggetto Utente è un tipo a sé, la relazione gerarchica, usata per cose come il responsabile di un utente. La meccanica è facile; il nome conta. Una relazione di ricerca da Centro di distribuzione a Centro di distribuzione chiamata Distribution_Center__c non aiuta nessuno. Principale? Di riserva? Di sfogo? Dai alla relazione il nome del ruolo, non dell’oggetto a cui punta.

Click to enlarge

Gerarchica: la relazione propria dell’oggetto Utente

Questa è piccola, ed è esattamente il tipo di fatto poco noto e unico nel suo genere da cui mi aspetterei che un esame attinga. La relazione gerarchica è una relazione di ricerca speciale che esiste solo sull’oggetto Utente. Collega un utente a un altro utente, e Salesforce non lascia che la catena torni su se stessa: un utente non può puntare a se stesso, né direttamente né indirettamente (Object Relationships Overview (opens in a new tab)). Se Maria fa capo a Dev, Dev non può fare capo a Maria, né a nessuno che faccia capo a Maria.

È questa la differenza rispetto alle relazioni con se stessi viste sopra. Su Account o su un oggetto personalizzato, due record possono puntare l’uno all’altro. Su Utente, la gerarchia deve restare una gerarchia. Ed è l’unico modo per collegare Utente a Utente: una normale relazione di ricerca da Utente verso se stesso non è offerta.

Ne hai già una. Il campo standard Responsabile (Manager) su Utente è una relazione gerarchica, e le approvazioni possono usarlo: invia questa richiesta al responsabile di chi l’ha inviata. Puoi crearne anche di tue, per esempio un Contatto di escalation o un Approvatore di riserva, e un’approvazione può seguirle allo stesso modo (ApprovalProcess, Metadata API (opens in a new tab)). Non confonderla con la gerarchia dei ruoli, che determina l’accesso ai record. Un campo gerarchico è solo una relazione tra utenti; non condivide nemmeno un record.

Da sapere per l’esame. La relazione gerarchica esiste solo sull’oggetto Utente, come il campo standard Responsabile (Manager), e un utente non può puntare a se stesso, né direttamente né indirettamente. Non è la gerarchia dei ruoli.

Anche le relazioni hanno limiti

Ogni oggetto può avere al massimo due relazioni master-dettaglio. I campi di relazione di ricerca e master-dettaglio insieme contano come campi di relazione: 40 per oggetto per impostazione predefinita, 50 al massimo su richiesta. Campi di riepilogo roll-up: 25 per oggetto per impostazione predefinita, 40 al massimo (Increase the Maximum Relationships Allowed per Object (opens in a new tab); Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab)). Salesforce aggiunge che alzare uno dei due limiti può influire sulle prestazioni.

Non devi progettare in base a quei numeri; devi accorgerti quando ti ci avvicini. Un oggetto con una relazione dopo l’altra appesa addosso ti sta dicendo qualcosa. Forse è davvero così centrale. O forse il modello è sbagliato. (E vale la regola del margine del capitolo 18: resta ben sotto un limite, misurato rispetto al terzo anno.)

La domanda dei 10.000 figli

Poi c’è il padre con troppi figli. L’indicazione di Salesforce è di non superare circa 10.000 record figli per un singolo padre in master-dettaglio (Considerations for Object Relationships (opens in a new tab)), e la sua guida all’accesso ai record su larga scala dice lo stesso per le relazioni padre-figlio in generale (Parent-Child Data Skew (opens in a new tab)). Il record 10.001 non rompe la org. Ma oltre quel punto, salvare un figlio può bloccare il padre, e le modifiche di condivisione sul padre si propagano su ogni figlio.

Quindi quando vedo un padre, un numero enorme di figli, mi chiedo: perché stanno tutti sotto lo stesso padre, chi ne è titolare, come vengono interrogati, e quale automazione tocca il padre? Tutte le consegne sotto un unico account “Steve Trucking” supererebbero 10.000 in pochi giorni. Un’innocente uno-a-molti diventa un problema di squilibrio (skew). Il prossimo modulo anticipa lo squilibrio, e la Parte 2 lo approfondisce.

Non progettare la linea in base alla funzionalità

È l’abitudine che voglio da questo modulo. Non partire da “mi serve un roll-up”, “mi serve obbligatorio”, “voglio la condivisione ereditata”. Sono indizi di implementazione. Parti dal business: il figlio ha una vita propria, chi ne è titolare, può esistere da solo, può spostarsi, cosa succede quando il padre se ne va, la relazione porta dati, e quanto può crescere ciascun lato? Poi scegli la relazione che implementa le risposte.

Click to enlarge

Oltre l’esame: cosa cambia l’IA. L’IA può proporre relazioni in pochi secondi. Non può dirti se il business eliminerà mai il padre. Disegnare più in fretta non rende meno costoso invertire una relazione sbagliata una volta che milioni di record e decine di automazioni ne dipendono.

Cosa decide qui un architetto

• Se il figlio ha un proprio ciclo di vita o appartiene davvero al padre, e se titolarità e accesso debbano essere propri o ereditati.
• Se il figlio può esistere senza un padre, spostarsi tra padri o sopravvivere all’eliminazione del padre.
• Cosa fa ogni relazione di ricerca quando il suo padre viene eliminato: cancellare, bloccare o eliminare a cascata.
• Se una molti-a-molti è una tubatura o un concetto di business, se l’oggetto di giunzione logico diventa un oggetto di giunzione di Salesforce, quale padre è il primario, e cosa significano entrambi i padri per l’accesso.
• Se il modello si adatta alla forma della piattaforma: tre livelli di dettaglio personalizzati di profondità, due padri master-dettaglio di larghezza, i limiti di relazioni e roll-up.
• Se il numero e la distribuzione previsti dei figli creano un rischio di squilibrio che dovrebbe cambiare il progetto.

Una relazione è un insieme di promesse su come si comportano insieme due dati. Falle deliberatamente.

Per approfondire

• Guida di Salesforce, Considerations for Object Relationships (opens in a new tab) (in inglese), consultato il 2026-10-13.
• Guida di Salesforce, Object Relationships Overview (opens in a new tab) e Create a Many-to-Many Object Relationship (opens in a new tab) (in inglese), consultato il 2026-10-13.
• Guida di Salesforce, Roll-Up Summary Field (opens in a new tab) (in inglese), consultato il 2026-10-13.
• Salesforce Developers, Metadata API, ApprovalProcess (opens in a new tab) (in inglese), consultato il 2026-10-13.
• Guida di Salesforce, Lookup Filters (opens in a new tab) (in inglese), consultato il 2026-10-13.
• Guida di Salesforce, Increase the Maximum Relationships Allowed per Object (opens in a new tab) e Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab) (in inglese), consultato il 2026-10-02.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (opens in a new tab) (in inglese), consultato il 2026-10-02.