Gerarchie e dati bidirezionali

🌐 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 5 di 6 del capitolo Dati master e identità, capitolo 6 del corso Data Architect. Ogni modulo si regge da solo. Precedente: Una mappa non è una decisione · Successivo: Checkpoint 1: Steve Trucking

La domanda a cui risponde questo modulo: Come gestisci dati che più di un sistema mantiene?

L’architettura facile: l’ERP possiede il cliente, Salesforce ne riceve una copia, fatto. Le aziende reali non sono così ordinate. L’ERP possiede il cliente legale e Salesforce la relazione commerciale; una divisione vive in SAP, una acquisita in un altro ERP; i potenziali clienti esistono solo in Salesforce. Poi qualcuno vuole che gli utenti Salesforce aggiornino un campo controllato dall’ERP, e le frecce iniziano a puntare in entrambe le direzioni. Come dico quando lo insegno: “La cosa più difficile sono i bidirezionali.” Non perché inviare dati in entrambe le direzioni sia tecnicamente difficile, ma perché quando entrambi i sistemi partecipano al cambiamento, devi essere estremamente preciso sull’autorità.

Dati bidirezionali non significa due master

L’ERP possiede l’indirizzo di fatturazione, copiato in Salesforce. Un commerciale viene a sapere dal cliente che è cambiato, e il business vuole che lo aggiorni senza uscire da Salesforce. Ragionevole. Ora i dati scorrono ERP → Salesforce e Salesforce → ERP. Salesforce ora condivide la titolarità dell’indirizzo di fatturazione? No. La direzione di un’integrazione non decide l’autorità. Il commerciale non sta modificando la copia di Salesforce. Dal punto di vista architetturale, sta chiedendo di modificare il valore autorevole. Non stai cambiando il campo dell’ERP; stai chiedendo di cambiarlo. Salesforce è l’interfaccia; l’ERP è ancora il master.

Questo cambia il progetto. Se Salesforce possedesse il campo, salva e fatto. Se lo possiede l’ERP, “salva” significa che Salesforce invia l’indirizzo proposto, l’ERP lo convalida e lo accetta, aggiorna il suo master, e rimanda indietro il valore autorevole. Solo allora il valore governato è cambiato: richiesta → convalida → accettazione → pubblicazione, non “aggiorna entrambi i sistemi e spera che restino sincronizzati”.

Click to enlarge

Un’integrazione bidirezionale non crea un’autorità bidirezionale.

Quando il master dice no

L’ERP rifiuta la modifica: il cliente è inattivo, l’indirizzo viola una regola dell’ERP, l’utente non può modificare gli indirizzi legali, l’ERP è giù, o qualcun altro ha modificato il cliente nel frattempo. Se Salesforce mostrava già il nuovo indirizzo, ora abbiamo due verità, e il modulo 1 ci ha già detto quale vince: quella dell’ERP. Quindi l’architettura ha bisogno di uno stato per richiesto, non ancora accettato: un valore proposto separato, un flag “modifica in attesa”, o l’attesa della conferma prima di mostrarlo. Il meccanismo dipende dal caso d’uso. La regola no: non lasciare mai che una richiesta rifiutata si trasformi in una verità concorrente.

Loop e collisioni

Eccone uno classico. L’ERP aggiorna Salesforce; l’integrazione di Salesforce vede una modifica e la invia all’ERP; l’ERP vede un aggiornamento e lo rimanda indietro. Hai costruito un loop molto costoso. Un buon progetto bidirezionale sa dove è partita una modifica, se il master l’ha accettata, e se si tratta di una nuova modifica di business o solo dell’eco di una già elaborata: identificatori di origine, timestamp, metadati di integrazione, elaborazione idempotente. Il capitolo sull’integrazione approfondisce. Il principio dei dati master è semplice: sappi se stai originando una modifica o ne stai riflettendo una.

Poi le collisioni. Ne hai incontrata una nel capitolo 5: un commerciale chiede Steve’s Plumbing LLC mentre qualcuno nell’ERP digita Steve’s Plumbing L.L.C. (Proteggi il record governato). Eccone un’altra. Salesforce propone 125 Main Street; quasi nello stesso momento un utente dell’ERP lo cambia in 130. Quale vince? Non c’è una risposta tecnica universale. Forse vince sempre l’ERP perché possiede il campo; forse la richiesta di Salesforce va in una coda di revisione; forse vince la modifica accettata più tardi; forse l’ERP rifiuta ogni aggiornamento il cui valore di partenza è cambiato. È concorrenza, ma sotto c’è una decisione sull’autorità, e nessun pattern di integrazione può salvarti se nessuno ha deciso chi può fare la modifica autorevole.

