Architettura dei dati Salesforce

🌐 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

Guida allo studio del capitolo 3 del corso Data Architect. Leggi prima i dieci moduli; questa pagina ti aiuta a verificare cosa ti è rimasto.

Su questa guida allo studio. È costruita solo con i contenuti di questo corso e con l’elenco degli obiettivi della guida all’esame pubblicata da Salesforce. Non si basa mai su domande reali d’esame, e non pretende di sapere cosa c’è nell’esame. Se hai sostenuto l’esame, per favore non mandarmi domande: l’accordo di certificazione vieta di condividerle, e memorizzare le risposte è comunque il modo sbagliato per diventare architetto.

È il capitolo in cui il modello incontra la piattaforma, e porta con sé una buona parte dell’esame. Alimenta entrambe le sezioni più grandi, Data Modeling and Database Design e Salesforce Data Management, ciascuna un quarto dell’esame. I numeri della piattaforma cambiano: la checklist riporta quelli citati dai moduli, con la data in cui sono stati verificati. Impara a cosa serve ogni limite, e controlla il numero attuale prima di farci affidamento.

Per l’esame

Spuntali man mano. Ognuno rimanda al punto in cui è spiegato.

DM-1: progettare il modello dati sulla piattaforma

• So che Salesforce è una piattaforma multitenant guidata dai metadati: un oggetto è un metadato, non una nuova tabella, e ogni oggetto riceve le sue API dal momento in cui esiste. (I metadati sono il progetto, La tua API è arrivata con l’oggetto)
• So che i limiti del governor esistono perché un tenant non possa impadronirsi delle risorse condivise. (Non puoi prenderti l’ascensore)
• So leggere i modelli dati standard: la conversione del Lead in Account, Contatto e Opportunità; un Prodotto opportunità punta a una Voce del listino prezzi (Price Book Entry), che punta a Product2; e Caso, Asset e Diritto (Entitlement) sul lato servizio. (Il modello Sales, Il modello Service)
• So cosa decide la schermata Nuovo oggetto personalizzato (New Custom Object): un nome del record di tipo Testo o Numerazione automatica; la classificazione dell’oggetto (Object Classification: con condivisione, Bulk API e Streaming API attivi è un oggetto Enterprise Application, con questi disattivati un oggetto Light Application); e Consenti ricerca (Allow Search), disattivato per impostazione predefinita. (La schermata Nuovo oggetto personalizzato)
• So leggere un nome API: oggetti e campi standard non hanno prefisso né suffisso; oggetti e campi personalizzati finiscono in __c; un pacchetto gestito aggiunge il suo prefisso dello spazio dei nomi (abc__); e un campo che aggiungi all’oggetto di un pacchetto riceve __c ma mai il prefisso del fornitore. (Prefissi e suffissi)
• So applicare la prova dell’adattamento pulito per un oggetto standard, e so quando significato o peso indicano un oggetto personalizzato. (La prova dell’adattamento pulito)
• So a cosa servono Asset e gli account personali, che un account personale occupa circa il doppio dello spazio di un account aziendale, e che una volta abilitati gli account personali non si possono disabilitare. (Asset è un buon esempio, Account personali, Quando la persona è l’account?)
• Scelgo un tipo di campo per il comportamento che mi serve (un numero di flotta non è un Numero), e so che data/ora è memorizzata in GMT e mostrata nel fuso orario di chi legge, quindi si confronta con intervalli, non con l’uguaglianza. (Un numero non è sempre un numero, Data, Data/ora e Ora)
• So che il testo è di due tipi: fino a 255 caratteri sul record (indicizzabile, utilizzabile come unico o come ID esterno), e testo lungo o RTF oltre quella soglia, senza indice, senza filtri WHERE e senza formule. (La famiglia dei testi)
• So quando usare un Name a numerazione automatica, e che non è l’ID del record. (Una persona ha bisogno di identificarlo?)
• So come un ID esterno permette a un’integrazione di fare un upsert, e di caricare i figli tramite l’ID esterno del padre. (ID esterni)
• So quando un valore dovrebbe essere derivato da una formula, e quando è un fatto storico che va memorizzato. (Memorizzato o derivato?)
• Conosco la differenza tra un oggetto di giunzione logico (l’idea di modellazione: un oggetto che unisce altri due in una relazione molti-a-molti, con attributi propri) e un oggetto di giunzione di Salesforce (Salesforce Junction Object: un oggetto personalizzato con due relazioni master-dettaglio), e so che Salesforce intende il secondo. (Due padri di larghezza)
• Conosco la relazione gerarchica: una relazione di ricerca speciale disponibile solo sull’oggetto Utente, come il campo standard Manager, che non può tornare allo stesso utente né direttamente né indirettamente, e non è la gerarchia dei ruoli. (Gerarchica)
• Conosco la differenza tra una relazione di ricerca e una master-dettaglio: titolarità, condivisione, padre obbligatorio, eliminazione a cascata, campi di riepilogo roll-up. (Relazione di ricerca, Master-dettaglio)
• So che una master-dettaglio non si può creare su un oggetto che contiene già dati (crea una relazione di ricerca, compilala, convertila), può tornare a relazione di ricerca solo senza roll-up sul master, e richiede Consenti riassegnazione dell’elemento principale per spostare un figlio. (Il figlio può cambiare padre?)
• Conosco la forma della piattaforma per la master-dettaglio: fino a tre livelli di dettaglio personalizzati di profondità (una relazione di ricerca può spezzare la catena in qualsiasi punto) e due padri in master-dettaglio di larghezza. In un oggetto di giunzione di Salesforce la master-dettaglio creata per prima è il master primario (titolare, aspetto, divisione), la seconda è il master secondario, e l’accesso richiede entrambi i padri: vince il più restrittivo. (Tre livelli di profondità, Due padri di larghezza)
• Conosco le tre scelte di una relazione di ricerca quando il padre viene eliminato: svuotare il campo (l’impostazione predefinita), bloccare l’eliminazione o eliminare a cascata, che è disattivata finché Salesforce non la abilita e scavalca la condivisione. (Relazione di ricerca)
• So che una relazione con se stessi deve essere una relazione di ricerca, e conosco le due già integrate: l’Account principale dell’Account e il Caso principale del Caso. (Relazioni con se stessi)
• So che il ricalcolo dei roll-up può richiedere tempo, che un roll-up non può usare una formula con NOW(), TODAY() o un riferimento tra oggetti, e che non si sceglie una master-dettaglio solo per avere un roll-up: l’alternativa è un campo memorizzato tenuto aggiornato da un flow o da un trigger. (I roll-up sono utili, ma non sono gratis)
• Conosco i limiti sulle relazioni citati dal modulo: due master-dettaglio per oggetto; 40 campi di relazione per impostazione predefinita (50 al massimo); 25 roll-up per impostazione predefinita (40 al massimo). (Anche le relazioni hanno limiti)

