Hiërarchieën en data in twee richtingen

🌐 Ook beschikbaar in 28 talen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Afbeelding gegenereerd met AI

Vertaald door AI. Nog niet door de community nagekeken. Lees in het Engels

Module 5 van 6 in het hoofdstuk Stamgegevens en identiteit, hoofdstuk 6 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Een kaart is geen beslissing · Volgende: Checkpoint 1: Steve Trucking

De vraag die deze module beantwoordt: Hoe beheer je data die door meer dan één systeem bijgehouden wordt?

De makkelijke architectuur: het ERP is eigenaar van de klant, Salesforce krijgt een kopie, klaar. Echte enterprises zijn niet zo netjes. Het ERP is eigenaar van de juridische klant en Salesforce van de salesrelatie; één divisie leeft in SAP, een overgenomen divisie in een ander ERP; prospects bestaan alleen in Salesforce. Dan wil iemand dat Salesforce-gebruikers een veld bijwerken dat het ERP controleert, en de pijlen gaan twee kanten op wijzen. Zoals ik zeg als ik dit doceer: “The hardest thing are the bi-directionals” (het moeilijkste zijn de tweerichtingsintegraties). Niet omdat data twee kanten op sturen technisch moeilijk is, maar omdat je, zodra beide systemen aan wijzigingen meedoen, uiterst precies moet zijn over zeggenschap.

Data in twee richtingen betekent geen twee masters

Het ERP is eigenaar van het factuuradres, dat naar Salesforce gekopieerd wordt. Een verkoper hoort van de klant dat het veranderd is, en het bedrijf wil dat hij het bijwerkt zonder Salesforce te verlaten. Redelijk. Nu stroomt data ERP → Salesforce en Salesforce → ERP. Is Salesforce nu mede-eigenaar van het factuuradres? Nee. De richting van een integratie bepaalt de zeggenschap niet. De verkoper wijzigt niet de kopie van Salesforce. Architecturaal vraagt hij om de gezaghebbende waarde te wijzigen. Je wijzigt het veld van het ERP niet; je vraagt erom het te wijzigen. Salesforce is de interface; het ERP is nog steeds de master.

Dat verandert het ontwerp. Als Salesforce eigenaar van het veld was: opslaan en klaar. Als het ERP eigenaar is, betekent “opslaan” dat Salesforce het voorgestelde adres stuurt, het ERP het valideert en accepteert, zijn master bijwerkt en de gezaghebbende waarde terugstuurt. Pas dan is de bestuurde waarde veranderd: verzoek → valideren → accepteren → publiceren, niet “beide systemen bijwerken en hopen dat ze gelijk blijven”.

Click to enlarge

Een integratie in twee richtingen maakt geen zeggenschap in twee richtingen.

Als de master nee zegt

Het ERP weigert de wijziging: de klant is inactief, het adres breekt een ERP-regel, de gebruiker mag geen juridische adressen wijzigen, het ERP ligt eruit, of iemand anders heeft de klant intussen gewijzigd. Als Salesforce het nieuwe adres al toonde, hebben we nu twee waarheden, en module 1 vertelde ons al welke wint: die van het ERP. Dus de architectuur heeft een toestand nodig voor aangevraagd, nog niet geaccepteerd: een aparte voorgestelde waarde, een markering “wijziging in behandeling”, of wachten op bevestiging voordat je het toont. Het mechanisme hangt af van de toepassing. De regel niet: laat een geweigerd verzoek nooit een concurrerende waarheid worden.

Lussen en botsingen

Hier is een klassieker. Het ERP werkt Salesforce bij; de integratie van Salesforce ziet een wijziging en stuurt die naar het ERP; het ERP ziet een update en stuurt haar terug. Je hebt een heel dure lus gebouwd. Een goed ontwerp in twee richtingen weet waar een wijziging begon, of de master haar geaccepteerd heeft, en of dit een nieuwe bedrijfswijziging is of alleen de echo van een die al verwerkt is: bronidentificatoren, tijdstempels, integratiemetadata, idempotente verwerking. Het hoofdstuk over integratie gaat er diep op in. Het principe voor stamgegevens is eenvoudig: weet of je een wijziging start of er een weerspiegelt.

Dan botsingen. Je kwam er een tegen in hoofdstuk 5: een verkoper vraagt om Steve’s Plumbing LLC terwijl iemand in het ERP Steve’s Plumbing L.L.C. intypt (Bescherm het bestuurde record). Hier is er nog een. Salesforce stelt 125 Main Street voor; bijna op hetzelfde moment wijzigt een ERP-gebruiker het naar 130. Welke wint? Er is geen universeel technisch antwoord. Misschien wint het ERP altijd omdat het eigenaar van het veld is; misschien gaat het Salesforce-verzoek naar een beoordelingswachtrij; misschien wint de later geaccepteerde wijziging; misschien weigert het ERP elke update waarvan de beginwaarde veranderd is. Dat is gelijktijdigheid, maar daaronder zit een zeggenschapsbeslissing, en geen integratiepatroon kan je redden als niemand besliste wie de gezaghebbende wijziging mag doen.

