Titolarità e ciclo di vita

🌐 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 8 di 10 del capitolo Architettura dei dati Salesforce, capitolo 3 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Le relazioni hanno conseguenze · Successivo: Mantenere i dati coerenti

La domanda a cui risponde questo modulo: Chi è titolare del record, e cosa gli succede per tutta la sua vita?

Quando guardo un modello dati, non voglio sapere solo quali sono gli oggetti e come si collegano. Voglio sapere cosa succede ai record nel tempo. Chi li crea? Chi ne è titolare? Chi può riassegnarli? Cosa succede quando la relazione di business cambia, quando non sono più attivi? Andrebbero mai eliminati, e per quanto li conserviamo? Niente di tutto questo compare in un ERD, il diagramma entità-relazione: le caselle e le linee del modello dati del capitolo 2. Tutto questo è architettura dei dati. E su Salesforce la titolarità è il punto in cui il modello dati e il modello di sicurezza si scontrano.

La titolarità è più di un nome in un campo

Gli amministratori vedono Titolare su un record e lo leggono come un’etichetta: Bart è titolare di questo account, Lisa di quel caso. Può voler dire questo. Ma su Salesforce la titolarità è anche un meccanismo della piattaforma. Sugli oggetti che hanno un titolare, il titolare determina chi può vedere il record attraverso la gerarchia dei ruoli, le regole di condivisione, le code e la riassegnazione. Quindi quando chiedo “chi è titolare di questo record?” non sto chiedendo quale nome compare nella pagina. Sto chiedendo quale comportamento di sicurezza e di ciclo di vita gli stiamo associando. Il titolare può essere un utente o, per alcuni oggetti, tra cui gli oggetti personalizzati, i casi e i lead, una coda, e in entrambi i casi il titolare ottiene l’accesso completo al record (Understanding Sharing (opens in a new tab)).

Per questo separo la responsabilità di business dalla titolarità del record. A volte sono la stessa persona. A volte no. Se il business dice che chi fa dispatch è responsabile di una consegna, non ne fa automaticamente il titolare. La responsabilità può stare in un suo campo mentre la titolarità viene impostata per sostenere sicurezza e scala. Non lasciare che le due si confondano solo perché in inglese entrambe usano la parola “owner”.

La tabella di condivisione: dove la titolarità diventa accesso

Alcune persone non sanno nemmeno cosa sia la tabella di condivisione. Ogni data architect dovrebbe saperlo.

Gran parte della condivisione di un record è conservata in un oggetto di condivisione (share object) collegato, la versione di Salesforce di una lista di controllo degli accessi (Understanding Sharing (opens in a new tab)). Account ha AccountShare, Contatto ha ContactShare, e un oggetto personalizzato ha il suo: Truck__c ha Truck__Share (Sharing a Record Using Apex (opens in a new tab)). Ogni riga dice quattro cose:

• Quale record: l’ID del padre.
• Chi: un utente o un gruppo (un gruppo pubblico, il gruppo di un ruolo, un territorio).
• Quanto: lettura, modifica o tutto (accesso completo).
• Perché: il motivo della riga (row cause). Owner per il titolare, Rule per una regola di condivisione, Manual per una condivisione manuale, Team, i motivi impliciti che Salesforce aggiunge tra un account e i suoi figli, e i motivi che uno sviluppatore definisce per la condivisione Apex.

In aula apro Workbench e interrogo la tabella di condivisione mentre condivido un record, e tu vedi le righe comparire e sparire. Quando qualcuno chiede “perché questa persona può vedere quello?”, la risposta spesso è lì, in una riga, con il suo motivo.

Ma non tutto è lì dentro. L’impostazione predefinita a livello di organizzazione non è una riga. Nemmeno la gerarchia dei ruoli è memorizzata lì: l’accesso per chi sta sopra il titolare viene calcolato quando serve. E Visualizza tutto, Modifica tutto, Visualizza tutti i dati e Modifica tutti i dati (View All, Modify All, View All Data, Modify All Data) saltano del tutto la tabella di condivisione (Sharing a Record Using Apex (opens in a new tab)). Come dico in aula: spunta Visualizza tutto e hai scavalcato la tabella di condivisione.