DM-2: un modello che rispetta la condivisione e scala

• So che un figlio in una master-dettaglio non ha né un titolare né una tabella di condivisione propri: l’accesso segue il master. (La titolarità viene con il pacchetto)
• Conosco lo squilibrio padre-figlio: l’indicazione di Salesforce è di non superare circa 10.000 figli su un solo padre. (La domanda dei 10.000 figli)
• Conosco lo squilibrio di titolarità (un utente titolare di più di 10.000 record di un oggetto) e l’indicazione: distribuire la titolarità, oppure tenere quell’utente fuori dalla gerarchia dei ruoli o da solo in cima, e fuori dai gruppi pubblici usati dalle regole di condivisione. (La titolarità può diventare un problema di scala)
• Conosco la tabella di condivisione: l’oggetto di condivisione di un oggetto personalizzato è Object__Share; un oggetto dettaglio non ne ha, il suo accesso viene dal master; e un cambio di titolare rimuove le condivisioni manuali ma mantiene la condivisione Apex con un motivo proprio. (La tabella di condivisione)
• So decidere chi è titolare dei record creati da integrazioni e agenti, in base a se la titolarità determina la condivisione. (Chi è titolare dei record creati dai sistemi?)

DM-4: big object rispetto agli oggetti standard e personalizzati

• Conosco le tre case dei dati: sul core (sObject, usati ogni giorno), referenziati (un altro sistema è la fonte di verità: gli oggetti esterni di Salesforce Connect, __x, o chiamate personalizzate) e archiviati (sul core nei big object, __b, o fuori dal core in un data warehouse). (Sul core e fuori dal core)
• So che gli oggetti esterni fanno una chiamata esterna ogni volta che vengono toccati, quindi contano la latenza e la disponibilità del sistema di origine. (Referenziati)
• Conosco i big object: volumi enormi, interrogati tramite il loro indice per corrispondenza esatta o intervallo, niente interfaccia né reportistica standard, solo autorizzazioni su oggetti e campi, niente automazione. (Archiviati)
• So che la maggior parte dei record conta circa 2 KB di spazio dati indipendentemente dai campi, e che i file si misurano separatamente nello spazio per i file. (Due colonne o duecento, File e allegati)

