Steve Trucking, cosa progetterei io

🌐 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 6 di 6 del capitolo Dati master e identità, capitolo 6 del corso Data Architect, e la fine della Parte 1. Precedente: Quando l’autorità è condivisa · Successivo: la Parte 2 comincia con Progettare per la scala (coming soon)

La domanda a cui risponde questo checkpoint: Sai mettere insieme la Parte 1 su uno scenario reale?

Prova prima la sfida. Questa è la mia soluzione commentata della sfida del Checkpoint 1. Se non hai ancora disegnato il tuo progetto, fallo prima di continuare a leggere. Il valore sta nel confrontare il tuo ragionamento con il mio, non nel leggere la risposta.

Questo è “Cosa progetterei io”: una possibile soluzione praticabile, non la risposta, con i trade-off dichiarati e le mie posizioni prese. Non abbiamo ancora trattato grandi volumi di dati, progettazione delle query, pattern di integrazione, migrazione o transazioni, ed è voluto: l’architettura si sviluppa man mano che impari di più. Ma la Parte 1 ci dà abbastanza per fissare lo scheletro.

Parti dai numeri

Dal brief: circa 3.300 consegne per giorno lavorativo, un milione all’anno, in crescita del 30% l’anno. Circa 1,6 voci per consegna (1,6 milioni all’anno); circa otto cambi di stato per consegna (8 milioni all’anno); da quattro a cinque milioni di foto all’anno; circa 200.000 letture GPS al giorno; circa 180.000 casi all’anno; tre Partner retail che inviano i manifesti in tre modi diversi; nove centri di distribuzione; 330 camion con squadre di due persone. E Steve Trucking ha già una org Salesforce con Service Cloud, Field Service e un portale per i partner. Conta gli zeri prima di disegnare un solo riquadro. Decideranno diverse cose qui sotto.

Il cuore delle consegne: guarda alla nave madre

Le consegne sono il cuore di tutto, e Field Service fa già il dispatch. Quindi parto dal modello standard di Field Service, come ha fatto la porzione del capitolo 3:

Concetto di business	Oggetto Salesforce	Perché
Partner retail	Account (tipo di record Retail Partner)	Un’azienda con cui Steve Trucking ha un contratto; porta contratti, casi e accesso al portale
Personale del partner (responsabili dei CD, personale dei negozi)	Contatto	Gli utenti del portale devono essere Contatti
Una consegna: un Destinatario, un indirizzo, un ordine del partner, un giorno	Ordine di lavoro (Work Order)	L’unità di lavoro di Field Service; pianificazione, app mobile e report di servizio vi sono collegati
Ogni articolo o servizio: il frigorifero, l’installazione, il ritiro dell’usato	Voce dell’ordine di lavoro (Work Order Line Item)	Suddivide il lavoro, guida checklist e fatturazione
Il tipo di tappa: solo consegna, con installazione, con ritiro dell’usato	Tipo di lavoro (Work Type)	Imposta durata, competenze e checklist di installazione
La visita pianificata e la sua fascia oraria	Appuntamento di servizio (Service Appointment)	Ciò che Field Service pianifica e che l’app della squadra mostra
Squadre e camion; aree di dispatch dei CD	Service Resource, Service Crew, Service Territory	Field Service pianifica una squadra come un’unica risorsa
Richieste dei Destinatari, reclami dei partner	Caso	La console di assistenza, gli entitlement, l’email-to-case
L’elenco del partner per martedì al CD di Phoenix	Manifest__c (personalizzato)	Niente di standard rappresenta l’unità di ricezione, riconciliazione e rielaborazione

Tutto il resto resta standard. Resistere a ulteriori oggetti personalizzati è voluto: la domanda del capitolo 1 era quando un architetto dovrebbe resistere a un altro oggetto, e qui la risposta è “quasi sempre”. La riga d’ordine del partner, per esempio, non è un nuovo oggetto. È l’Ordine di lavoro, identificato dal riferimento del partner.

