Hierarkier og tovejsdata

🌐 Findes også på 28 sprog

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

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 5 af 6 i kapitlet Masterdata og identitet, kapitel 6 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Et kort er ikke en beslutning · Næste: Kontrolpunkt 1: Steve Trucking

Spørgsmålet, dette modul besvarer: Hvordan håndterer du data, som mere end ét system vedligeholder?

Den lette arkitektur: ERP’et ejer kunden, Salesforce får en kopi, færdig. Rigtige virksomheder er ikke så rene. ERP’et ejer den juridiske kunde og Salesforce salgsrelationen; én division lever i SAP, en opkøbt én i et andet ERP; emner findes kun i Salesforce. Så vil nogen have, at Salesforce-brugere kan opdatere et felt, som ERP’et styrer, og pilene begynder at pege begge veje. Som jeg siger, når jeg underviser i det: »Det sværeste er tovejsintegrationerne.« Ikke fordi det er teknisk svært at sende data begge veje, men fordi du, så snart begge systemer deltager i ændringer, skal være ekstremt præcis med autoriteten.

Tovejsdata betyder ikke to mastere

ERP’et ejer fakturaadressen, som er kopieret ind i Salesforce. En sælger hører fra kunden, at den er ændret, og forretningen vil have, at sælgeren opdaterer den uden at forlade Salesforce. Rimeligt. Nu flyder data ERP → Salesforce og Salesforce → ERP. Er Salesforce så medejer af fakturaadressen? Nej. En integrations retning afgør ikke autoriteten. Sælgeren ændrer ikke Salesforces kopi. Arkitektonisk beder sælgeren om at ændre den autoritative værdi. Du ændrer ikke ERP’ets felt; du beder om at ændre det. Salesforce er grænsefladen; ERP’et er stadig masteren.

Det ændrer designet. Hvis Salesforce ejede feltet: gem, og færdig. Hvis ERP’et ejer det, betyder »gem«, at Salesforce sender den foreslåede adresse, ERP’et validerer og accepterer den, opdaterer sin master og sender den autoritative værdi tilbage. Først da har den styrede værdi ændret sig: anmod → validér → acceptér → publicér, ikke »opdatér begge systemer, og håb, at de forbliver synkroniseret«.

Click to enlarge

En tovejsintegration skaber ikke autoritet begge veje.

Når masteren siger nej

ERP’et afviser ændringen: Kunden er inaktiv, adressen bryder en regel i ERP’et, brugeren må ikke ændre juridiske adresser, ERP’et er nede, eller nogen andre har ændret kunden i mellemtiden. Hvis Salesforce allerede viste den nye adresse, har vi nu to sandheder, og modul 1 har allerede fortalt os, hvilken der vinder: ERP’ets. Så arkitekturen har brug for en tilstand for anmodet, endnu ikke accepteret: en separat foreslået værdi, et flag for »afventende ændring« eller at vente på bekræftelse, før den vises. Mekanismen afhænger af brugsscenariet. Reglen gør ikke: Lad aldrig en afvist anmodning blive til en konkurrerende sandhed.

Løkker og kollisioner

Her er en klassiker. ERP’et opdaterer Salesforce; Salesforces integration ser en ændring og sender den til ERP’et; ERP’et ser en opdatering og sender den tilbage. Du har bygget en meget dyr løkke. Et godt tovejsdesign ved, hvor en ændring startede, om masteren har accepteret den, og om det er en ny forretningsændring eller bare ekkoet af en, der allerede er behandlet: kildeidentifikatorer, tidsstempler, integrationsmetadata, idempotent behandling. Kapitlet om integration går i dybden. Masterdataprincippet er enkelt: Vid, om du starter en ændring eller afspejler en.

Så er der kollisioner. Du mødte en i kapitel 5: En sælger beder om Steve’s Plumbing LLC, mens nogen i ERP’et skriver Steve’s Plumbing L.L.C. (Beskyt den styrede post). Her er en til. Salesforce foreslår 125 Main Street; næsten i samme øjeblik ændrer en ERP-bruger den til 130. Hvem vinder? Der findes ikke noget universelt teknisk svar. Måske vinder ERP’et altid, fordi det ejer feltet; måske går anmodningen fra Salesforce til en kø til gennemgang; måske vinder den senest accepterede ændring; måske afviser ERP’et enhver opdatering, hvis udgangsværdi har ændret sig. Det er samtidighed, men nedenunder er det en beslutning om autoritet, og intet integrationsmønster kan redde dig, hvis ingen har besluttet, hvem der må foretage den autoritative ændring.

