Progetta il modello fisico 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

Modulo 10 di 10 del capitolo Architettura dei dati Salesforce, capitolo 3 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Mantenere i dati coerenti · Successivo: la guida allo studio del capitolo, poi il prossimo capitolo, Capire i dati aziendali

La domanda a cui risponde questo modulo: Come trasformiamo il nostro modello logico in un’architettura Salesforce?

Questo capitolo è stato un unico lungo ragionamento sul fatto che la piattaforma ha una forma: oggetti standard e personalizzati, luoghi in cui possono risiedere i dati, tipi di campo, relazioni, titolarità, licenze, regole di coerenza, spazio di archiviazione e scala. Ognuno di questi elementi può cambiare il modo in cui si costruisce il modello logico del capitolo 2. Ora mettiamo tutto insieme su una porzione di Steve Trucking.

Una porzione, non l’intera azienda. Un errore che vedo fare agli architetti è cercare di risolvere l’intera azienda in un solo diagramma. Voglio qualcosa su cui possiamo ragionare: un Partner retail invia un manifesto di carico, Steve Trucking consegna ciò che contiene, e conserviamo ciò che ci serve su ogni consegna. Poi prendiamo le decisioni fisiche una alla volta. Il progetto completo è il checkpoint della Parte 1.

Parti da ciò che sappiamo già

Il capitolo 2 ha fatto il lavoro concettuale: Partner retail, Destinatario, Manifesto di carico, Consegna, Articolo della consegna, il tipo di tappa, Squadra, Camion, Centro di distribuzione, foto. Abbiamo dato un nome alle relazioni e ci siamo chiesti cosa significano. Non lo ripeto. La domanda ora è come quei concetti vivono su Salesforce. Un fatto del brief conta subito: Steve Trucking usa già Field Service per appuntamenti, squadre e app mobile.

Partner retail: non inventare un Account

Un Partner retail è un’azienda per cui lavora Steve Trucking. Salesforce ha già un oggetto progettato per le aziende: Account. Adattamento pulito. Quindi niente Retail_Partner__c solo perché il business dice “partner”. È un Account, con un tipo di record Retail Partner per distinguerlo dalle altre organizzazioni, e con esso arrivano contratti, casi, Contatti per i responsabili dei CD e l’accesso al portale per quei Contatti. Decisione facile. Non lo sono tutte.

Il numero d’ordine del partner non è la nostra identità

Ogni Partner retail invia i propri riferimenti. L’ordine di un partner ha l’aspetto 8843119, quello di un altro A-984732. Quei numeri contano, ma di chi sono? Del partner. Salesforce ha il proprio ID del record, e il partner ha il riferimento che usa quando parla con noi. Possono esistere entrambi; è la “una cosa, diversi identificatori” del capitolo 2.

Quindi il riferimento del partner diventa un ID esterno che l’integrazione usa per abbinare gli aggiornamenti. E siccome due partner potrebbero usare lo stesso numero, l’identità è il partner più il riferimento, non il riferimento da solo. Non fare del numero di un partner l’identità universale della consegna perché è arrivato per primo, e non costringere un’integrazione a cercare in un campo di testo ogni volta che deve trovare un record.

Consegna: guarda alla nave madre

Qui si è tentati di creare Delivery__c. Il business ha detto “consegna”, quindi ci serve un oggetto Consegna. È esattamente ciò che non voglio che tu faccia per prima cosa. Guarda alla nave madre, come abbiamo fatto nel modulo 2. Cosa ha già Salesforce per un lavoro svolto in un luogo, con un ciclo di vita, degli articoli, una pianificazione e una squadra sul campo? L’Ordine di lavoro (Work Order) di Field Service: Salesforce lo descrive come lavoro di field service da svolgere per un cliente (WorkOrder (opens in a new tab)). La visita pianificata con la sua fascia oraria è l’Appuntamento di servizio (Service Appointment), ed è ciò che il dispatch pianifica e che l’app della squadra mostra.

Quindi Consegna → Ordine di lavoro. Non perché le parole coincidano; non coincidono. Perché il comportamento coincide con la funzionalità della piattaforma che stiamo già pagando e intendiamo usare. Un oggetto standard non deve condividere il vocabolario del business. Deve rappresentare correttamente il concetto.

Click to enlarge

Passo 1 di 4: la nave madre. Ogni scheda è il concetto di business, con il suo oggetto Salesforce sotto.

Ma gli oggetti standard si portano dietro un bagaglio