SDM-1: le licenze e gli oggetti che le persone possono usare

• Conosco le tre licenze interne, Sales Cloud, Service Cloud e Platform, e cosa può usare ciascuna. (Tre licenze interne)
• So che le licenze fanno parte del modello dati: gli utenti Salesforce Platform non hanno Lead, Campagne, Opportunità né Previsioni, e gli utenti Customer Community non possono usare l’Opportunità. (Ora complichiamo tutto: le licenze)
• Conosco i livelli delle licenze esterne: Customer Community, Customer Community Plus (report, dashboard, condivisione standard), Partner Community (oggetti di vendita); e so che Partner Community non si può usare con gli account personali. (Lo stadio)
• Conosco le licenze basate sui membri e quelle basate sugli accessi, e a quale popolazione si adatta ciascuna. (Il modo in cui pagano cambia il progetto)
• So che alcune licenze di piattaforma limitano gli utenti a un’app con al massimo dieci oggetti personalizzati, e conosco il pattern con i tipi di record per lavorare entro quel limite. (Quando la licenza dà forma al modello)
• So che la licenza Salesforce Integration è per utenti da sistema a sistema, solo API. (Le persone non sono più gli unici utenti)
• So che la reportistica sugli SLA richiede entitlement e milestone, che richiedono licenze Service. (Ora complichiamo tutto: le licenze)

SDM-2: mantenere i dati coerenti

• So collocare una regola sul gradino giusto della scala della coerenza: tipo di campo e vocabolario, obbligatorio e unico, regole di convalida, regole duplicati, automazione. (Mantenere i dati coerenti)
• So che un elenco di selezione con restrizioni rifiuta i valori che non sono nell’elenco, anche tramite l’API, e che un set di valori globale condivide un elenco tra più campi (fino a 1.000 valori). (Primo gradino)
• So che un requisito nel layout di pagina protegge solo quella schermata, non i dati, e che le regole di convalida girano a ogni salvataggio. (La convalida nell’interfaccia non è convalida dei dati, Terzo gradino)
• So delimitare una regola di convalida con ISNEW() e ISCHANGED(), un’autorizzazione personalizzata o una data di entrata in vigore, sapendo quali salvataggi (compresi quelli che non controllo, come un cambio di titolare in batch o un roll-up) ogni scelta continua a controllare. (Il problema dei vecchi record)
• Conosco le regole di corrispondenza e le regole duplicati, i limiti citati dal modulo (cinque regole duplicati attive per oggetto, tre regole di corrispondenza ciascuna), e so che non risolvono l’identità tra sistemi. (Quarto gradino: le regole duplicati)
• So che le regole duplicati non confrontano tra loro i record salvati nello stesso momento, che i salvataggi da API e importazione vengono bloccati senza avviso, e che un salvataggio e tutto ciò che mette in moto vengono annullati come un’unica transazione. (Quarto gradino, Tutto o niente)
• So che le Workflow Rules e Process Builder non sono più supportati; automazione significa Flow o Apex. (Quinto gradino: l’automazione)

Oltre l’esame

L’esame è il pavimento, non il soffitto. Queste sono le abitudini di questo capitolo di cui un architetto ha bisogno, che una domanda le chieda o no.

• La piattaforma ha una forma. Progetta per la piattaforma su cui ti trovi, non per un database generico.
• Guarda alla nave madre. Vedi come Salesforce modella un concetto prima di inventarne uno.
• Ogni oggetto è un impegno: spazio di archiviazione, limiti, un modello di condivisione, licenze e dipendenze.
• Chiediti dove risiedono i dati prima di scegliere un oggetto: sul core, referenziati o archiviati.
• Leggi un nome API qualsiasi e saprai chi l’ha creato, e cosa puoi cambiare.
• Se non archiviate oggi, archivierete mai?
• Fai un prototipo dei big object prima di proporli.
• Nomi di business diversi non significano automaticamente oggetti diversi.
• Chiediti quali identità hanno bisogno dei dati: persone, clienti, partner, integrazioni e agenti.
• Ogni campo riceve una descrizione, e una classificazione dove conta.
• Descrivi prima il comportamento della relazione; la configurazione lo implementa. Non distorcere il modello per ottenere una funzionalità.
• La domanda sull’eliminazione: cosa dovrebbe succedere ai figli se qualcuno elimina il padre?
• Scegli quale collegamento spezza la catena: usa la relazione di ricerca dove il figlio ha davvero una vita propria.
• Titolarità dal primario, accesso da entrambi: vince il più restrittivo.
• Separa inattivo da scomparso, e fai della conservazione una regola di business.
• Spingi la regola in basso fin dove le spetta correttamente, e dai allo storico legittimo un’esclusione invece di riscriverlo.
• Il diagramma non è l’architettura. Sappi ricondurre ogni struttura a una ragione di business.