En één veld is het simpele geval. Een adres is een straat, een plaats, een postcode. Salesforce stuurt een nieuwe straat terwijl het ERP net de plaats veranderd heeft. Laat je de straat er alleen door? Of behandel je het adres als één transactie, zodat de velden allemaal samen gaan of geen van alle, en weiger je de hele wijziging? Beslis vóór de eerste botsing welke velden als groep reizen, niet erna.

Als ik een integratie in twee richtingen zie, vraag ik wat gebeurt er als beide kanten dezelfde data wijzigen? Als het antwoord is “dat gebeurt waarschijnlijk niet”, zijn we niet klaar. Welke wint, weigeren we, zetten we in een wachtrij, vergelijken we versies, beoordelen we? Moet het veld überhaupt op beide plekken bewerkbaar zijn? Soms haalt het beste ontwerp in twee richtingen voor een bepaald attribuut één richting weg: Salesforce mag een verzoek doen; alleen het ERP publiceert de geaccepteerde waarde. Data beweegt nog steeds twee kanten op, maar maar één systeem beheert het veld. Dat verschil is alles.

Hiërarchieën zijn ook stamgegevens

Relaties kunnen ook stamgegevens zijn. Een wereldwijde moeder met regio’s in Noord-Amerika en Europa, elk met dochters per land: de hiërarchie zelf draagt betekenis. Wie is de moeder? Welke dochter valt onder welke juridische entiteit? Welke accounts tellen op tot de wereldwijde klant? Dat stuurt rapportage, verkoopgebieden, prijzen, contracten, kredietrisico, service, datatoegang en analytics. Een hiërarchie kan net zoveel ertoe doen als de records erin, en ze heeft dezelfde governance nodig. (Het examen noemt hiërarchiebeheer; het is makkelijk te vergeten.)

In Salesforce worden accounthiërarchieën gebouwd met het veld Parent Account. De hiërarchieweergave in Lightning toont tot 2.000 accounts, en alleen die de gebruiker mag zien; persoonsaccounts worden niet ondersteund in de hiërarchie; en Account Site onderscheidt de locaties van een bedrijf (Considerations for Using Account Hierarchy (opens in a new tab)). Maar het veld Parent Account beantwoordt de architectuurvraag niet: wie is eigenaar van de hiërarchie?

Examenkennis. Ken de basis van de accounthiërarchie: ze wordt gebouwd met Parent Account (bovenliggend account); de Lightning-weergave toont tot 2.000 accounts, alleen die de gebruiker kan zien; persoonsaccounts worden niet ondersteund; en Account Site onderscheidt de locaties van een bedrijf.

Eén hiërarchie, meerdere masters

In mijn ervaring hebben hiërarchieën gesplitste zeggenschap. De Noord-Amerikaanse entiteiten komen uit SAP, de Europese uit een ander ERP, nieuwe prospects worden in Salesforce opgebouwd, en een overgenomen dochter is nog niet gemigreerd. Wie is eigenaar van de hiërarchie? Het hangt af van de tak. Elk ERP controleert zijn tak; Salesforce controleert de relaties van prospects tot ze omgezet worden. Dat is een legitieme architectuur, zolang iedereen weet waar de grenzen liggen. Beslis per tak.

Click to enlarge

Zeggenschap over een hiërarchie kan per tak toegewezen worden.

Laat het veld Parent Account de zeggenschap dus niet verbergen. Een gebruiker hangt een dochter in Salesforce onder een andere moeder. Technisch triviaal. Architecturaal: heeft hij net de juridische structuur van het bedrijf veranderd? Als het ERP die tak beheert, waarschijnlijk niet, dus moet Salesforce het blokkeren, of er een wijzigingsverzoek van maken. Of misschien houdt Salesforce terecht een commerciële hiërarchie bij terwijl het ERP de juridische bijhoudt. Dan moeten het misschien helemaal niet dezelfde relatie zijn.

Een bedrijf kan meerdere geldige hiërarchieën hebben: juridisch, facturatie, sales, service, geografisch. De wereldwijde moeder tekent het contract, regio’s krijgen zelf service, facturatie loopt via een gedeelde financiële entiteit, sales stuurt per regio. Welke is de echte hiërarchie? Allemaal; ze beantwoorden verschillende vragen. De fout is aannemen dat er één moet zijn. Er moet duidelijke zeggenschap zijn voor elk soort relatie: het attribuutprincipe uit module 1, toegepast op relaties.