E un singolo campo è il caso semplice. Un indirizzo è una via, una città, un codice postale. Salesforce invia una nuova via mentre l’ERP ha appena cambiato la città. Lasci passare la via da sola? Oppure tratti l’indirizzo come una sola transazione, così i campi passano tutti insieme o nessuno, e rifiuti l’intera modifica? Decidi quali campi viaggiano come gruppo prima della prima collisione, non dopo.

Ogni volta che vedo un’integrazione bidirezionale, chiedo cosa succede quando entrambe le parti modificano gli stessi dati? Se la risposta è “probabilmente non succederà”, non abbiamo finito. Quale vince, rifiutiamo, mettiamo in coda, confrontiamo le versioni, facciamo una revisione? Il campo dovrebbe proprio essere modificabile in entrambi i posti? A volte il miglior progetto bidirezionale elimina una direzione per un dato attributo: Salesforce può richiedere; solo l’ERP pubblica il valore accettato. I dati si muovono ancora in entrambe le direzioni, ma un solo sistema gestisce il campo come master. Quella differenza è tutto.

Anche le gerarchie sono dati master

Anche le relazioni possono essere dati master. Una capogruppo globale con regioni in Nord America ed Europa, ciascuna con controllate nei singoli paesi: la gerarchia stessa porta significato. Chi è la capogruppo? Quale controllata sta sotto quale entità legale? Quali account confluiscono nel cliente globale? Questo guida reportistica, territori, prezzi, contratti, esposizione creditizia, assistenza, accesso ai dati e analisi. Una gerarchia può contare quanto i record che contiene, e ha bisogno della stessa governance. (L’esame cita la gestione delle gerarchie; è facile dimenticarla.)

Su Salesforce, le gerarchie di account si costruiscono con il campo Account principale (Parent Account). La vista della gerarchia in Lightning mostra fino a 2.000 account, e solo quelli che l’utente può vedere; gli account personali non sono supportati nella gerarchia; e la Sede dell’account (Account Site) distingue le sedi di un’azienda (Considerations for Using Account Hierarchy (opens in a new tab)). Ma il campo Account principale non risponde alla domanda architetturale: chi possiede la gerarchia?

Da sapere per l’esame. Conosci le basi della gerarchia degli account: si costruisce con Account principale (Parent Account); la vista Lightning mostra fino a 2.000 account, solo quelli che l’utente può vedere; gli account personali non sono supportati; e la Sede dell’account (Account Site) distingue le sedi di un’azienda.

Una gerarchia, diversi master

Nella mia esperienza, le gerarchie hanno un’autorità divisa. Le entità nordamericane vengono da SAP, quelle europee da un altro ERP, i nuovi potenziali clienti vengono costruiti in Salesforce, e una controllata acquisita non è ancora migrata. Chi possiede la gerarchia? Dipende dal ramo. Ogni ERP controlla il proprio ramo; Salesforce controlla le relazioni dei potenziali clienti finché non vengono convertiti. È un’architettura legittima, purché tutti sappiano dove sono i confini. Decidi ramo per ramo.

Click to enlarge

L’autorità sulla gerarchia si può assegnare ramo per ramo.

Quindi non lasciare che il campo Account principale nasconda l’autorità. Un utente assegna in Salesforce una controllata a un’altra capogruppo. Tecnicamente banale. Architetturalmente, ha appena cambiato la struttura legale dell’azienda? Se l’ERP gestisce quel ramo come master, probabilmente no, quindi Salesforce dovrebbe bloccarlo, o trasformarlo in una richiesta di modifica. Oppure Salesforce mantiene legittimamente una gerarchia commerciale mentre l’ERP mantiene quella legale. Allora forse non dovrebbero proprio essere la stessa relazione.

Un’azienda può avere diverse gerarchie valide: legale, di fatturazione, di vendita, di assistenza, geografica. La capogruppo globale firma il contratto, le regioni ricevono assistenza per conto proprio, la fatturazione passa da un’entità finanziaria condivisa, le vendite gestiscono per regione. Qual è la vera gerarchia? Tutte; rispondono a domande diverse. L’errore è dare per scontato che ce ne debba essere una sola. Dovrebbe esserci un’autorità chiara per ogni tipo di relazione: il principio degli attributi del modulo 1, applicato alle relazioni.

