Hierarkier og toveisdata

🌐 Finnes også på 28 språk

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 · Dansk · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 5 av 6 i kapitlet Masterdata og identitet, kapittel 6 i kurset Data Architect. Hver modul står på egne ben. Forrige: Et kart er ikke en beslutning · Neste: Kontrollpunkt 1: Steve Trucking

Spørsmålet denne modulen besvarer: Hvordan håndterer du data som mer enn ett system vedlikeholder?

Den enkle arkitekturen: ERP-systemet eier kunden, Salesforce får en kopi, ferdig. Ekte virksomheter er ikke så ryddige. ERP-systemet eier den juridiske kunden og Salesforce salgsrelasjonen; én divisjon bor i SAP, en oppkjøpt en i et annet ERP-system; prospekter finnes bare i Salesforce. Så vil noen at Salesforce-brukerne skal oppdatere et felt som ERP-systemet kontrollerer, og pilene begynner å peke begge veier. Som jeg sier når jeg underviser i dette: «Det vanskeligste er toveisflytene.» Ikke fordi det er teknisk vanskelig å sende data begge veier, men fordi du, så snart begge systemene tar del i endringer, må være ekstremt presis om autoritet.

Toveisdata betyr ikke to mastere

ERP-systemet eier fakturaadressen, som kopieres inn i Salesforce. En selger får vite av kunden at den er endret, og virksomheten vil at selgeren skal oppdatere den uten å forlate Salesforce. Rimelig. Nå flyter data ERP → Salesforce og Salesforce → ERP. Er Salesforce nå medeier av fakturaadressen? Nei. Retningen på en integrasjon avgjør ikke autoriteten. Selgeren endrer ikke kopien i Salesforce. Arkitektonisk sett ber selgeren om å få endre den autoritative verdien. Du endrer ikke ERP-systemets felt; du ber om å få endre det. Salesforce er grensesnittet; ERP-systemet er fortsatt masteren.

Det endrer designet. Hvis Salesforce eide feltet, ville det vært lagre og ferdig. Hvis ERP-systemet eier det, betyr «lagre» at Salesforce sender den foreslåtte adressen, ERP-systemet validerer og godtar den, oppdaterer masteren sin og sender den autoritative verdien tilbake. Først da har den styrte verdien endret seg: forespørsel → validering → godkjenning → publisering, ikke «oppdater begge systemene og håp at de holder seg synkronisert».

Click to enlarge

En toveisintegrasjon skaper ikke toveis autoritet.

Når masteren sier nei

ERP-systemet avviser endringen: kunden er inaktiv, adressen bryter en regel i ERP-systemet, brukeren har ikke lov til å endre juridiske adresser, ERP-systemet er nede, eller noen andre har endret kunden i mellomtiden. Hvis Salesforce allerede viste den nye adressen, har vi nå to sannheter, og modul 1 har allerede fortalt oss hvilken som vinner: ERP-systemets. Så arkitekturen trenger en tilstand for forespurt, ikke godtatt ennå: en separat foreslått verdi, et flagg for «ventende endring», eller å vente på bekreftelse før den vises. Mekanismen avhenger av brukstilfellet. Regelen gjør det ikke: la aldri en avvist forespørsel bli en konkurrerende sannhet.

Løkker og kollisjoner

Her er en klassiker. ERP-systemet oppdaterer Salesforce; integrasjonen i Salesforce ser en endring og sender den til ERP-systemet; ERP-systemet ser en oppdatering og sender den tilbake. Du har bygd en svært dyr løkke. Godt toveisdesign vet hvor en endring startet, om masteren har godtatt den, og om dette er en ny forretningsendring eller bare ekkoet av en som allerede er behandlet: kildeidentifikatorer, tidsstempler, integrasjonsmetadata, idempotent behandling. Integrasjonskapitlet går i dybden. Masterdataprinsippet er enkelt: vit om du starter en endring eller speiler en.

Så kollisjoner. Du møtte en i kapittel 5: en selger ber om Steve’s Plumbing LLC mens noen i ERP-systemet skriver Steve’s Plumbing L.L.C. (Beskytt den styrte posten). Her er en til. Salesforce foreslår 125 Main Street; nesten i samme øyeblikk endrer en ERP-bruker den til 130. Hvem vinner? Det finnes ikke noe universelt teknisk svar. Kanskje ERP-systemet alltid vinner fordi det eier feltet; kanskje forespørselen fra Salesforce går til en gjennomgangskø; kanskje den sist godtatte endringen vinner; kanskje ERP-systemet avviser enhver oppdatering der startverdien har endret seg. Det er samtidighet, men under ligger en autoritetsbeslutning, og ingen integrasjonsmønstre kan redde deg hvis ingen har bestemt hvem som kan gjøre den autoritative endringen.