Click to enlarge

Cresce dal finale del capitolo 3 (Progetta il modello fisico Salesforce): gli stessi oggetti negli stessi posti, con l’aggiunta della squadra, dell’area di dispatch, del caso e di ciò che il Checkpoint 1 tiene fuori dal core.

La chiave che abbina l’ordine di un partner a una consegna

Ogni riga del manifesto diventa un Ordine di lavoro, collegato al suo Manifesto. La chiave è la domanda a cui voglio di più una risposta: come sappiamo che questa riga del partner è quella consegna? La mia risposta: un ID esterno sull’Ordine di lavoro costruito dal Partner retail e dal riferimento d’ordine e di consegna del partner stesso (qualcosa come KEYSTONE-PHX-8843119-1), segnato come unico. Un campo per fonte, uno-a-uno. È l’identificatore del partner, non il nostro: la “diversi identificatori per una cosa” del capitolo 2, e il “il partner possiede il proprio riferimento d’ordine” del modulo 1.

Perché conta: i manifesti arrivano con uno o due giorni di anticipo e vengono modificati il giorno stesso. Con quella chiave, ogni manifesto reinviato o modificato fa un upsert invece di creare duplicati. La modifica aggiorna l’Ordine di lavoro, un campo la registra, e una modifica a una consegna già assegnata a un percorso avvisa il coordinatore: la modifica del partner viene applicata, ma segnalata finché il dispatch non la conferma. È anche questo che cambia rispetto al quadro del capitolo 4. Oggi ogni manifesto arriva in RouteDesk, e i coordinatori ridigitano i percorsi in Salesforce e le tappe completate all’indietro. In questo progetto i manifesti arrivano direttamente in Salesforce, con un upsert sulla chiave del partner; RouteDesk viene dismesso, e la ridigitazione finisce. Il capitolo sull’integrazione progetta i tre formati in entrata. La decisione sui dati è la chiave.

Il Destinatario: account personale, Contatto o nessuno dei due?

È la decisione sui dati più interessante della Parte 1, quindi ecco le opzioni, poi la mia scelta.

Opzione A: account personali. Ogni Destinatario diventa un account personale, collegato a ogni consegna. A favore: standard, funziona in modo naturale con Service Cloud, la messaggistica e la console, riconosce i Destinatari ricorrenti. Contro: circa un milione di nuovi Destinatari all’anno, ciascuno un account personale che occupa circa il doppio dello spazio di un account aziendale (Estimated Record Size by Object Type (opens in a new tab)), quindi entro due anni uno degli oggetti più grandi della org. E i Destinatari non sono clienti di Steve Trucking. Sono clienti di ciascun Partner retail, e Steve Trucking non deve mai mescolare il cliente di un partner con quello di un altro (S2).

Opzione B: Contatti sotto l’account del Partner retail. Contro: un milione di Contatti sotto tre o quattro account è uno squilibrio padre-figlio su scala enorme, ben oltre l’indicazione di Salesforce di circa 10.000 figli per padre (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab)). È l’opzione da mostrare, e da scartare.

Opzione C: il Destinatario vive sulla consegna. Nome, telefono, email, indirizzo e note di consegna del Destinatario sono campi sull’Ordine di lavoro (i campi dell’indirizzo lì sono già standard), acquisiti dal manifesto. A favore: nessun nuovo oggetto voluminoso; i dati vivono esattamente quanto serve alla consegna; la cancellazione avviene consegna per consegna, secondo i tempi del partner; e l’isolamento tra partner arriva gratis, perché ogni consegna appartiene a un solo partner. Contro: un Destinatario ricorrente non viene riconosciuto come la stessa persona.