E non ogni relazione padre-figlio è un dato master. Raggruppare le consegne di oggi su un percorso è una relazione, ma è transazionale, un evento operativo. Una gerarchia di clienti descrive una relazione di business duratura. Entrambe sembrano padre-figlio in un modello; non condividono un ciclo di vita. Chiediti cosa significa la relazione e quanto dura quel significato.

Un cliente, due ERP

Quando lo insegno chiedo all’aula: chi ha lavorato con un cliente che ha un solo Salesforce e più di un ERP? Le mani si alzano ogni volta. Chiedi perché, e scopri che gli ERP sono divisi per regione (uno per il Nord America, uno per l’Europa), per funzione (un’azienda di impianti idraulici compra un’azienda di impianti elettrici, e ognuna tiene il proprio ERP), o semplicemente per ragioni storiche: l’azienda è stata acquisita, e nessuno l’ha ancora migrata.

Prendi Steve’s Plumbing come cliente. Fa affari in Nord America, quindi l’ERP nordamericano ha un record cliente per lei. Poi apre un ufficio a Monaco di Baviera, e l’ERP europeo crea un proprio record cliente, con il proprio numero cliente. Stessa azienda, due record, due ID. Come la rappresento in una sola org Salesforce? Ho visto tre modi.

Una gerarchia di account. Steve’s Plumbing è l’account padre, con Steve’s Plumbing North America e Steve’s Plumbing Europe come account figli, ogni figlio a rappresentare il record di un ERP. Il problema: i figli non sono più davvero Steve’s Plumbing. Sono Steve’s Plumbing che opera in una regione, e come abbiamo appena visto, una gerarchia porta con sé un significato.

Account paritetici. Due account fianco a fianco, ciascuno con un campo che dice a quale ERP appartiene: un codice società, una regione. Non c’è niente di nascosto. Il costo si vede nei report: per vedere Steve’s Plumbing in tutto il mondo, ti serve qualcosa che dica che questi due account sono la stessa azienda.

Un solo account, con un figlio per ogni ERP. Una sola Steve’s Plumbing, e un oggetto figlio con un record per ogni ERP che contiene l’ID cliente di quell’ERP. Due ERP o dieci. I commerciali vedono un solo cliente e inseriscono un solo ordine; dietro le quinte, dei flow decidono a quale ERP va ogni riga: i lavori elettrici all’ERP degli impianti elettrici, quelli idraulici all’ERP degli impianti idraulici. Ma ora devi decidere quale ERP è il primario per i valori condivisi, come il nome e l’indirizzo, e cosa succede quando il cliente esiste in un ERP e non nell’altro.

Click to enlarge

Un cliente, due ERP: tre modi di rappresentarlo in Salesforce.

Chiedi come mantengono sincronizzati gli ERP

Quindi, quale? Primo: quanta parte della struttura degli ERP devono vedere i commerciali? Se hanno sempre saputo che Nord America ed Europa sono business separati, perché accedono all’uno o all’altro ERP, non nasconderglielo. Porta quella struttura in Salesforce come account paritetici. Se il business vuole una sola Steve’s Plumbing davanti alle vendite, stai guardando un solo account con un figlio per ogni ERP.

Poi la domanda che decide davvero, e non si decide in Salesforce. Chiedo al cliente: come mantenete sincronizzati quei due record tra i vostri ERP? Non le cose locali a ciascun ERP, come il saldo; quelle sono transazionali. Intendo i dati master: la ragione sociale, gli indirizzi. Se hanno un team che mantiene sincronizzati i due ERP, possiamo riunirli in un solo account. Se non riescono a mantenerli sincronizzati nei loro stessi ERP, come possono aspettarsi che li manteniamo sincronizzati noi in Salesforce? Allora sono account paritetici, o una gerarchia.

Ricorda cos’è un ERP. Sono sistemi enormi che richiedono anni per essere messi in piedi, e arrivano con il loro modo di gestire i dati master. Non sarà Salesforce a guidarli. Non controlliamo noi gli ERP. Controlliamo come li rappresentiamo in Salesforce.

L’MDM nel mezzo