En niet elke parent-childrelatie is een stamgegeven. De leveringen van vandaag op één route groeperen is een relatie, maar ze is transactioneel, een operationele gebeurtenis. Een klanthiërarchie beschrijft een duurzame bedrijfsrelatie. Allebei zien ze er in een model uit als parent-child; ze delen geen levenscyclus. Vraag wat de relatie betekent en hoe lang die betekenis duurt.

Eén klant, twee ERP’s

Als ik dit doceer, vraag ik de zaal: wie heeft gewerkt met een opdrachtgever die één Salesforce heeft en meer dan één ERP? Er gaan elke keer handen omhoog. Vraag waarom, en de ERP’s blijken regionaal gesplitst (één voor Noord-Amerika, één voor Europa), functioneel (een loodgietersbedrijf koopt een elektrabedrijf, en elk houdt zijn eigen ERP), of gewoon historisch: het bedrijf is overgenomen, en niemand heeft het nog gemigreerd.

Neem Steve’s Plumbing als de klant. Het doet zaken in Noord-Amerika, dus het Noord-Amerikaanse ERP heeft er een klantrecord voor. Dan opent het een kantoor in München, en het Europese ERP maakt een eigen klantrecord aan, met een eigen klantnummer. Hetzelfde bedrijf, twee records, twee ID’s. Hoe geef ik dat weer in één Salesforce-org? Ik heb drie manieren gezien.

Een accounthiërarchie. Steve’s Plumbing is de parent, met Steve’s Plumbing North America en Steve’s Plumbing Europe als onderliggende accounts, waarbij elk onderliggend account staat voor het record van één ERP. Het addertje: de onderliggende accounts zijn eigenlijk niet meer Steve’s Plumbing. Ze zijn Steve’s Plumbing dat zaken doet in een regio, en zoals we net zagen, draagt een hiërarchie betekenis.

Gelijkwaardige accounts. Twee accounts naast elkaar, elk met een veld dat zegt bij welk ERP het hoort: een bedrijfscode, een regio. Er is niets verborgen. De prijs zie je in de rapportage: om Steve’s Plumbing wereldwijd te zien, heb je iets nodig dat zegt dat deze twee accounts hetzelfde bedrijf zijn.

Eén account, met een onderliggend record per ERP. Eén Steve’s Plumbing, en een onderliggend object met een record voor elk ERP dat de klant-ID van dat ERP bevat. Twee ERP’s of tien. De verkopers zien één klant en plaatsen één order; achter de schermen beslissen flows naar welk ERP elke regel gaat: elektrawerk naar het elektra-ERP, loodgieterswerk naar het loodgieters-ERP. Maar nu moet je beslissen welk ERP primair is voor de gedeelde waarden, zoals naam en adres, en wat er gebeurt als de klant in het ene ERP bestaat en niet in het andere.

Click to enlarge

Eén klant, twee ERP’s: drie manieren om het in Salesforce weer te geven.

Vraag hoe ze de ERP’s synchroon houden

Dus welke? Eerst: hoeveel van de ERP-structuur moeten de verkopers zien? Als ze altijd geweten hebben dat Noord-Amerika en Europa aparte bedrijven zijn, omdat ze op het ene of het andere ERP inloggen, verberg het dan niet voor ze. Neem die structuur als gelijkwaardige accounts mee naar Salesforce. Als het bedrijf één Steve’s Plumbing voor sales wil, kijk je naar één account met een onderliggend record per ERP.

Dan de vraag die echt de doorslag geeft, en die wordt niet in Salesforce beslist. Ik vraag de opdrachtgever: hoe houden jullie die twee records tussen jullie ERP’s synchroon? Niet de dingen die lokaal zijn voor elk ERP, zoals het saldo; dat is transactioneel. Ik bedoel de stamgegevens: de juridische naam, de adressen. Als ze een team hebben dat de twee ERP’s synchroon houdt, kunnen we ze samenbrengen als één account. Als ze ze in hun eigen ERP’s niet synchroon kunnen houden, hoe kunnen ze dan verwachten dat wij ze in Salesforce synchroon houden? Dan worden het gelijkwaardige accounts, of een hiërarchie.

Onthoud wat een ERP is. Dit zijn enorme systemen die jaren kosten om neer te zetten, en ze komen met hun eigen manier om stamgegevens te beheren. Salesforce gaat ze niet aansturen. Wij hebben de ERP’s niet in de hand. Wij bepalen hoe we ze in Salesforce weergeven.

MDM in het midden