È questo l’equilibrio da trovare. Ci sarà mai bisogno di riconoscere più consegne come la stessa persona, nello stesso posto? Di dare a quella persona un accesso? È questa la linea tra un Destinatario che ha bisogno di un record tutto suo e i dati del Destinatario che sono semplicemente dati sulla consegna. E c’è una via di mezzo. Porta l’ID cliente del Partner retail come campo sulla consegna, un Retail Partner Customer ID (ID cliente del Partner retail). Non crea un record Destinatario, ma lega tra loro le consegne che un partner invia per lo stesso cliente, il che è l’inizio di un’esperienza cliente più unificata, e riporta dritto al sistema del Partner retail, dove quel cliente vive davvero. È il loro identificativo, quindi ha senso solo insieme al partner: il cliente 4417 di un partner non ha niente a che fare con quello di un altro.

Secondo il mio giudizio professionale, l’Opzione C è la scelta giusta. Il mancato riconoscimento è accettabile, perfino desiderabile: Steve Trucking non ha alcuna relazione con queste persone oltre la consegna. È di nuovo il modulo 1: il Destinatario è il cliente del partner, e il partner è l’autorità su chi sia. Ed è il capitolo 5: dati personali che finiscono in un solo posto, legati a una sola consegna, sono molto più facili da proteggere, conservare e cancellare. E regge alle forme normali del capitolo 2: i dati del Destinatario sono uno a uno con la consegna, quindi appartengono alla consegna. Un figlio Destinatario separato risparmierebbe qualche valore ripetuto al prezzo di un altro oggetto, un’altra relazione e il suo costo, e l’unico modo in cui risparmierebbe di più sarebbe trattare la stessa persona come una sola tra Partner retail diversi, cosa che non faremo. Quindi la consegna porta con sé il Destinatario, con il Retail Partner Customer ID come via di ritorno al sistema del partner.

Click to enlarge

Unificherei i Destinatari tra i partner?

John Smith, 123 Main Street, compare nel manifesto di Redrock e in quello di Brightwave. Probabilmente la stessa persona. Steve Trucking dovrebbe unificarli? No, deliberatamente no. Unificare i Destinatari tra Partner retail violerebbe S2: un partner non deve mai vedere i Destinatari di un altro partner, e un’identità unificata è esattamente il ponte da cui passano le fughe di dati. È la posizione di questo capitolo applicata: corrispondi di meno dove mescolare costa caro, e qui mescolare costa carissimo.

Se un Partner retail in futuro volesse il riconoscimento dei Destinatari ricorrenti all’interno delle proprie consegne, sarebbe un lavoro per uno strumento di risoluzione dell’identità, come quello di Data 360, limitato a quel partner: una mappa in stile registry, non un account personale, e mai tra partner diversi. Una mappa di chi è chi non concede la titolarità, e non concede l’accesso.

Cosa resta nella org, e cosa no

Il capitolo 3 chiedeva dove dovrebbero risiedere i dati. Qui rispondono gli zeri:

• Lo stato attuale vive sull’Appuntamento di servizio e sull’Ordine di lavoro. Lo storico dei cambi di stato, circa 8 milioni all’anno e in crescita, non ha bisogno di vivere nella org core. Ogni cambiamento viene pubblicato come evento e conservato nel data warehouse, Snowflake. La org conserva lo stato attuale; lo storico è comunque disponibile per assistenza, operazioni e analisi, solo non nel database operativo.
• Le foto (da quattro a cinque milioni all’anno, alcune che mostrano persone o l’interno di una casa) vivono fuori dal core, in uno spazio di archiviazione costruito per quel volume, caricate direttamente dall’app della squadra. La org conserva solo ciò che le serve: un piccolo record indice per foto, o solo un conteggio e un flag “foto di installazione richieste complete”. La mia preferenza va all’opzione più leggera: tenere snella la org, e lasciare che l’archivio delle foto possieda il proprio indice e la propria conservazione.
• Le letture GPS (200.000 al giorno) restano in FleetLink e vanno in Snowflake; alla org serve solo l’ultima posizione per la pagina di tracciamento e la mappa di chi fa dispatch.
• Gli otto anni di storico di RouteDesk (circa 5 milioni di consegne) vanno nel data warehouse o in un archivio, raggiungibili per i reclami. Cosa entri nella org, se qualcosa entra, è una decisione di migrazione per la Parte 2.