Og ett enkelt felt er det enkle tilfellet. En adresse er en gate, en by, et postnummer. Salesforce sender en ny gate mens ERP-systemet nettopp har endret byen. Slipper du gaten gjennom alene? Eller behandler du adressen som én transaksjon, så feltene går sammen eller ingen av dem gjør det, og avviser hele endringen? Bestem hvilke felt som reiser som en gruppe før den første kollisjonen, ikke etter.

Hver gang jeg ser en toveisintegrasjon, spør jeg hva skjer når begge sider endrer de samme dataene? Hvis svaret er «det skjer nok ikke», er vi ikke ferdige. Hvem vinner, avviser vi, setter vi i kø, sammenligner vi versjoner, går vi gjennom manuelt? Bør feltet i det hele tatt kunne redigeres begge steder? Noen ganger fjerner det beste toveisdesignet én retning for et gitt attributt: Salesforce kan be om endringen; bare ERP-systemet publiserer den godtatte verdien. Data beveger seg fortsatt begge veier, men bare ett system mastrer feltet. Den forskjellen er alt.

Hierarkier er også masterdata

Relasjoner kan også være masterdata. Et globalt morselskap med regionene Nord-Amerika og Europa, hver med datterselskaper per land: selve hierarkiet bærer mening. Hvem er morselskapet? Hvilket datterselskap ligger under hvilken juridisk enhet? Hvilke kontoer rulles opp til den globale kunden? Det styrer rapportering, salgsområder, priser, kontrakter, kredittrisiko, service, datatilgang og analyse. Et hierarki kan bety like mye som postene i det, og det trenger samme styring. (Eksamen nevner hierarkihåndtering; det er lett å glemme.)

I Salesforce bygges kontohierarkier med feltet Parent Account (overordnet konto). Hierarkivisningen i Lightning viser opptil 2 000 kontoer, og bare dem brukeren har lov til å se; personkontoer støttes ikke i hierarkiet; og Account Site skiller mellom et selskaps lokasjoner (Considerations for Using Account Hierarchy (opens in a new tab)). Men feltet Parent Account svarer ikke på arkitekturspørsmålet: hvem eier hierarkiet?

Eksamenskunnskap. Kjenn det grunnleggende om kontohierarkiet: det bygges med Parent Account; visningen i Lightning viser opptil 2 000 kontoer, bare dem brukeren kan se; personkontoer støttes ikke; og Account Site skiller mellom et selskaps lokasjoner.

Ett hierarki, flere mastere

Etter min erfaring har hierarkier delt mastring. Nordamerikanske enheter kommer fra SAP, europeiske fra et annet ERP-system, nye prospekter bygges i Salesforce, og et oppkjøpt datterselskap er ikke migrert ennå. Hvem eier hierarkiet? Det avhenger av grenen. Hvert ERP-system kontrollerer sin gren; Salesforce kontrollerer prospektrelasjonene til de konverteres. Det er en legitim arkitektur, så lenge alle vet hvor grensene går. Bestem per gren.

Click to enlarge

Autoriteten over et hierarki kan tildeles gren for gren.

Så ikke la feltet Parent Account skjule autoriteten. En bruker flytter et datterselskap til en ny forelder i Salesforce. Teknisk trivielt. Arkitektonisk: endret brukeren nettopp selskapets juridiske struktur? Hvis ERP-systemet mastrer den grenen, sannsynligvis ikke, så Salesforce bør blokkere det, eller gjøre det om til en endringsforespørsel. Eller kanskje Salesforce helt legitimt holder et kommersielt hierarki mens ERP-systemet holder det juridiske. Da bør de kanskje ikke være samme relasjon i det hele tatt.

Et selskap kan ha flere gyldige hierarkier: juridisk, fakturering, salg, service, geografisk. Det globale morselskapet signerer kontrakten, regionene får service hver for seg, faktureringen går gjennom en felles økonomienhet, salg styrer per region. Hvilket er det sanne hierarkiet? Alle sammen; de svarer på forskjellige spørsmål. Feilen er å anta at det må finnes ett. Det bør finnes tydelig autoritet for hver type relasjon: attributtprinsippet fra modul 1, brukt på relasjoner.

