Salta ai contenuti

I modelli dati standard

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)

An aisle of a builders' supply warehouse, its racks stacked with ready-made standard doors, windows and stair parts, a cart waiting in the aisle.
Immagine generata con l'IA

Modulo 2 di 10 del capitolo Architettura dei dati Salesforce, capitolo 3 del corso Data Architect. Ogni modulo si regge da solo. Precedente: La piattaforma dati Salesforce: più di un database · Successivo: Costruisci il tuo: gli oggetti personalizzati

La domanda a cui risponde questo modulo: Cosa ha già modellato Salesforce per te, e come è costruito?

Nel modulo 1 ti ho detto di guardare alla nave madre: prima di inventare qualcosa, guarda come lo fa Salesforce stessa. In questo modulo guardiamo davvero. Salesforce ha già modellato per te una buona parte del business, nei suoi oggetti standard, e due di quei modelli fanno quasi tutto il lavoro nella maggior parte delle org in cui entro: il modello Sales e il modello Service. Prima di poter decidere se qualcosa merita un oggetto personalizzato, devi sapere cosa c’è già. Ne parlano i prossimi due moduli.

Un oggetto standard arriva già pronto. L’ha costruito Salesforce, ha uno scopo definito, e porta con sé i propri campi e le proprie relazioni. Puoi aggiungergli campi, costruirci intorno automazioni e cambiarne i layout, ma non puoi riprogettarlo: i campi e le relazioni standard sono di Salesforce.

Guarda i nomi. Account, Contact, Case. Nessun prefisso, nessun suffisso. È Salesforce che tiene quello spazio per sé. Tutto ciò che costruiamo noi finisce in __c, così Salesforce può aggiungere nuovi oggetti standard in qualsiasi momento senza mai scontrarsi con qualcosa nella tua org. E lo fa, a ogni release.

A un certo punto qualcuno ha costruito un oggetto prodotto che non ha funzionato e ha dovuto essere lasciato indietro. Ecco perché il nome API è Product2. È la mia prima cartina di tornasole quando qualcuno mi dice di conoscere Salesforce.

Parti da sinistra, con il Lead: qualcuno che potrebbe diventare cliente. Un lead non fa ancora davvero parte del modello. È un’area di attesa. Quando lo converti, Salesforce crea i record veri: un Account, un Contatto e, se c’è una trattativa, un’Opportunità. Ecco perché disegno il Lead in disparte.

L’Account è l’azienda. I suoi Contatti sono le persone che ci lavorano. Un’Opportunità è una trattativa con quell’account. Finora, niente che non ti aspettassi.

Poi si fa interessante. Cosa c’è nella trattativa? Ogni riga è un Prodotto opportunità (Opportunity Product), e un Prodotto opportunità non punta direttamente a un Prodotto. Punta a una Voce del listino prezzi (Price Book Entry): questo prodotto, a questo prezzo, in questo listino prezzi. La Voce del listino prezzi sta tra il Prodotto e il Listino prezzi (Price Book), così lo stesso prodotto può avere un prezzo nel listino prezzi standard e un altro nel listino prezzi dei partner.

Sono due relazioni diventate cose, una dopo l’altra. Ricordi l’Articolo della consegna del capitolo 2, tra la Consegna e il Prodotto, e l’Esercizio del cane tra il Cane e l’Esercizio? Salesforce ha fatto esattamente la stessa cosa qui, due volte: il Prodotto opportunità tra l’Opportunità e la Voce del listino prezzi, e la Voce del listino prezzi tra il Prodotto e il Listino prezzi. Quando sai leggere questo, sai leggere gran parte del modello dati standard.

Il modello Sales Il modello Sales. Un Lead, in disparte a sinistra, si converte in un Account. Un Account ha Contatti e Opportunità. Un'Opportunità usa un Listino prezzi e contiene Prodotti opportunità. Ogni Prodotto opportunità prende il prezzo da una sola Voce del listino prezzi. Un Listino prezzi elenca Voci del listino prezzi, e un Prodotto compare in Voci del listino prezzi, quindi ogni Voce del listino prezzi unisce un Prodotto e un Listino prezzi. si converte in ha ha usa contiene prende il prezzo da elenca compare in Lead Account Contatto Opportunità Listino prezzi Prodotto opportunità Voce del listino prezzi Prodotto esattamente uno zero o uno uno o molti zero o molti © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Ecco quella catena da vicino, con i campi che la tengono insieme:

La catena dei prezzi da vicino La catena dei prezzi come modello dati dettagliato. Un Prodotto opportunità porta l'ID della sua Opportunità, l'ID della sua Voce del listino prezzi, una quantità e un prezzo di vendita, e prende il prezzo da una sola Voce del listino prezzi. La Voce del listino prezzi porta l'ID del suo Listino prezzi, l'ID del suo Prodotto, un prezzo di listino e un indicatore Usa prezzo standard. Un Listino prezzi ha un nome e un indicatore È standard; un Prodotto ha un nome e un codice prodotto. prende il prezzo da elenca compare in Listino prezzi ID listino prezzi ID DEL RECORD Nome È standard Prodotto opportunità ID prodotto opportunità ID DEL RECORD ID opportunità ID voce del listino prezzi Quantità Prezzo di vendita Voce del listino prezzi ID voce del listino prezzi ID DEL RECORD ID listino prezzi ID prodotto Prezzo di listino Usa prezzo standard Prodotto ID prodotto ID DEL RECORD Nome Codice prodotto esattamente uno zero o uno uno o molti zero o molti © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Una regola su cui le persone inciampano: esiste un listino prezzi standard, e una Voce del listino prezzi in qualsiasi altro listino può semplicemente usare il prezzo standard del prodotto. Sappi quale listino prezzi usa un’opportunità prima di caricarne i prodotti.