Click to enlarge

Checkpoint 1: cosa progetterei io. Gli stessi posti del panorama del capitolo 4 (Il panorama di Steve Trucking), senza più la ridigitazione e il foglio di calcolo.

Chi vede cosa, e chi ha bisogno di una licenza

• I Partner retail vedono solo le proprie consegne (S2). Ogni Ordine di lavoro porta il suo Partner retail; gli utenti del portale vedono le consegne del proprio partner, e i responsabili dei CD solo quelle del proprio CD.
• Gli utenti dei partner hanno bisogno di una licenza del portale che supporti regole di condivisione e ruoli: Customer Community Plus o Partner Community. I posti allo stadio del capitolo 3: i posti più economici non hanno la condivisione di cui questo progetto ha bisogno. Entrambe le licenze richiedono ruoli per gli utenti esterni, e Salesforce avverte che più ruoli rallentano la org (Experience Cloud User Licenses (opens in a new tab), in inglese). Un ruolo per partner e per CD va bene; un ruolo per ogni negozio no.

Da sapere per l’esame. Sappi quali licenze esterne prevedono la condivisione standard: Customer Community Plus e Partner Community (con i ruoli per gli utenti esterni), non Customer Community, che usa i set di condivisione.

• I Destinatari non hanno bisogno di una licenza. La pagina di tracciamento mostra una consegna tramite un link con un token che scade (S3), non un accesso.
• Attenzione allo squilibrio. Centinaia di migliaia di Ordini di lavoro all’anno che puntano a tre o quattro account di partner sono uno squilibrio dei dati sugli account. Un’opzione è un account figlio per ogni CD sotto ciascun partner, che distribuisce i figli su nove o più padri; archiviare le consegne completate dopo la finestra dei reclami mantiene basso il numero di figli attivi per padre. La Parte 2 affronta il tema.

Cosa non farei

Non creerei un account personale per ogni Destinatario perché un Destinatario è un individuo. Non appenderei un milione di Contatti a tre account. Non costruirei un oggetto Consegna personalizzato accanto all’Ordine di lavoro di Field Service. Non unificherei i Destinatari tra i partner. Non metterei milioni di foto o di letture GPS nello spazio di archiviazione del core. E non chiamerei golden record un Destinatario unificato a meno di aver davvero preso una decisione di gestione dei dati master.

Cosa resta aperto

La Parte 1 ha fissato lo scheletro; la Parte 2 lo mette alla prova. Il righello dei grandi volumi al terzo anno (Ordini di lavoro, Appuntamenti di servizio e voci sono tutti territorio da grandi volumi entro due o tre anni), la progettazione delle query per le viste elenco limitate a un partner, le tre integrazioni in entrata e i tre flussi di stato, la migrazione di RouteDesk, le transazioni del giorno stesso, e il progetto di sicurezza dietro il portale. Anche Steve Trucking cambierà. Tieni questo progetto; ci tornerai.

Cosa decide qui un architetto

• Quali oggetti standard reggono il cuore (qui, quelli di Field Service), e quali oggetti personalizzati sono davvero giustificati (qui, uno).
• La chiave che abbina la riga d’ordine di ogni partner a una consegna, e perché appartiene al partner.
• Cos’è il Destinatario, in base alla relazione che Steve Trucking ha davvero con lui.
• Se unificare le identità, e dove mescolare costa troppo per rischiare.
• Cosa resta nella org, cosa vive fuori dal core, e da quali licenze dipende il progetto.

Per approfondire

• Il brief di Steve Trucking e le sue sfide (D1, D3, DC1).
• Guida di Salesforce, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) e Experience Cloud User Licenses (opens in a new tab) (in inglese), consultato il 2026-10-14.
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (in inglese), come citato nel capitolo 3.