Og et enkelt felt er det enkle tilfælde. En adresse er en gade, en by, et postnummer. Salesforce sender en ny gade, mens ERP’et lige har ændret byen. Lader du gaden gå igennem alene? Eller behandler du adressen som én transaktion, så felterne enten går samlet eller slet ikke, og afviser hele ændringen? Beslut, hvilke felter der følges ad som en gruppe, før den første kollision, ikke efter.

Når jeg ser en tovejsintegration, spørger jeg: Hvad sker der, når begge sider ændrer de samme data? Hvis svaret er »det sker nok ikke«, er vi ikke færdige. Hvem vinder, afviser vi, sætter vi i kø, sammenligner vi versioner, gennemgår vi? Skal feltet overhovedet kunne redigeres begge steder? Nogle gange fjerner det bedste tovejsdesign én retning for en given attribut: Salesforce må anmode; kun ERP’et publicerer den accepterede værdi. Data bevæger sig stadig begge veje, men kun ét system er master for feltet. Den forskel er alt.

Hierarkier er også masterdata

Relationer kan også være masterdata. En global moderkoncern med regioner i Nordamerika og Europa, hver med datterselskaber i hvert land: Selve hierarkiet bærer betydning. Hvem er forælderen? Hvilket datterselskab ligger under hvilken juridisk enhed? Hvilke konti rulles op til den globale kunde? Det styrer rapportering, salgsområder, priser, kontrakter, kreditrisiko, service, dataadgang og analyse. Et hierarki kan betyde lige så meget som posterne i det, og det har brug for den samme styring. (Eksamen nævner hierarkistyring; det er let at glemme.)

I Salesforce bygges kontohierarkier med feltet Parent Account (overordnet konto). Hierarkivisningen i Lightning viser op til 2.000 konti, og kun dem, brugeren må se; personkonti understøttes ikke i hierarkiet; og Account Site skelner mellem en virksomheds lokationer (Considerations for Using Account Hierarchy (opens in a new tab), på engelsk). Men feltet Parent Account svarer ikke på arkitekturspørgsmålet: Hvem ejer hierarkiet?

Eksamensviden. Kend det grundlæggende om kontohierarkiet: Det bygges med Parent Account; visningen i Lightning viser op til 2.000 konti, kun dem, brugeren kan se; personkonti understøttes ikke; og Account Site skelner mellem en virksomheds lokationer.

Ét hierarki, flere mastere

Min erfaring er, at hierarkier har delt mastering. Nordamerikanske enheder kommer fra SAP, europæiske fra et andet ERP, nye emner bygges i Salesforce, og et opkøbt datterselskab er ikke migreret endnu. Hvem ejer hierarkiet? Det afhænger af grenen. Hvert ERP styrer sin gren; Salesforce styrer relationerne for emner, indtil de konverteres. Det er en legitim arkitektur, så længe alle ved, hvor grænserne går. Beslut det pr. gren.

Click to enlarge

Autoritet over et hierarki kan tildeles gren for gren.

Så lad ikke feltet Parent Account skjule autoriteten. En bruger flytter et datterselskab til en ny forælder i Salesforce. Teknisk trivielt. Arkitektonisk: Ændrede brugeren lige virksomhedens juridiske struktur? Hvis ERP’et er master for den gren, sandsynligvis ikke, så Salesforce bør blokere det eller gøre det til en ændringsanmodning. Eller måske har Salesforce legitimt et kommercielt hierarki, mens ERP’et har det juridiske. Så skal de måske slet ikke være den samme relation.

En virksomhed kan have flere gyldige hierarkier: juridisk, fakturering, salg, service, geografi. Moderselskabet underskriver kontrakten, regionerne får service hver for sig, faktureringen går gennem en fælles økonomienhed, salg styrer efter region. Hvilket er det sande hierarki? Dem alle; de svarer på forskellige spørgsmål. Fejlen er at antage, at der skal være ét. Der skal være klar autoritet for hver type relation: princippet om attributter fra modul 1, anvendt på relationer.