Ora l’altro lato della casa. Stesso Account, stessi Contatti. Quando qualcosa va storto, il cliente apre un Caso.

Il caso riguarda di solito qualcosa che il cliente possiede, e Salesforce ha un oggetto per questo: l’Asset. Nel modulo 5 lo chiamerò l’oggetto standard che le persone trascurano. È una cosa che il cliente possiede, che l’abbia comprata da te o no.

E a cosa ha diritto il cliente? È il Diritto (Entitlement): l’assistenza che un account ha titolo a ricevere, spesso legata a un asset, a un prodotto o a un contratto di assistenza. Metti un diritto su un caso, e ora il caso sa quale livello di assistenza dovrebbe ricevere.

Il modello Service Il modello Service. Un Account ha Contatti, Casi e Asset. Un Contatto segnala Casi. Un Caso può riguardare un solo Asset, e un Diritto (Entitlement), che appartiene a un Account, copre Casi. Una linea che dal Caso torna su se stesso, girando attorno al suo angolo, è il Caso principale: un caso è il padre di zero o molti casi, e ogni caso ha zero o un padre. ha ha segnala possiede riguarda copre padre di Account Contatto Asset Caso Diritto esattamente uno zero o uno uno o molti zero o molti © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Guarda la linea che dal Caso torna al Caso stesso. Ogni caso ha un campo Caso principale (Parent Case), e punta a un altro caso. È un’auto-relazione di ricerca (self-lookup): una relazione da un oggetto a sé stesso. Confonde molte persone la prima volta che la vedono, quindi ecco i due motivi per cui la uso.

Uno: un grosso problema che si scompone in problemi più piccoli. Il cliente segnala che l’intera installazione è ferma. Apriamo sotto-casi per la rete, l’hardware e la configurazione, ognuno lavorato per conto suo, e si risolvono tutti verso l’alto: il caso principale non è chiuso finché non lo sono loro.

Due: lo storico. Un caso è stato chiuso il mese scorso, e ora lo stesso problema è tornato. Il nuovo caso punta all’originale, così chiunque lo apra può vedere che è già successo, e cosa si è fatto.

Torneremo sulle auto-relazioni di ricerca quando arriveremo alle relazioni nel modulo 7.

Nota che l’Account e il Contatto stanno nello stesso posto in entrambi i diagrammi. Sono gli stessi record. Chi vende e chi fa assistenza guardano lo stesso cliente, da lati diversi della casa. È uno degli argomenti più forti per restare sullo standard: i modelli sono stati costruiti per incontrarsi.

Non tutto ciò che sta su un record è un campo. Contratti, foto, PDF e fogli di calcolo sono file, e il loro posto è Salesforce Files, non il vecchio modello degli Allegati, che è legacy. Se il documento si trova già in SharePoint Online, OneDrive, Google Drive o Box, Files Connect permette agli utenti di raggiungerlo da Salesforce senza copiarlo dentro.

I file vengono contati in modo diverso dai record. Salesforce divide lo spazio in due: lo spazio per i file contiene allegati, File, Salesforce CRM Content, file di Chatter e simili, e lo spazio per i dati contiene i tuoi record. Lo spazio per i file sale in fretta quando ogni record riceve foto o scansioni, quindi grandi volumi di immagini, come le foto di un’app sul campo, spesso stanno meglio del tutto fuori da Salesforce, con Salesforce che conserva solo un link. Il modulo 4 ci torna sopra.

Anche lo spazio per i dati viene contato in modo diverso rispetto a un database. In un database normale, una tabella con due colonne e un milione di righe è piccola, e una tabella con cento colonne e un milione di righe è un elefante. Salesforce le pesa allo stesso modo: la maggior parte dei record conta circa 2 KB, indipendentemente da quanti campi abbia. Ci sono eccezioni. Una campagna conta di più, un messaggio email conta per la sua dimensione reale, e un account personale conta circa 4 KB, perché è un account e un contatto.

Ecco un consiglio. Ogni volta che entro in una nuova org, uno dei primi posti dove vado è Imposta → Utilizzo memoria (Storage Usage). Chiedo perfino al cliente uno screenshot alla prima chiamata. Quella schermata non mente. Ti dice quali oggetti stanno crescendo, e quali sono già gli elefanti.

Account personali: quando il cliente è una persona

Sezione intitolata “Account personali: quando il cliente è una persona ”

Il modello Account e Contatto funziona benissimo per un’azienda e le persone che ci lavorano. Ma se il tuo cliente non è un’azienda? Se è una persona?

È l’account personale: un account e un contatto combinati in un unico record, per le singole persone. I campi del contatto vengono inclusi, e quelli personalizzati compaiono con un loro suffisso, __pc. Ognuno conta sia sullo spazio degli account sia su quello dei contatti, perché sotto è entrambe le cose.

Un avvertimento prima di attivarli: una volta abilitati, gli account personali non si possono disabilitare. È il Test di Reversibilità del capitolo 1 nella sua forma più pura. Il modulo 5 ti dà la mia posizione su quando valgono la pena.

  • Quali parti del business Salesforce ha già modellato, prima di progettare qualcosa di nuovo.
  • Se un concetto finisce nel modello Sales, nel modello Service o in entrambi, sapendo che condividono l’Account e il Contatto.
  • Dove risiedono documenti e immagini: Salesforce Files, un file system collegato, o fuori dalla piattaforma con un link.
  • Quanto costeranno i dati in spazio di archiviazione, contati come li conta Salesforce: record, non colonne.
  • Se il cliente è un’azienda o una persona, prima di attivare qualcosa che non si può disattivare.

E quando Salesforce non ha ciò che ti serve? Lo costruisci. È il prossimo argomento.