L’altra metà: l’Ordine di lavoro non è gratis. Porta con sé le licenze Field Service, le sue relazioni, il suo comportamento di sicurezza, campi obbligatori, automazione e ciclo di vita, e altre parti della piattaforma si aspettano che si comporti in un certo modo. Lo scegliamo perché l’adattamento è pulito e usiamo ciò che vi è costruito intorno. Se Steve Trucking non volesse niente di Field Service e il modello combattesse il processo a ogni passo, ci ripenserei. L’architettura è l’adattamento, non l’etichetta.

Articoli della consegna: segui il modello

Una volta che la Consegna è un Ordine di lavoro, guarda il resto di quel modello prima di inventare qualsiasi cosa. Una Voce dell’ordine di lavoro (Work Order Line Item) è un’attività secondaria di un ordine di lavoro (WorkOrderLineItem (opens in a new tab)): il frigorifero, l’installazione, il ritiro dell’usato. Quindi Articolo della consegna → Voce dell’ordine di lavoro. Nota che la prima decisione ha dato forma alla seconda. Non stiamo scegliendo un oggetto per ogni entità presa da sola. Adotta un modello, e capiscine il resto prima di costruirci intorno strutture personalizzate.

Che tipo di tappa è?

In Steve Trucking una tappa è solo consegna, consegna con installazione o consegna con ritiro dell’usato, e ogni tipo ha la sua durata, le competenze della squadra e la checklist di installazione. Nel capitolo 2 abbiamo deciso che è un’entità, non un’etichetta. Field Service ne ha già una: il Tipo di lavoro (Work Type), un modello per un tipo di lavoro che si può applicare agli ordini di lavoro e alle loro voci (WorkType (opens in a new tab)). Quindi Tipo di tappa → Tipo di lavoro. Di nuovo, non perché esista qualcosa chiamato Tipo di lavoro, ma perché il concetto e il comportamento coincidono.

Click to enlarge

Passo 2 di 4: segui il modello. Le voci e il Tipo di lavoro arrivano con l’Ordine di lavoro.

Manifesto di carico: ora voglio un oggetto personalizzato

Esiste un oggetto standard per “l’elenco del partner per martedì al CD di Phoenix”? Non proprio, e non lo forzerò in un oggetto che non c’entra solo per dire che siamo rimasti sullo standard. Manifesto di carico → Manifest__c. È l’unità di ricezione: da dove è arrivato (un file, un batch via API), quando, il suo stato e i suoi totali, e, quando un partner lo reinvia il giorno stesso, cosa viene confrontato. Ogni riga del manifesto diventa un Ordine di lavoro collegato a esso.

Personalizzato non è un fallimento. È ciò che la piattaforma ci dà quando un concetto non ha una sede standard pulita. L’errore non è creare un oggetto personalizzato; è crearne uno senza controllare se la piattaforma ha già quel concetto.

Click to enlarge

Passo 3 di 4: l’unico oggetto personalizzato, dove nessun oggetto standard si adatta.

Foto: il fatto che Salesforce possa memorizzarle non significa che debba farlo

“Ci servono le foto delle consegne in Salesforce.” Cosa significa “in Salesforce”? Gli utenti hanno bisogno di vederle da Salesforce, sì. Significa che i file delle immagini devono risiedere nello spazio di archiviazione del core? Non necessariamente. Conta gli zeri: circa quattro foto per consegna, di più con le installazioni, su un milione di consegne all’anno, sono da quattro a cinque milioni di foto all’anno, e le consegne crescono del 30% l’anno.

Quindi la mia posizione di partenza: non trasformare la org core in un gigantesco archivio di foto perché gli utenti hanno bisogno di accedere alle foto. I file appartengono a uno spazio di archiviazione costruito per quel volume, fuori dal core, con Salesforce che conserva ciò che serve per trovarle e mostrarle: un riferimento, un conteggio o un piccolo record indice per foto, e un flag che indica che le foto di installazione richieste sono complete. L’accesso ai dati e il luogo in cui i dati risiedono fisicamente sono due domande diverse. È il modulo 4 che ritorna.

Campi: rendi visibile il significato

L’Ordine di lavoro ha bisogno di campi: il riferimento del partner, la fascia di consegna, l’orario effettivo di consegna, lo stato, note come “codice del cancello” o “cane in giardino”. Non lo trasformerò in un catalogo di campi; l’ha fatto il modulo 6. Applica le domande a ciascuno: cosa significa, chi ne è responsabile, se cambia, se è un identificatore, un vocabolario controllato, memorizzato o derivato, sensibile. Il riferimento del partner è l’ID esterno, quindi la sua unicità fa parte del contratto di integrazione, non è solo una casella. L’orario effettivo di consegna è un momento, quindi Data/ora. Lo stato guida il comportamento, quindi un elenco controllato, mai testo libero. E le note di consegna sulla casa di una persona sono dati personali, quindi vengono classificate. Ogni campo si riconduce a un significato.