Salesforce condivide anche alcuni record al posto tuo, per via di come sono collegati. È la condivisione implicita, e funziona tra un account e i suoi figli. Se puoi vedere un contatto, un caso o un’opportunità, puoi anche leggere l’account a cui appartiene. E il titolare dell’account ottiene l’accesso ai contatti, ai casi e alle opportunità dell’account, a un livello stabilito dal ruolo del titolare (Implicit Sharing (opens in a new tab)). Nelle release recenti Salesforce calcola parte di quell’accesso ai figli quando serve, invece di memorizzarlo come righe, quindi non stupirti se una query sulla tabella di condivisione non lo mostra. Qui ti do solo un accenno; i dettagli sono in Le relazioni e la condivisione integrata.

Un’altra eccezione, per quando hai molti utenti esterni. Gli utenti community ad alto volume, le licenze Customer Community pensate per migliaia o milioni di clienti, non hanno un ruolo, non possono stare nei gruppi pubblici e non possono ricevere record tramite regole di condivisione o condivisioni manuali (About High-Volume Community or Site Users (opens in a new tab); Sharing Rule Considerations (opens in a new tab)). Per loro la risposta non è la tabella di condivisione: arrivano ai record tramite i set di condivisione, che confrontano l’account o il contatto di un record con quelli dell’utente. È uno dei motivi per cui quelle licenze scalano. Il corso Sharing and Visibility lo tratta in Condividere con gli utenti esterni.

E ricorda il modulo 7: un oggetto dettaglio non ha alcun oggetto di condivisione. Il suo accesso viene dall’oggetto di condivisione del master e dall’impostazione di condivisione (Sharing Setting) del campo master-dettaglio.

Perché un data architect se ne preoccupa? Perché la titolarità è scritta in questa tabella. Ogni cambio di titolare, ogni nuova regola di condivisione, ogni utente che cambia ruolo o gruppo significa che Salesforce aggiunge e rimuove righe. Con qualche migliaio di record nessuno se ne accorge. Con dieci milioni, e un solo utente titolare della maggior parte, è il ricalcolo che incontreremo tra poco.

Da sapere per l’esame. L’oggetto di condivisione di un oggetto personalizzato si chiama Object__Share, come Truck__Share. Un oggetto dettaglio non ha un oggetto di condivisione: il suo accesso viene dal master. E quando il titolare di un record cambia, le sue condivisioni manuali vengono rimosse, mentre la condivisione Apex con un motivo definito dallo sviluppatore resta.

È qui che il modello dati passa il testimone al modello di sicurezza, e il resto lo insegno nel corso Sharing and Visibility Architect: I 22 modi di Steve per condividere un record, Impostazioni predefinite a livello di organizzazione, titolarità, code e gerarchia dei ruoli, Le relazioni e la condivisione integrata per le condivisioni implicite, e Condivisione programmatica e codice sicuro per i motivi di condivisione Apex. In questo corso, il capitolo 12 mette tutto insieme per persone, applicazioni e agenti.

A volte la titolarità è ereditata

Nel modulo precedente abbiamo visto che un figlio in una master-dettaglio non ha un titolare proprio; segue il padre. Spesso è esattamente giusto. Il business ha bisogno di un titolare diverso per ogni articolo di una consegna? No. La consegna governa il ciclo di vita e l’articolo le appartiene. Ecco perché la progettazione delle relazioni e quella della titolarità vanno insieme: quando hai scelto la master-dettaglio, avevi già preso parte della decisione sulla titolarità.

Chi è titolare dei record creati dai sistemi?

Ora si fa interessante. Una persona crea un account, e forse ne diventa titolare. Ma un ERP invia 100.000 transazioni durante la notte. Chi ne è titolare? L’utente di integrazione? Una coda? Un titolare regionale ricavato dai dati? Un account di sistema a cui nessuno pensa da cinque anni? E ora anche gli agenti creano record.