Og ikke alle forælder-barn-relationer er masterdata. At samle dagens leveringer på én rute er en relation, men den er transaktionel, en operationel hændelse. Et kundehierarki beskriver en varig forretningsrelation. Begge ligner forælder-barn i en model; de deler ikke livscyklus. Spørg, hvad relationen betyder, og hvor længe den betydning holder.

Én kunde, to ERP’er

Når jeg underviser i det her, spørger jeg lokalet: Hvem har arbejdet med en klient, der har én Salesforce og mere end ét ERP? Hænderne kommer op hver gang. Spørg hvorfor, og det viser sig, at ERP’erne er delt regionalt (ét for Nordamerika, ét for Europa), funktionelt (et VVS-firma køber et el-firma, og hver beholder sit eget ERP) eller bare historisk: Forretningen blev opkøbt, og ingen har migreret den endnu.

Tag Steve’s Plumbing som kunden. Firmaet driver forretning i Nordamerika, så det nordamerikanske ERP har en kundepost for det. Så åbner det et kontor i München, og det europæiske ERP opretter sin egen kundepost med sit eget kundenummer. Samme virksomhed, to poster, to id’er. Hvordan repræsenterer jeg det i én Salesforce-org? Jeg har set tre måder.

Et kontohierarki. Steve’s Plumbing er forælderen med Steve’s Plumbing North America og Steve’s Plumbing Europe som underordnede konti, hvor hvert barn står for ét ERP’s post. Problemet: Børnene er ikke rigtig Steve’s Plumbing længere. De er Steve’s Plumbing, der driver forretning i en region, og som vi lige så, bærer et hierarki betydning.

Sideordnede konti. To konti side om side, hver med et felt, der siger, hvilket ERP den hører til: en firmakode, en region. Intet er skjult. Prisen viser sig i rapporteringen: For at se Steve’s Plumbing på tværs af verden skal du have noget, der siger, at de to konti er den samme virksomhed.

Én konto med et barn pr. ERP. Én Steve’s Plumbing og et underordnet objekt med en post for hvert ERP, der rummer det ERP’s kunde-id. To ERP’er eller ti. Sælgerne ser én kunde og afgiver én ordre; bag kulisserne afgør flows, hvilket ERP hver linje går til: el-arbejde til el-ERP’et, VVS til VVS-ERP’et. Men nu skal du beslutte, hvilket ERP der er primært for de fælles værdier som navn og adresse, og hvad der sker, når kunden findes i det ene ERP og ikke i det andet.

Click to enlarge

Én kunde, to ERP’er: tre måder at repræsentere det på i Salesforce.

Spørg, hvordan de holder ERP’erne synkroniseret

Så hvilken? Først: Hvor meget af ERP-strukturen skal sælgerne se? Hvis de altid har vidst, at Nordamerika og Europa er separate forretninger, fordi de logger ind i det ene eller det andet ERP, så skjul det ikke for dem. Tag den struktur med ind i Salesforce som sideordnede konti. Hvis forretningen vil have én Steve’s Plumbing foran salg, ser du på én konto med et barn pr. ERP.

Så kommer det spørgsmål, der virkelig afgør det, og det afgøres ikke i Salesforce. Jeg spørger klienten: Hvordan holder I de to poster synkroniseret mellem jeres ERP’er? Ikke det, der er lokalt i hvert ERP, som saldoen; det er transaktionelt. Jeg mener masterdata: det juridiske navn, adresserne. Hvis de har et team, der holder de to ERP’er synkroniseret, kan vi samle dem som én konto. Hvis de ikke kan holde dem synkroniseret i deres egne ERP’er, hvordan kan de så forvente, at vi holder dem synkroniseret i Salesforce? Så bliver det sideordnede konti eller et hierarki.

Husk, hvad et ERP er. Det er massive systemer, der tager år at indføre, og de kommer med deres egen måde at håndtere masterdata på. Salesforce kommer ikke til at styre dem. Vi styrer ikke ERP’erne. Vi styrer, hvordan vi repræsenterer dem i Salesforce.

MDM i midten