Relazioni: non limitarti a collegare i riquadri

Account con Ordine di lavoro, Ordine di lavoro con le sue voci, Manifesto di carico con Ordine di lavoro, Tipo di lavoro che descrive la tappa. Poi le domande del modulo 7 per ogni linea: il figlio può esistere da solo, chi ne è titolare, l’accesso viene ereditato, può spostarsi, cosa succede all’eliminazione, quanti figli possono accumularsi? Ogni Ordine di lavoro sotto una manciata di account di Partner retail significa centinaia di migliaia di figli per padre: una questione di squilibrio a cui risponderemo nella Parte 2. E per le relazioni standard di Field Service, controlla come le ha già costruite Salesforce invece di dare per scontato che coincidano con ciò che avremmo progettato noi. Quando adotti un modello standard, adotti le decisioni che Salesforce ha preso al suo interno. Capiscile prima di costruirci sopra.

Titolarità e Destinatario: non lasciare che decida l’impostazione predefinita

Due decisioni che un’impostazione predefinita prenderebbe volentieri al posto nostro.

Chi è titolare di una consegna? Ci abbiamo risposto nel modulo 8, e la risposta passa direttamente all’Ordine di lavoro: qui la titolarità non determina l’accesso di nessuno, quindi l’utente di integrazione è titolare degli Ordini di lavoro che crea. Chi fa dispatch vede quelli del proprio centro di distribuzione, le squadre quelli dei loro percorsi, e ogni Partner retail i propri tramite il portale, tutto attraverso la condivisione, non la titolarità. L’utente di integrazione non ha un ruolo e resta fuori dai gruppi pubblici usati dalle nostre regole di condivisione, perché a 3.300 al giorno supera i 10.000 record in tre giorni. E mettiamo per iscritto cosa succede se quell’utente viene mai sostituito.

Che cos’è il Destinatario? Un Contatto? Un account personale? Qualcosa conservato solo sulla consegna? Dipende da se Steve Trucking ha davvero una relazione con queste persone (sono i clienti dei Partner retail), se un partner potrà mai vedere quelli di un altro, per quanto tempo i loro dati personali possono essere conservati, e dalla scala: circa un milione di nuovi Destinatari all’anno. Non abbiamo ancora tutte queste informazioni, e va bene. A volte la risposta giusta è non sappiamo ancora abbastanza. Metti per iscritto la domanda e vai a procurarti le informazioni; non seppellire l’incertezza in un oggetto personalizzato. Rispondiamo al checkpoint della Parte 1, dopo che i capitoli dal 4 al 6 ci avranno dato il quadro dei dati aziendali e dei dati master.

Coerenza: proteggi il modello al livello giusto

Vale la scala del modulo 9: il riferimento del partner è un ID esterno, unico, quindi un manifesto reinviato fa un upsert invece di duplicare; lo stato è un elenco con restrizioni; l’orario effettivo di consegna è obbligatorio solo quando lo stato dice Consegnata; una tappa con installazione non può chiudersi senza checklist e foto. Non un unico flow gigante. Ogni regola sul suo gradino.

Dove vive ogni pezzo

Un ultimo passaggio sulla porzione, con la domanda del modulo 4: dove vive ogni dato? Nelle slide del mio corso è una sola slide, logico contro fisico: le entità logiche del capitolo 2, e dove ciascuna finisce fisicamente: sul core, come sObject (__c se è personalizzato) o big object (__b), oppure fuori dal core, come oggetto esterno (__x) o come dati che non entrano mai in Salesforce.

• Sul core, usati ogni giorno: l’Account, gli Ordini di lavoro e le loro voci, gli Appuntamenti di servizio, i Tipi di lavoro, Manifest__c.
• Sul core, archiviati: le consegne più vecchie di tre anni passano in Delivery History, un big object, ancora lì per i reclami, fuori nel capanno.
• Referenziati: i dettagli dell’ordine del Partner retail restano nel sistema del partner; conserviamo il riferimento del partner come ID esterno, e raggiungiamo il resto tramite un oggetto esterno o l’integrazione quando qualcuno ne ha bisogno.
• Fuori dal core: le foto, in uno spazio di archiviazione costruito per milioni di immagini, con un link dall’Ordine di lavoro.

Questo è il modello fisico: non solo quale oggetto, ma quale casa.