La mia posizione: dipende da se la titolarità conta per la condivisione. L’utente di integrazione, o l’utente dell’agente, è un utente valido, e può essere titolare dei record. Se in quell’oggetto la titolarità determina l’accesso (tramite la gerarchia dei ruoli o le regole di condivisione), assegna i record al titolare giusto: un utente reale, una coda o un utente titolare dedicato. Se non lo determina, tenere l’utente di sistema come titolare può essere la scelta migliore, perché così l’audit trail riporta dritto a ciò che ha creato il record.

In ogni caso, decidilo di proposito. Un account di integrazione titolare di tutto è diventato in silenzio parte della tua architettura di sicurezza, e qualcuno deve sapere cosa succede se mai viene disattivato.

La titolarità può diventare un problema di scala

Conta anche la distribuzione. Dieci milioni di record distribuiti su migliaia di titolari sono una forma. Dieci milioni di record di un solo utente sono una forma molto diversa. Salesforce parla di squilibrio dei dati di titolarità (ownership data skew) quando un singolo utente è titolare di più di 10.000 record di un oggetto (Ownership Data Skew (opens in a new tab)). Di solito succede quando qualcuno parcheggia tutto su un solo utente o una sola coda: tutti i lead non assegnati su un utente segnaposto, ogni record di integrazione sull’utente di integrazione. È innocuo finché quell’utente non si sposta nella gerarchia dei ruoli, o entra o esce da un gruppo da cui dipende una regola di condivisione. A quel punto Salesforce deve adeguare un numero enorme di voci di condivisione, e ottieni ricalcoli lunghissimi.

L’indicazione è pratica. Distribuisci la titolarità su più utenti dove puoi. Se un utente deve essere titolare di molti record, tienilo fuori dalla gerarchia dei ruoli; se gli serve un ruolo, mettilo in un ruolo tutto suo in cima e non spostarlo, e tienilo fuori dai gruppi pubblici usati dalle regole di condivisione (Ownership Data Skew (opens in a new tab)). Lo stesso ragionamento vale per il padre con troppi figli del modulo precedente, lo squilibrio padre-figlio.

Quindi la distribuzione fa parte del modello fisico. Non chiederti solo quanti record; chiediti come sono distribuiti. È un’altra versione del Numero di Zeri: non solo quanti zeri, ma dove sono concentrati gli zeri. La Parte 2 approfondisce lo squilibrio; qui voglio che tu lo veda arrivare. Il corso Sharing and Visibility lo riprende in La condivisione su larga scala.

Il “titolare predefinito” diventa architettura

Ecco uno schema che vedo di continuo. Nessuno sa chi dovrebbe essere titolare di qualcosa, così qualcuno dice: “Assegnali tutti all’utente di integrazione”, oppure “crea un utente generico chiamato Sistema”. Forse è giusto. Ma non farlo per caso. Un’impostazione predefinita temporanea ha l’abitudine di diventare permanente: due anni dopo ogni record appartiene a integration@company.com, nessuno ricorda perché, e cambiarlo è un progetto. È il Test di Reversibilità del capitolo 1: prima di dare un milione di record a un solo titolare, chiediti cosa serve per cambiarlo più avanti.

La riassegnazione è un evento del ciclo di vita

I titolari cambiano. I commerciali se ne vanno, i territori si spostano, i team si riorganizzano, le regioni vengono ribilanciate. Cosa dipende dal titolare: condivisione, automazione, report, code, escalation, integrazioni? Se cambiare il titolare cambia chi può vedere il record, la riassegnazione non è una pulizia amministrativa. È un evento di sicurezza, e con un milione di record è anche un evento operativo. Osserva la tabella di condivisione quando succede: le condivisioni manuali vengono rimosse quando il titolare cambia, mentre la condivisione Apex con un motivo definito dallo sviluppatore sopravvive al cambio (Understanding Sharing (opens in a new tab)). In aula condivido un record con qualcuno, cambio il titolare, e quella persona perde l’accesso. L’aula si sorprende sempre.