Og ikke hver forelder–barn-relasjon er masterdata. Å samle dagens leveringer på én rute er en relasjon, men den er transaksjonell, en operativ hendelse. Et kundehierarki beskriver en varig forretningsrelasjon. Begge ser ut som forelder–barn i en modell; de deler ikke livssyklus. Spør hva relasjonen betyr og hvor lenge den betydningen varer.

Én kunde, to ERP-systemer

Når jeg underviser i dette, spør jeg rommet: hvem har jobbet med en klient som har én Salesforce og mer enn ett ERP-system? Hendene går i været hver gang. Spør hvorfor, og det viser seg at ERP-systemene er delt regionalt (ett for Nord-Amerika, ett for Europa), funksjonelt (et rørleggerfirma kjøper et elektrofirma, og hvert beholder sitt eget ERP-system), eller bare historisk: virksomheten ble kjøpt opp, og ingen har migrert den ennå.

Ta Steve’s Plumbing som kunden. Selskapet driver forretning i Nord-Amerika, så det nordamerikanske ERP-systemet har en kundepost for det. Så åpner det et kontor i München, og det europeiske ERP-systemet oppretter en egen kundepost, med sitt eget kundenummer. Samme selskap, to poster, to ID-er. Hvordan representerer jeg det i én Salesforce-org? Jeg har sett tre måter.

Et kontohierarki. Steve’s Plumbing er forelderen, med Steve’s Plumbing North America og Steve’s Plumbing Europe som barnekontoer, der hvert barn står for én ERP-post. Haken: barna er egentlig ikke Steve’s Plumbing lenger. De er Steve’s Plumbing som driver forretning i en region, og som vi nettopp så, bærer et hierarki mening.

Likestilte kontoer. To kontoer side om side, hver med et felt som sier hvilket ERP-system den hører til: en selskapskode, en region. Ingenting er skjult. Kostnaden viser seg i rapporteringen: for å se Steve’s Plumbing over hele verden trenger du noe som sier at disse to kontoene er samme selskap.

Én konto, med et barn per ERP-system. Én Steve’s Plumbing, og et barneobjekt med en post for hvert ERP-system som holder det systemets kunde-ID. To ERP-systemer eller ti. Selgerne ser én kunde og legger inn én ordre; i bakgrunnen avgjør flyter hvilket ERP-system hver linje går til: elektroarbeid til elektro-ERP-et, rørleggerarbeid til rørlegger-ERP-et. Men nå må du bestemme hvilket ERP-system som er primært for de delte verdiene, som navn og adresse, og hva som skjer når kunden finnes i det ene ERP-systemet og ikke i det andre.

Click to enlarge

Én kunde, to ERP-systemer: tre måter å representere det i Salesforce.

Spør hvordan de holder ERP-systemene synkronisert

Så hvilken? Først: hvor mye av ERP-strukturen skal selgerne se? Hvis de alltid har visst at Nord-Amerika og Europa er separate virksomheter, fordi de logger inn i det ene eller det andre ERP-systemet, så ikke skjul det for dem. Ta med den strukturen inn i Salesforce som likestilte kontoer. Hvis virksomheten vil ha én Steve’s Plumbing foran salg, ser du på én konto med et barn per ERP-system.

Så spørsmålet som virkelig avgjør det, og det avgjøres ikke i Salesforce. Jeg spør klienten: hvordan holder dere de to postene synkronisert mellom ERP-systemene deres? Ikke det som er lokalt for hvert ERP-system, som saldoen; det er transaksjonelt. Jeg mener masterdataene: det juridiske navnet, adressene. Hvis de har et team som holder de to ERP-systemene synkronisert, kan vi samle dem som én konto. Hvis de ikke klarer å holde dem synkronisert i sine egne ERP-systemer, hvordan kan de forvente at vi skal holde dem synkronisert i Salesforce? Da blir det likestilte kontoer, eller et hierarki.

Husk hva et ERP-system er. Dette er enorme systemer som tar år å få på plass, og de kommer med sin egen måte å håndtere masterdata på. Salesforce kommer ikke til å styre dem. Vi får ikke kontrollere ERP-systemene. Vi får kontrollere hvordan vi representerer dem i Salesforce.

MDM i midten