Sommige klanten hebben dit al opgelost voordat wij er zijn. Een groot bedrijf, al vele jaren actief, meerdere ERP’s: ze liepen lang vóór Salesforce tegen dit probleem aan en zetten een specifiek MDM-product in het midden om tussen de ERP’s te bemiddelen. Dat is de coëxistentie- of gecentraliseerde MDM uit module 2. Nu verbindt Salesforce zich niet met elk ERP. Het wijst naar één plek, de MDM-hub, en krijgt één weergave van de klant. Verwacht er niet vaak een tegen te komen, hoor. Dit zijn op zichzelf grote implementaties; in al mijn jaren heb ik er maar twee of drie keer met een gewerkt. En zelfs met de hub heb je misschien nog steeds dat onderliggende object nodig, zodat elke order weet naar welk ERP hij gaat.

Click to enlarge

MDM in het midden: Salesforce wijst naar één plek.

Steve Trucking: wiens hiërarchie?

Een retailpartner heeft een eigen structuur: moederbedrijf, regionale divisies, distributiecentra, winkels. Is Steve Trucking eigenaar van die hiërarchie? Nee; de partner heeft de zeggenschap over zijn eigen organisatie. Maar Steve Trucking heeft misschien een eigen commerciële kijk op diezelfde locaties nodig, voor contracten, accountbeheer, service en rapportage, misschien een child-account voor elk distributiecentrum onder de partner. Twee legitieme hiërarchieën, twee zeggenschappen. Benoem ze, en doe niet alsof één boom elke relatie weergeeft.

Maak de grenzen zichtbaar

Als zeggenschap gesplitst is, wil ik de grens zichtbaar hebben: veldnamen, recordmetadata, identificatoren van bronsystemen, rechten, gedrag van integraties, documentatie. Wat ik niet wil, is een developer die vijf integraties moet lezen om te ontdekken “deze Parent Account-waarden komen uit SAP, behalve prospects, behalve Europa.” Dat is geen onderhoudbaar zeggenschapsmodel. Als de hiërarchie gesplitste zeggenschap heeft, documenteer de splitsing. Als de zeggenschap bij de omzetting verandert, documenteer de verandering. Als Salesforce een wijziging kan aanvragen maar niet doorvoeren, maak dat duidelijk in de ervaring.

In Salesforce begint dat met één veld. Er moet een veld zijn dat duidelijk zegt dat dit stamgegevens zijn: de sleutel van het ERP, of een vlag “is stamgegeven”. Stuur de bewerkbaarheid van velden vanuit dat veld, niet vanuit een recordtype; met Dynamic Forms heb je geen recordtype meer nodig om de velden van het ERP alleen-lezen te tonen (hoofdstuk 5, Een recordtype voor elke stroom). Je kunt toestaan dat records buiten de master aangemaakt worden, maar let op de bewerkingen.

Voorbij het examen: wat AI verandert. Een klant vertelt een agent: “verander ons factuuradres in 125 Main Street.” Het veld staat daar gewoon in Salesforce. Moet de agent het bijwerken? Niet als het ERP er eigenaar van is. Een agent heeft schrijfbevoegdheid nodig, niet alleen veldtoegang: zijn actie moet het goedgekeurde pad vastleggen, een wijzigingsverzoek indienen en zeggen “ik heb de wijziging ter verwerking ingediend”, niet ten onrechte melden “ik heb je factuuradres bijgewerkt.”

Wat een architect hier beslist

• Of een bewerking in Salesforce gezaghebbende data wijzigt of een wijziging aanvraagt bij het systeem dat er eigenaar van is.
• Hoe stromen in twee richtingen startende wijzigingen van echo’s onderscheiden, en weigering, botsingen, vertraging en falen afhandelen.
• Wie eigenaar is van elke hiërarchie, zo nodig tak voor tak.
• Voor één klant die in meerdere ERP’s staat: een hiërarchie, gelijkwaardige accounts, of één account met een onderliggend record per ERP, afhankelijk van hoe goed de opdrachtgever zijn ERP’s synchroon houdt.
• Of concurrerende hiërarchieën eigenlijk verschillende legitieme relaties zijn: juridisch, facturatie, sales, service.
• Hoe zeggenschapsgrenzen en goedgekeurde schrijfpaden zichtbaar gemaakt worden voor gebruikers, integraties, developers en agents.

Gedeelde zeggenschap is niet het probleem. Onduidelijke zeggenschap wel. Meerdere ERP’s kunnen verschillende takken beheren, Salesforce kan sommige attributen beheren en wijzigingen in andere aanvragen, en meerdere hiërarchieën kunnen één enterprise beschrijven. Dat werkt allemaal, zolang je voor elk belangrijk attribuut en elke belangrijke relatie kunt zeggen wie eigenaar is, wie het mag wijzigen, waar de gezaghebbende wijziging gedaan wordt, en wat er gebeurt als systemen het oneens zijn. Als je dat niet kunt, lost nog een pijl in twee richtingen op het diagram het niet op.

Verder lezen

• Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).