E ricorda che la titolarità non è la stessa cosa dell’accesso. Il titolare non è l’unica persona che ha bisogno di vedere un record, e Salesforce ha molti modi per concedere l’accesso: la gerarchia dei ruoli, le regole di condivisione, i team, i territori, la condivisione manuale e programmatica. Il corso Sharing and Visibility li approfondisce, a partire da I 22 modi di Steve per condividere un record. Il punto dell’architetto è più semplice: non usare la titolarità per risolvere ogni problema di accesso. Se sposti i titolari solo perché qualcuno possa vedere un record, probabilmente stai risolvendo il problema sbagliato.

La creazione è solo l’inizio

Molta modellazione dei dati si ferma alla creazione: i campi, l’oggetto, la relazione, fatto. Ma il record può vivere dieci anni. Viene aggiornato, cambia titolare, cambia stato e relazioni, diventa inattivo, diventa storico, può dover essere archiviato, e un giorno forse eliminato. L’architettura non è solo come nasce il record. È ciò che succede dalla nascita alla morte.

Click to enlarge

Non eliminare solo perché qualcosa è vecchio

Un Partner retail smette di inviare lavoro. Eliminiamo l’account? Non automaticamente: le sue consegne, i reclami e lo storico di fatturazione contano ancora. Un camion viene ritirato. Lo eliminiamo, insieme al suo storico di consegne e ai reclami per danni? La cosa può non essere più attiva, ma i suoi dati sì. Quindi separo inattivo da scomparso. Un camion ritirato può restare nel modello; un ex dipendente può ancora comparire nello storico di audit. L’architettura deve conservare i fatti che contano dopo la fine della relazione operativa.

La conservazione è un requisito di business

L’altra faccia: conservare tutto per sempre non è nemmeno architettura. Lo spazio cresce, i report rallentano, la ricerca diventa più rumorosa, e la legge sulla privacy può dire che alcuni dati devono sparire. Quindi voglio una risposta esplicita a per quanto tempo lo conserviamo?. “Lo conserva Salesforce” non è una politica di conservazione.

E soprattutto è una domanda sui dati transazionali. I dati di riferimento, i prodotti, i tipi di servizio, i centri di distribuzione, non diventano enormi, e altri record puntano a loro, quindi di solito restano. I dati dei clienti stanno nel mezzo: può arrivare il giorno in cui chiudi il ciclo di vita di un cliente, soprattutto quando conservi dati personali e il motivo per conservarli viene meno. Ma il volume sta nelle transazioni: le consegne, gli ordini, i casi, gli appuntamenti, creati ogni giorno, per sempre. È questo che cresce fino a centinaia di milioni di righe, ed è qui che la conservazione deve essere esplicita: forse due anni di dati operativi nella org, sette anni di documenti finanziari da qualche parte, novanta giorni per alcune foto. Sono regole di business, e se nessuno l’ha chiesto, dovrebbe farlo l’architetto.

Lo dico in aula da anni: se non archiviate oggi, archivierete mai? “Ce ne occuperemo più avanti” ha il vizio di diventare un progetto d’emergenza a trecento milioni di record. La Parte 2 ha un intero modulo su archiviazione ed eliminazione definitiva, costruito sulla stessa domanda.

Steve Trucking: chi è titolare di una consegna?

Una consegna viene creata dal manifesto di carico del Partner retail, da un’integrazione, circa 3.300 volte al giorno. Chi ne è titolare? Non il Partner retail; quella è una relazione di business. Non il Destinatario. La squadra la esegue, ma il record dovrebbe cambiare titolare ogni volta che le squadre si scambiano i camion? Chi fa dispatch? Il centro di distribuzione? Una coda? L’utente di integrazione che l’ha creata?

Ora applica questo modulo, partendo dalla domanda che decide tutto: la titolarità determina l’accesso di qualcuno alle consegne? In Steve Trucking no. Chi fa dispatch vede le consegne del proprio centro di distribuzione, le squadre vedono quelle sui loro percorsi, e ogni retailer vede le proprie nel portale dei partner. Niente di tutto questo dipende da chi è titolare del record; viene dal centro di distribuzione, dal percorso e dal partner.

Quindi la mia risposta: l’utente di integrazione è titolare delle consegne. È un buon esempio di utente di sistema titolare di record di proposito:

• La traccia di audit è onesta. Il titolare di ogni consegna dice da dove viene: l’integrazione del manifesto di carico.
• L’accesso viene dalla condivisione, non dalla titolarità. Regole di condivisione basate su criteri sul centro di distribuzione danno al team di ogni CD le sue consegne; i partner arrivano alle proprie tramite il portale.
• Lo squilibrio è previsto dal progetto. A 3.300 al giorno, l’utente di integrazione supera le 10.000 consegne in tre giorni, quindi è squilibrio di titolarità dal primo giorno, e va bene se lo pianifichiamo. L’utente di integrazione non ha un ruolo, quindi niente sopra di lui in una gerarchia deve essere ricalcolato, e resta fuori dai gruppi pubblici usati dalle nostre regole di condivisione.
• Nessuno riassegna le consegne. Le squadre si scambiano i camion e chi fa dispatch cambia turno, ma il titolare non si sposta mai, quindi niente tempesta di riassegnazioni e nessuna condivisione manuale da perdere.

E metti per iscritto cosa succede se quell’utente viene mai disattivato o sostituito, perché ora è titolare di milioni di record. È la decisione che il prossimo team avrà bisogno di trovare.

Oltre l’esame: cosa cambia l’IA. Gli agenti creano e modificano record alla velocità delle macchine. Se un agente crea 100.000 record con il proprio utente, “sistemeremo il titolare più avanti” diventa squilibrio, un ricalcolo della condivisione e un progetto di pulizia. Decidi la regola di titolarità dell’agente prima che vada in produzione, con la stessa domanda: qui la titolarità conta per la condivisione?

Cosa decide qui un architetto

• Se la titolarità rappresenta la responsabilità di business, un meccanismo di sicurezza o entrambi, e dove sta la responsabilità se non nel campo Titolare.
• Se i record hanno bisogno di un proprio titolare o dovrebbero ereditarlo da un padre.
• Chi è titolare dei record creati da integrazioni e agenti, a seconda che la titolarità determini o no la condivisione.
• Come è distribuita la titolarità, e come evitare lo squilibrio di titolarità quando un utente deve essere titolare di molti record.
• Quando i record diventano inattivi, quando vengono archiviati, per quanto vengono conservati, e quando l’eliminazione è giusta.

Quando guardi un modello fisico, non chiederti solo dove sono memorizzati i dati. Chiediti chi ne è titolare oggi, chi potrebbe esserlo domani, e cosa succede quando non ci servono più. Il prossimo argomento: anche con l’oggetto, i campi, le relazioni e il titolare giusti, i dati devono restare affidabili.

Per approfondire

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (in inglese), consultato il 2026-10-13: i titolari (un utente, o una coda per oggetti personalizzati, casi e lead) ottengono l’accesso completo; la maggior parte della condivisione sta in un oggetto di condivisione collegato; la gerarchia dei ruoli viene ricavata in fase di esecuzione; le condivisioni manuali vengono rimosse quando il titolare cambia, la condivisione gestita da Apex resta; i valori del motivo della riga.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (in inglese), consultato il 2026-10-13: AccountShare, MyCustomObject__Share; gli oggetti dettaglio non hanno un oggetto di condivisione; cosa l’oggetto di condivisione non registra (impostazioni predefinite a livello di organizzazione, gerarchia dei ruoli, Visualizza tutto e Modifica tutto).
• Guida di Salesforce, Implicit Sharing (opens in a new tab) (in inglese), consultato il 2026-10-13: l’accesso tra un account e i suoi contatti, casi e opportunità.
• Guida di Salesforce, About High-Volume Community or Site Users (opens in a new tab) e Sharing Rule Considerations (opens in a new tab) (in inglese), consultato il 2026-10-13: niente ruoli, niente regole di condivisione o condivisioni manuali; al loro posto i set di condivisione.
• Corso Sharing and Visibility Architect: I 22 modi di Steve per condividere un record, Impostazioni predefinite a livello di organizzazione, titolarità, code e gerarchia dei ruoli, Le relazioni e la condivisione integrata, Condivisione programmatica e codice sicuro, Condividere con gli utenti esterni, La condivisione su larga scala.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) e Parent-Child Data Skew (opens in a new tab) (in inglese), consultato il 2026-10-02.