Parole da conoscere

Termine	In una riga
Guidato dai metadati	Oggetti e campi sono definizioni che la piattaforma legge in fase di esecuzione, non nuove tabelle fisiche
Multitenancy	Molte org condividono l’infrastruttura, ciascuna isolata, come appartamenti in un unico edificio
Limiti del governor	Limiti che impediscono a un tenant di monopolizzare le risorse condivise
Oggetto esterno	Dati mostrati in Salesforce tramite Salesforce Connect, recuperati dalla loro fonte a ogni accesso
Big object	Spazio per dati molto voluminosi e usati di rado, interrogati tramite il loro indice
Account personale	Un individuo rappresentato come account, per i modelli business-to-consumer
Adattamento pulito	Un concetto di business che corrisponde allo scopo previsto di un oggetto standard
ID esterno	Un campo che contiene l’identificatore di un altro sistema, usato per upsert e abbinamenti
Upsert	Aggiorna il record se esiste, crealo se non esiste
Relazione di ricerca	Una relazione in cui il figlio conserva il proprio titolare e la propria vita
Master-dettaglio	Una relazione in cui il figlio appartiene al padre: titolare e condivisione ereditati, eliminazione a cascata, roll-up
Oggetto di giunzione logico	L’idea di modellazione: un oggetto che unisce altri due in una relazione molti-a-molti e ha attributi propri, comunque sia costruito
Oggetto di giunzione di Salesforce (Salesforce Junction Object)	Ciò che Salesforce intende per “oggetto di giunzione”: un oggetto personalizzato con due relazioni master-dettaglio
Master primario e secondario	La master-dettaglio creata per prima in un oggetto di giunzione di Salesforce (titolare, aspetto, divisione) e la seconda (ambito dei report; diventa primaria se la prima viene rimossa)
Relazione gerarchica	Una relazione di ricerca speciale disponibile solo sull’oggetto Utente, come Manager, che non può tornare allo stesso utente
Prefisso dello spazio dei nomi	Il prefisso del fornitore sugli oggetti e sui campi di un pacchetto gestito, come abc__Inspection__c
Tabella di condivisione	L’oggetto di condivisione (AccountShare, Truck__Share) che contiene la maggior parte della condivisione di un record, una riga per utente o gruppo, con il suo motivo
Riepilogo roll-up	Un campo sul master che conta, somma o trova il minimo o il massimo dei suoi dettagli
Squilibrio dei dati	Troppi record sotto un solo padre o un solo titolare, che causano blocchi e lunghi ricalcoli della condivisione
Basata sui membri / basata sugli accessi	Pagare per utente esterno, o per accesso ogni mese
Scala della coerenza	I livelli che fanno rispettare le regole sui dati, dal tipo di campo fino all’automazione
Elenco di selezione con restrizioni	Un elenco di selezione che rifiuta qualsiasi valore non presente, da qualsiasi fonte
Classificazione dei dati	Metadati dei campi per responsabile, uso, sensibilità e categoria di conformità

Mettiti alla prova

Brevi scenari nello stile del corso. Decidi la tua risposta prima di aprirla.

1. Gli utenti devono vedere i dettagli degli ordini che l'ERP possiede e aggiorna tutto il giorno. Non li modificano in Salesforce. Li copi o no?

Referenziali: gli oggetti esterni tramite Salesforce Connect mantengono l’ERP come fonte di verità senza una copia da sincronizzare. Accetta che ogni visualizzazione faccia una chiamata esterna, quindi contano la latenza e la disponibilità dell’ERP, e che si adatta meglio all’accesso in lettura che a modifiche o reportistica intense. Rileggi Referenziati.

2. Il business vuole tracciare distributori, fornitori e partner retail. Tre oggetti personalizzati?

No. Sono tutti aziende, quindi Account si adatta in modo pulito; i nomi diversi sono ruoli, portati da un tipo, un tipo di record o una relazione. Rileggi La prova dell’adattamento pulito.