Alcuni clienti hanno già risolto il problema prima del nostro arrivo. Una grande azienda, molti anni di attività, diversi ERP: hanno incontrato questo problema molto prima di Salesforce e hanno messo nel mezzo un prodotto MDM dedicato per fare da intermediario tra gli ERP. È l’MDM di coesistenza o centralizzato del modulo 2. Ora Salesforce non si collega a ogni ERP. Punta a un solo posto, l’hub MDM, e ottiene un’unica rappresentazione del cliente. Non aspettarti di incontrarne spesso, però. Sono grandi implementazioni a sé stanti; in tutti i miei anni ci ho lavorato solo due o tre volte. E anche con l’hub, potrebbe servirti comunque quell’oggetto figlio, così ogni ordine sa a quale ERP va.

Click to enlarge

L’MDM nel mezzo: Salesforce punta a un solo posto.

Steve Trucking: di chi è la gerarchia?

Un Partner retail ha la sua struttura: capogruppo, divisioni regionali, centri di distribuzione, negozi. Steve Trucking possiede quella gerarchia? No; il partner è l’autorità sulla propria organizzazione. Ma Steve Trucking potrebbe aver bisogno di una propria vista commerciale di quelle stesse sedi, per contratti, gestione dell’account, assistenza e reportistica, magari un account figlio per ogni CD sotto il partner. Due gerarchie legittime, due autorità. Dai loro un nome, e non fingere che un solo albero rappresenti ogni relazione.

Rendi visibili i confini

Ogni volta che l’autorità è divisa, voglio che il confine sia visibile: nomi dei campi, metadati dei record, identificatori dei sistemi di origine, autorizzazioni, comportamento delle integrazioni, documentazione. Ciò che non voglio è uno sviluppatore che legge cinque integrazioni per scoprire che “questi valori di Account principale vengono da SAP, tranne i potenziali clienti, tranne l’Europa”. Non è un modello delle autorità manutenibile. Se la gerarchia ha un’autorità divisa, documenta la divisione. Se l’autorità cambia alla conversione, documenta il cambiamento. Se Salesforce può richiedere una modifica ma non farla, rendilo evidente nell’esperienza.

In Salesforce, si comincia da un campo. Serve un campo che dica chiaramente che questi sono dati master: la chiave dell’ERP, o un flag “è un dato master”. Fai dipendere la modificabilità dei campi da quel campo, non da un tipo di record; con i Moduli dinamici (Dynamic Forms) non ti serve più un tipo di record per mostrare in sola lettura i campi dell’ERP (capitolo 5, Un tipo di record per ogni flusso). Puoi consentire la creazione di record al di fuori del master, ma tieni d’occhio le modifiche.

Oltre l’esame: cosa cambia l’IA. Un cliente dice a un agente: “cambiate il nostro indirizzo di fatturazione in 125 Main Street”. Il campo è lì, in Salesforce. L’agente dovrebbe aggiornarlo? No, se lo possiede l’ERP. Un agente ha bisogno di autorità di scrittura, non solo di accesso al campo: la sua azione dovrebbe codificare il percorso approvato, inviando una richiesta di modifica e dicendo “ho inviato la modifica perché venga elaborata”, non dichiarando falsamente “ho aggiornato il vostro indirizzo di fatturazione”.

Cosa decide qui un architetto

• Se una modifica in Salesforce cambia dati autorevoli o richiede una modifica al sistema che li possiede.
• Come i flussi bidirezionali distinguono le modifiche originarie dagli echi, e gestiscono rifiuti, collisioni, latenza e guasti.
• Chi possiede ogni gerarchia, ramo per ramo se necessario.
• Per un cliente presente in più ERP: una gerarchia, account paritetici, o un solo account con un figlio per ogni ERP, a seconda di quanto bene il cliente mantiene sincronizzati i propri ERP.
• Se gerarchie in concorrenza sono in realtà relazioni legittime diverse: legale, di fatturazione, di vendita, di assistenza.
• Come i confini di autorità e i percorsi di scrittura approvati vengono resi visibili a utenti, integrazioni, sviluppatori e agenti.

L’autorità condivisa non è il problema. Lo è l’autorità ambigua. Più ERP possono gestire come master rami diversi, Salesforce può gestire alcuni attributi e richiedere modifiche ad altri, e più gerarchie possono descrivere un’unica azienda. Tutto questo funziona, purché per ogni attributo e relazione importante tu sappia dire chi lo possiede, chi può modificarlo, dove si fa la modifica autorevole, e cosa succede quando i sistemi non sono d’accordo. Se non sai dirlo, un’altra freccia bidirezionale nel diagramma non risolverà nulla.

Per approfondire

• Guida di Salesforce, Considerations for Using Account Hierarchy (opens in a new tab) (in inglese), consultato il 2026-10-14.