Nogle klienter har allerede løst det her, før vi kommer. En stor virksomhed med mange år på bagen og flere ERP’er: De ramte problemet længe før Salesforce og satte et dedikeret MDM-produkt i midten til at formidle mellem ERP’erne. Det er sameksistens- eller centraliseret MDM fra modul 2. Nu forbinder Salesforce sig ikke selv til hvert ERP. Den peger på ét sted, MDM-hubben, og får én repræsentation af kunden. Forvent dog ikke at møde det ofte. Det er store implementeringer i sig selv; i alle mine år har jeg kun arbejdet med en to eller tre gange. Og selv med hubben kan du stadig have brug for det underordnede objekt, så hver ordre ved, hvilket ERP den skal til.

Click to enlarge

MDM i midten: Salesforce peger på ét sted.

Steve Trucking: hvis hierarki?

En detailpartner har sin egen struktur: moderselskab, regionale divisioner, distributionscentre, butikker. Ejer Steve Trucking det hierarki? Nej; partneren er autoriteten for sin egen organisation. Men Steve Trucking kan have brug for sit eget kommercielle billede af de samme lokationer til kontrakter, kundeansvar, service og rapportering, måske en underordnet konto for hvert DC under partneren. To legitime hierarkier, to autoriteter. Navngiv dem, og lad ikke, som om ét træ repræsenterer alle relationer.

Gør grænserne synlige

Når autoriteten er delt, vil jeg have grænsen synlig: feltnavne, metadata på posten, identifikatorer fra kildesystemet, tilladelser, integrationernes opførsel, dokumentation. Det, jeg ikke vil have, er en udvikler, der skal læse fem integrationer for at opdage, at »disse værdier i Parent Account kommer fra SAP, undtagen for emner, undtagen i Europa«. Det er ikke en autoritetsmodel, der kan vedligeholdes. Hvis hierarkiet har delt mastering, så dokumentér opdelingen. Hvis autoriteten skifter ved konvertering, så dokumentér skiftet. Hvis Salesforce kan anmode om en ændring, men ikke foretage den, så gør det tydeligt i oplevelsen.

I Salesforce starter det med ét felt. Der skal være et felt, der tydeligt siger, at dette er masterdata: ERP’ets nøgle eller et flag for »er masterdata«. Styr redigerbarheden ud fra det felt, ikke ud fra en posttype; med Dynamic Forms har du ikke længere brug for en posttype for at vise ERP’ets felter som skrivebeskyttede (kapitel 5, En posttype til hvert flow). Du kan godt tillade, at poster oprettes uden for masteren, men hold øje med redigeringerne.

Ud over eksamen: hvad AI ændrer. En kunde siger til en agent: »Ændr vores fakturaadresse til 125 Main Street.« Feltet er lige dér i Salesforce. Skal agenten opdatere det? Ikke hvis ERP’et ejer det. En agent har brug for skriveautoritet, ikke kun adgang til feltet: Dens handling skal indbygge den godkendte vej, nemlig at indsende en ændringsanmodning og sige »Jeg har sendt ændringen til behandling«, ikke fejlagtigt melde »Jeg har opdateret din fakturaadresse«.

Hvad en arkitekt beslutter her

• Om en redigering i Salesforce ændrer autoritative data eller anmoder om en ændring fra det system, der ejer dem.
• Hvordan tovejsflows skelner oprindelige ændringer fra ekkoer og håndterer afvisning, kollisioner, forsinkelse og fejl.
• Hvem der ejer hvert hierarki, om nødvendigt gren for gren.
• For én kunde i flere ERP’er: et hierarki, sideordnede konti eller én konto med et barn pr. ERP, afgjort af, hvor godt klienten holder sine ERP’er synkroniseret.
• Om konkurrerende hierarkier i virkeligheden er forskellige legitime relationer: juridisk, fakturering, salg, service.
• Hvordan autoritetsgrænser og godkendte skriveveje gøres synlige for brugere, integrationer, udviklere og agenter.

Delt autoritet er ikke problemet. Tvetydig autoritet er. Flere ERP’er kan være master for forskellige grene, Salesforce kan være master for nogle attributter og anmode om ændringer af andre, og flere hierarkier kan beskrive én virksomhed. Alt det virker, så længe du for hver vigtig attribut og relation kan sige, hvem der ejer den, hvem der må ændre den, hvor den autoritative ændring foretages, og hvad der sker, når systemerne er uenige. Hvis du ikke kan det, hjælper endnu en tovejspil på diagrammet ikke.

Læs mere

• Salesforce Help, Considerations for Using Account Hierarchy (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).