3. Un progetto usa l'Opportunità, ma la maggior parte delle persone che hanno bisogno dei dati ha licenze Salesforce Platform o Customer Community. E ora?

Quelle licenze non possono usare l’Opportunità, quindi la licenza è un vincolo architetturale: comprare licenze diverse, spostare l’esperienza o riprogettare, di solito verso un oggetto personalizzato. Rileggi Ora complichiamo tutto: le licenze.

4. L'ERP invia ogni notte aggiornamenti sugli account. Come dovrebbe l'integrazione trovare il record giusto senza cercare gli ID Salesforce?

Memorizza il numero cliente dell’ERP in un campo ID esterno e fai l’upsert su di esso: aggiorna se lo trova, crea se no. Anche i record figli possono indicare il padre tramite il suo ID esterno. Rileggi ID esterni.

5. Un Articolo della consegna non può esistere senza la sua consegna, non si sposta mai e non ha bisogno di un titolare proprio. Una Consegna esiste prima di essere assegnata a un percorso e può passare a un altro percorso. Quale relazione per ciascuno?

Da Articolo della consegna a Consegna: master-dettaglio (appartiene al padre per tutta la vita, eredita l’accesso, viene eliminato a cascata). Da Consegna a Percorso: una relazione di ricerca (vita propria, inizialmente facoltativa, spostabile, ed eliminare un percorso non deve mai eliminare le consegne). Rileggi Parti dalla relazione di business.

6. Un'integrazione crea 3.300 consegne al giorno, tutte con titolare l'utente di integrazione, che ha un ruolo a metà della gerarchia. Qual è il rischio, e la soluzione?

Squilibrio di titolarità: oltre i 10.000 record, spostare quell’utente o cambiare i suoi gruppi scatena lunghi ricalcoli della condivisione. Distribuisci la titolarità se conta per l’accesso; altrimenti tieni l’utente di integrazione fuori dalla gerarchia dei ruoli, o da solo in un ruolo in cima, e fuori dai gruppi usati dalle regole di condivisione. Rileggi La titolarità può diventare un problema di scala.

7. Aggiungi una regola di convalida, e 20.000 vecchi record la violano. Un utente modifica un numero di telefono su uno di essi e il salvataggio fallisce. Cosa avrebbe dovuto fare la regola?

Dire quando farla rispettare, non solo cosa deve essere vero: delimitarla con ISNEW() o ISCHANGED() sui campi rilevanti, e dare ai record che la precedono un’esclusione deliberata invece di riscriverne la storia. Rileggi Il problema dei vecchi record.

8. Il business vuole ogni foto delle consegne “in Salesforce”: da quattro a cinque milioni all'anno, in crescita del 30 per cento. Cosa proponi?

Separa l’accesso dallo spazio di archiviazione. Tieni i file in uno spazio costruito per quel volume, fuori dalla org core, e conserva in Salesforce un riferimento, un conteggio o un record indice perché gli utenti possano trovarle e vederle. Rileggi Foto.

9. Un'Assegnazione della squadra ha relazioni master-dettaglio con Squadra (creata per prima) e Camion. Chi fa dispatch può vedere la squadra ma non il camion. Può vedere l'Assegnazione della squadra?

No. Squadra è il master primario, quindi dà all’assegnazione il suo titolare e il suo aspetto, ma l’accesso richiede entrambi i padri: chi fa dispatch ha bisogno dell’accesso alla squadra e al camion, al livello richiesto dall’impostazione di condivisione (Sharing Setting) di ciascun campo master-dettaglio. Vince il più restrittivo. Rileggi Due padri di larghezza.

10. Un partner reinvia un file di manifesto, e lo stesso cliente vi compare due volte. Hai una regola duplicati sull'Account impostata per bloccare. Sei al sicuro?

Non con la sola regola duplicati. I record salvati nello stesso momento non vengono confrontati tra loro, solo con i record già presenti in Salesforce, quindi entrambe le righe possono passare. Spingi l’unicità giù fino al campo: un ID esterno unico, che la piattaforma controlla a ogni salvataggio, così ne vince uno solo. Rileggi Quarto gradino: le regole duplicati e Tutto o niente.

Per approfondire

• Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Guida di Salesforce (in inglese, consultato il 2026-09-25): l’elenco ufficiale degli obiettivi e dei loro pesi. Controlla sempre la versione attuale prima di prenotare l’esame.
• La sezione Per approfondire di ogni modulo elenca la documentazione Salesforce dietro i suoi fatti sulla piattaforma, con la data in cui è stata verificata.