Noen klienter har allerede løst dette før vi kommer. Et stort selskap, mange år i drift, flere ERP-systemer: de møtte dette problemet lenge før Salesforce og satte et eget MDM-produkt i midten for å megle mellom ERP-systemene. Det er sameksistens- eller sentralisert MDM fra modul 2. Nå kobler ikke Salesforce seg til hvert ERP-system. Det peker til ett sted, MDM-knutepunktet, og får én representasjon av kunden. Men ikke forvent å møte et slikt ofte. Dette er store implementeringer i seg selv; i alle mine år har jeg jobbet med et bare to eller tre ganger. Og selv med knutepunktet kan du fortsatt trenge det barneobjektet, så hver ordre vet hvilket ERP-system den skal til.

Click to enlarge

MDM i midten: Salesforce peker til ett sted.

Steve Trucking: hvem sitt hierarki?

En detaljhandelspartner (Retail Partner) har sin egen struktur: konsernmor, regionale divisjoner, distribusjonssentre, butikker. Eier Steve Trucking det hierarkiet? Nei; partneren er autoriteten for sin egen organisasjon. Men Steve Trucking kan trenge sin egen kommersielle visning av de samme lokasjonene, for kontrakter, kundeoppfølging, service og rapportering, kanskje en barnekonto for hvert DC under partneren. To legitime hierarkier, to autoriteter. Gi dem navn, og ikke lat som om ett tre representerer hver relasjon.

Gjør grensene synlige

Når autoriteten er delt, vil jeg at grensen skal være synlig: feltnavn, metadata på posten, identifikatorer fra kildesystemet, tillatelser, integrasjonsatferd, dokumentasjon. Det jeg ikke vil, er at en utvikler må lese fem integrasjoner for å oppdage at «disse Parent Account-verdiene kommer fra SAP, bortsett fra prospekter, bortsett fra Europa». Det er ikke en autoritetsmodell som lar seg vedlikeholde. Hvis hierarkiet har delt mastring, dokumenter delingen. Hvis autoriteten endres ved konvertering, dokumenter endringen. Hvis Salesforce kan be om en endring, men ikke gjøre den, gjør det tydelig i brukeropplevelsen.

I Salesforce starter det med ett felt. Det må finnes et felt som tydelig sier at dette er masterdata: ERP-systemets nøkkel, eller et flagg for «er masterdata». Styr hva som kan redigeres ut fra det feltet, ikke ut fra en posttype; med Dynamic Forms trenger du ikke lenger en posttype for å vise ERP-feltene skrivebeskyttet (kapittel 5, En posttype for hver flyt). Du kan tillate at poster opprettes utenfor masteren, men følg med på redigeringene.

Utover eksamen: hva KI endrer. En kunde sier til en agent: «endre fakturaadressen vår til 125 Main Street.» Feltet ligger der i Salesforce. Skal agenten oppdatere det? Ikke hvis ERP-systemet eier det. En agent trenger skriveautoritet, ikke bare tilgang til feltet: handlingen dens bør bygge inn den godkjente veien, sende inn en endringsforespørsel og si «jeg har sendt inn endringen til behandling», ikke feilaktig melde «jeg har oppdatert fakturaadressen din».

Hva en arkitekt bestemmer her

• Om en redigering i Salesforce endrer autoritative data eller ber om en endring fra systemet som eier dem.
• Hvordan toveisflyter skiller endringer som starter et sted fra ekkoer, og håndterer avvisning, kollisjoner, forsinkelse og feil.
• Hvem som eier hvert hierarki, gren for gren om nødvendig.
• For én kunde i flere ERP-systemer: et hierarki, likestilte kontoer, eller én konto med et barn per ERP-system, avhengig av hvor godt klienten holder ERP-systemene sine synkronisert.
• Om konkurrerende hierarkier egentlig er forskjellige legitime relasjoner: juridisk, fakturering, salg, service.
• Hvordan autoritetsgrenser og godkjente skriveveier gjøres synlige for brukere, integrasjoner, utviklere og agenter.

Delt autoritet er ikke problemet. Uklar autoritet er det. Flere ERP-systemer kan mastre forskjellige grener, Salesforce kan mastre noen attributter og be om endringer i andre, og flere hierarkier kan beskrive én virksomhet. Alt det fungerer, så lenge du for hvert viktig attributt og hver viktig relasjon kan si hvem som eier det, hvem som kan endre det, hvor den autoritative endringen gjøres, og hva som skjer når systemene er uenige. Hvis du ikke kan det, fikser ikke enda en toveispil på diagrammet det.

Les mer

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