Ora guarda l’intera porzione

• Partner retail → Account, con un tipo di record Retail Partner; i responsabili dei CD come Contatti.
• Consegna → Ordine di lavoro di Field Service, pianificato tramite un Appuntamento di servizio.
• Articolo della consegna → Voce dell’ordine di lavoro.
• Tipo di tappa → Tipo di lavoro.
• Manifesto di carico → Manifest__c personalizzato.
• Riferimento del partner → ID esterno sull’Ordine di lavoro, unico per partner.
• Foto → memorizzate fuori dal core; Salesforce conserva il riferimento e il flag di completezza.
• Storico delle consegne (Delivery History) → archiviato in un big object dopo tre anni.
• Titolarità → l’utente di integrazione, con l’accesso tramite la condivisione (modulo 8).
• Destinatario → aperto, per il checkpoint della Parte 1.

Click to enlarge

Passo 4 di 4: l’intera porzione, sul core, archiviata e fuori dal core. Ogni linea è una relazione di ricerca: Salesforce ha costruito Field Service sulle relazioni di ricerca, e insieme al modello adottiamo le sue decisioni.

Il diagramma non è l’architettura

Posso consegnarti quel diagramma, e non basta. L’architettura è il ragionamento che c’è dietro. Perché Account? Un’azienda, adattamento pulito. Perché Ordine di lavoro e non Delivery__c? La consegna si comporta come un lavoro sul campo, e Field Service c’è già. Perché un Manifesto personalizzato? Nessuna sede standard pulita. Perché le foto non sono semplicemente File? Volume ed economia dello spazio di archiviazione. Perché un ID esterno? Un altro sistema ha bisogno di un’identità stabile oltre il confine. Perché l’utente di integrazione è titolare degli Ordini di lavoro? Qui la titolarità non determina l’accesso, e così la traccia di audit resta onesta. Perché il Destinatario è ancora aperto? Non abbiamo ancora risposto a domande sufficienti. Le linee sono il risultato; le decisioni le hanno prodotte.

Quindi ecco l’abitudine con cui voglio che tu lasci il capitolo 3. Indica qualsiasi cosa in un modello fisico e chiedi perché? Perché questo oggetto, questo tipo, questa relazione, questo titolare, questo luogo, questa regola? Dovresti poter ricondurre la risposta all’indietro: dalla configurazione al modello fisico, al modello logico, al requisito di business. Se non ci riesci, qualcuno ha progettato partendo da Imposta.

E avrai notato i numeri che non abbiamo ancora elaborato del tutto: consegne per partner, voci, foto, conservazione, archiviazione. Bene. Chiedi il numero di zeri prima di bloccare un progetto: un modello che funziona benissimo con cinquantamila record può comportarsi in modo molto diverso con cinquecento milioni. È la Parte 2.

Oltre l’esame: cosa cambia l’IA. Dai a un’IA il brief di Steve Trucking e produrrà uno schema in pochi secondi: Account, Ordine di lavoro, oggetti personalizzati, campi, perfino i metadati per il deployment. È un acceleratore fantastico, e non è la revisione. Il lavoro dell’architetto si sposta sul controllo delle corrispondenze e delle loro conseguenze: adattamento, licenze, titolarità, ciclo di vita, scala, identità, sicurezza e ciò che resta fuori dalla piattaforma. L’IA è il razzo propulsore; non ti dice se stai puntando nella direzione giusta.

Cosa decide qui un architetto

• Come ogni concetto di business corrisponde a Salesforce: un oggetto standard, un oggetto personalizzato o qualcosa fuori dal core.
• Quali identificatori, campi e relazioni implementano il significato di business senza cambiarlo in silenzio.
• Quale comportamento della piattaforma e quali licenze arrivano con un modello standard che adotti.
• Quali decisioni su titolarità, ciclo di vita, coerenza, spazio di archiviazione e scala vanno prese prima che il progetto sia completo.
• Quali domande restano esplicitamente aperte, invece di nascondersi dietro una scelta di implementazione arbitraria.

All’inizio di questo capitolo ci siamo chiesti come il modello dovrebbe vivere su Salesforce. Questa è l’architettura dei dati Salesforce: non creare oggetti, non memorizzare Imposta, non disegnare riquadri più belli, ma adattare deliberatamente il modello di business alla forma della piattaforma. Ogni struttura è un impegno. Prendi quelli che sai spiegare.

Per approfondire

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) e WorkType (opens in a new tab) (in inglese), consultato il 2026-10-02.
• Il brief di Steve Trucking.