Hierarkier och tvåvägsdata

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 5 av 6 i kapitlet Masterdata och identitet, kapitel 6 i kursen Data Architect. Varje modul står på egna ben. Föregående: En karta är inget beslut · Nästa: Kontrollpunkt 1: Steve Trucking

Frågan den här modulen besvarar: Hur hanterar du data som mer än ett system förvaltar?

Den enkla arkitekturen: ERP:t äger kunden, Salesforce får en kopia, klart. Verkliga företag är inte så prydliga. ERP:t äger den juridiska kunden och Salesforce säljrelationen; en division finns i SAP, en uppköpt i ett annat ERP; prospekt finns bara i Salesforce. Sedan vill någon att Salesforce-användare ska uppdatera ett fält som ERP:t styr, och pilarna börjar peka åt båda hållen. Som jag säger när jag undervisar om det här: ”Det svåraste är de dubbelriktade flödena.” Inte för att det är tekniskt svårt att skicka data åt båda hållen, utan för att du, när båda systemen deltar i förändringen, måste vara extremt exakt om auktoriteten.

Tvåvägsdata betyder inte två master

ERP:t äger faktureringsadressen, som kopieras till Salesforce. En säljare får veta av kunden att den har ändrats, och verksamheten vill att säljaren ska uppdatera den utan att lämna Salesforce. Rimligt. Nu flödar data ERP → Salesforce och Salesforce → ERP. Är Salesforce nu delägare av faktureringsadressen? Nej. Integrationens riktning avgör inte auktoriteten. Säljaren ändrar inte kopian i Salesforce. Arkitektoniskt ber säljaren om att få ändra det auktoritativa värdet. Du ändrar inte ERP:ts fält; du ber om att få ändra det. Salesforce är gränssnittet; ERP:t är fortfarande master.

Det ändrar designen. Om Salesforce ägde fältet: spara och klart. Om ERP:t äger det betyder ”spara” att Salesforce skickar den föreslagna adressen, ERP:t validerar och accepterar den, uppdaterar sin master och skickar tillbaka det auktoritativa värdet. Först då har det styrda värdet ändrats: begäran → validering → acceptans → publicering, inte ”uppdatera båda systemen och hoppas att de håller sig synkade”.

Click to enlarge

En dubbelriktad integration skapar inte dubbelriktad auktoritet.

När mastern säger nej

ERP:t avvisar ändringen: kunden är inaktiv, adressen bryter mot en regel i ERP:t, användaren får inte ändra juridiska adresser, ERP:t är nere, eller någon annan har ändrat kunden under tiden. Om Salesforce redan visade den nya adressen har vi nu två sanningar, och modul 1 har redan sagt oss vilken som vinner: ERP:ts. Så arkitekturen behöver ett tillstånd för begärd, ännu inte accepterad: ett separat föreslaget värde, en flagga för ”väntande ändring”, eller att vänta på bekräftelse innan värdet visas. Mekanismen beror på användningsfallet. Regeln gör det inte: låt aldrig en avvisad begäran bli en konkurrerande sanning.

Loopar och kollisioner

Här är en klassiker. ERP:t uppdaterar Salesforce; integrationen i Salesforce ser en ändring och skickar den till ERP:t; ERP:t ser en uppdatering och skickar tillbaka den. Du har byggt en väldigt dyr loop. En bra tvåvägsdesign vet var en ändring startade, om mastern har accepterat den, och om det här är en ny affärsändring eller bara ekot av en som redan har behandlats: källidentifierare, tidsstämplar, integrationsmetadata, idempotent bearbetning. Kapitlet om integration går på djupet. Masterdataprincipen är enkel: vet om du startar en ändring eller speglar en.

Sedan kollisioner. Du mötte en i kapitel 5: en säljare ber om Steve’s Plumbing LLC medan någon i ERP:t skriver Steve’s Plumbing L.L.C. (Skydda den styrda posten). Här är en till. Salesforce föreslår 125 Main Street; nästan i samma ögonblick ändrar en användare i ERP:t den till 130. Vilken vinner? Det finns inget universellt tekniskt svar. Kanske vinner ERP:t alltid eftersom det äger fältet; kanske går begäran från Salesforce till en granskningskö; kanske vinner den senast accepterade ändringen; kanske avvisar ERP:t varje uppdatering vars startvärde har ändrats. Det är samtidighet, men under ytan är det ett auktoritetsbeslut, och inget integrationsmönster kan rädda dig om ingen har bestämt vem som får göra den auktoritativa ändringen.

Och ett enda fält är det enkla fallet. En adress är en gata, en ort, ett postnummer. Salesforce skickar en ny gata medan ERP:t precis har ändrat orten. Släpper du igenom gatan på egen hand? Eller behandlar du adressen som en transaktion, så att alla fälten går tillsammans eller inget av dem, och avvisar hela ändringen? Bestäm vilka fält som färdas som en grupp före den första kollisionen, inte efter.

När jag ser en tvåvägsintegration frågar jag alltid vad händer när båda sidor ändrar samma data? Om svaret är ”det kommer nog inte att hända” är vi inte klara. Vilken vinner, avvisar vi, köar vi, jämför vi versioner, granskar vi? Ska fältet över huvud taget gå att redigera på båda ställena? Ibland tar den bästa tvåvägsdesignen bort en riktning för ett visst attribut: Salesforce får begära; bara ERP:t publicerar det accepterade värdet. Data rör sig fortfarande åt båda hållen, men bara ett system är master för fältet. Den skillnaden är allt.

Hierarkier är också masterdata

Relationer kan också vara masterdata. Ett globalt moderbolag med regionerna Nordamerika och Europa, var och en med dotterbolag per land: hierarkin i sig bär betydelse. Vem är moderbolaget? Vilket dotterbolag ligger under vilken juridisk person? Vilka konton rullas upp till den globala kunden? Det styr rapportering, territorier, prissättning, avtal, kreditexponering, service, dataåtkomst och analys. En hierarki kan spela lika stor roll som posterna i den, och den behöver samma styrning. (Provet nämner hierarkihantering; det är lätt att glömma.)

I Salesforce byggs kontohierarkier med fältet Parent Account (överordnat konto). Hierarkivyn i Lightning visar upp till 2 000 konton, och bara dem som användaren får se; personkonton stöds inte i hierarkin; och Account Site skiljer på ett företags platser (Considerations for Using Account Hierarchy (opens in a new tab)). Men fältet Parent Account besvarar inte arkitekturfrågan: vem äger hierarkin?

Provkunskap. Känn till grunderna för kontohierarkin: den byggs med Parent Account; vyn i Lightning visar upp till 2 000 konton, bara dem som användaren kan se; personkonton stöds inte; och Account Site skiljer på ett företags platser.

En hierarki, flera master

Min erfarenhet är att hierarkier har delad masterdata. Nordamerikanska enheter kommer från SAP, europeiska från ett annat ERP, nya prospekt byggs i Salesforce, och ett uppköpt dotterbolag har inte migrerats än. Vem äger hierarkin? Det beror på grenen. Varje ERP styr sin gren; Salesforce styr prospektens relationer tills de konverteras. Det är en legitim arkitektur, så länge alla vet var gränserna går. Bestäm per gren.

Click to enlarge

Auktoriteten över en hierarki kan tilldelas gren för gren.

Så låt inte fältet Parent Account dölja auktoriteten. En användare byter överordnat konto för ett dotterbolag i Salesforce. Tekniskt trivialt. Arkitektoniskt: ändrade användaren just företagets juridiska struktur? Om ERP:t är master för den grenen, förmodligen inte, så Salesforce bör blockera det, eller göra om det till en ändringsbegäran. Eller så har Salesforce legitimt en kommersiell hierarki medan ERP:t har den juridiska. Då borde de kanske inte alls vara samma relation.

Ett företag kan ha flera giltiga hierarkier: juridisk, fakturering, försäljning, service, geografisk. Det globala moderbolaget skriver under avtalet, regionerna får service på egen hand, faktureringen går genom en gemensam ekonomienhet, försäljningen styrs per region. Vilken är den sanna hierarkin? Alla; de besvarar olika frågor. Misstaget är att anta att det måste finnas en. Det ska finnas tydlig auktoritet för varje typ av relation: attributprincipen från modul 1, tillämpad på relationer.

Och inte varje förälder–barn-relation är masterdata. Att samla dagens leveranser på en rutt är en relation, men den är transaktionell, en operativ händelse. En kundhierarki beskriver en varaktig affärsrelation. Båda ser ut som förälder–barn i en modell; de delar inte livscykel. Fråga vad relationen betyder och hur länge den betydelsen varar.

En kund, två ERP:er

När jag undervisar om det här frågar jag rummet: vem har jobbat med en klient som har ett Salesforce och mer än ett ERP? Händer åker upp varje gång. Fråga varför, och det visar sig att ERP:erna är uppdelade regionalt (ett för Nordamerika, ett för Europa), funktionellt (ett rörföretag köper ett elföretag, och vart och ett behåller sitt eget ERP), eller bara historiskt: verksamheten köptes upp, och ingen har migrerat den än.

Ta Steve’s Plumbing som kund. Företaget gör affärer i Nordamerika, så det nordamerikanska ERP:t har en kundpost för det. Sedan öppnar det ett kontor i München, och det europeiska ERP:t skapar en egen kundpost, med ett eget kundnummer. Samma företag, två poster, två ID:n. Hur representerar jag det i en org i Salesforce? Jag har sett tre sätt.

En kontohierarki. Steve’s Plumbing är föräldern, med Steve’s Plumbing North America och Steve’s Plumbing Europe som barnkonton, där varje barn står för ett ERP:s post. Haken: barnen är egentligen inte Steve’s Plumbing längre. De är Steve’s Plumbing när företaget gör affärer i en region, och som vi just såg bär en hierarki betydelse.

Likställda konton. Två konton sida vid sida, vart och ett med ett fält som säger vilket ERP det hör till: en bolagskod, en region. Ingenting är dolt. Kostnaden syns i rapporteringen: för att se Steve’s Plumbing över hela världen behöver du något som säger att de här två kontona är samma företag.

Ett konto, med ett barn per ERP. Ett Steve’s Plumbing, och ett barnobjekt med en post för varje ERP som håller det ERP:ts kund-ID. Två ERP:er eller tio. Säljarna ser en kund och lägger en order; bakom kulisserna avgör flöden vilket ERP varje rad går till: elarbete till el-ERP:t, rörarbete till rör-ERP:t. Men nu måste du bestämma vilket ERP som är primärt för de gemensamma värdena, som namn och adress, och vad som händer när kunden finns i det ena ERP:t men inte i det andra.

Click to enlarge

En kund, två ERP:er: tre sätt att representera den i Salesforce.

Fråga hur de håller ERP:erna synkade

Så vilket? Först: hur mycket av ERP-strukturen ska säljarna se? Om de alltid har vetat att Nordamerika och Europa är separata verksamheter, eftersom de loggar in i det ena eller det andra ERP:t, dölj det inte för dem. För över den strukturen till Salesforce som likställda konton. Om verksamheten vill ha ett enda Steve’s Plumbing framför försäljningen tittar du på ett konto med ett barn per ERP.

Sedan frågan som verkligen avgör det, och den avgörs inte i Salesforce. Jag frågar klienten: hur håller ni de två posterna synkade mellan era ERP:er? Inte det som är lokalt för varje ERP, som saldot; det är transaktionellt. Jag menar masterdata: det juridiska namnet, adresserna. Om de har ett team som håller de två ERP:erna synkade kan vi föra samman dem som ett konto. Om de inte kan hålla dem synkade i sina egna ERP:er, hur kan de då förvänta sig att vi ska hålla dem synkade i Salesforce? Då blir det likställda konton, eller en hierarki.

Kom ihåg vad ett ERP är. Det är enorma system som tar år att införa, och de kommer med sitt eget sätt att hantera masterdata. Salesforce kommer inte att styra dem. Vi får inte styra över ERP:erna. Vi får styra hur vi representerar dem i Salesforce.

MDM i mitten

En del klienter har redan löst det här innan vi kommer dit. Ett stort företag, många år i branschen, flera ERP:er: de stötte på det här problemet långt före Salesforce och satte en dedikerad MDM-produkt i mitten för att medla mellan ERP:erna. Det är samexistens eller centraliserad MDM från modul 2. Nu kopplar Salesforce inte upp sig mot varje ERP. Det pekar på ett ställe, MDM-navet, och får en enda representation av kunden. Räkna dock inte med att möta det ofta. Det är stora implementationer i sig; på alla mina år har jag jobbat med det bara två eller tre gånger. Och även med navet kan du fortfarande behöva det där barnobjektet, så att varje order vet vilket ERP den ska till.

Click to enlarge

MDM i mitten: Salesforce pekar på ett ställe.

Steve Trucking: vems hierarki?

En detaljhandelspartner (Retail Partner) har sin egen struktur: koncernmoder, regionala divisioner, distributionscentraler, butiker. Äger Steve Trucking den hierarkin? Nej; partnern är auktoriteten för sin egen organisation. Men Steve Trucking kan behöva sin egen kommersiella bild av samma platser, för avtal, kundansvar, service och rapportering, kanske ett barnkonto för varje DC under partnern. Två legitima hierarkier, två auktoriteter. Ge dem namn, och låtsas inte att ett träd representerar varje relation.

Gör gränserna synliga

När auktoriteten är uppdelad vill jag att gränsen ska synas: fältnamn, metadata på posten, identifierare från källsystemet, behörigheter, integrationernas beteende, dokumentation. Det jag inte vill är att en utvecklare ska läsa fem integrationer för att upptäcka att ”de här Parent Account-värdena kommer från SAP, utom prospekten, utom Europa”. Det är ingen auktoritetsmodell som går att underhålla. Om hierarkin har delad masterdata, dokumentera uppdelningen. Om auktoriteten ändras vid konverteringen, dokumentera ändringen. Om Salesforce kan begära men inte göra en ändring, gör det tydligt i upplevelsen.

I Salesforce börjar det med ett fält. Det måste finnas ett fält som tydligt säger att det här är masterdata: ERP:ts nyckel, eller en flagga för ”är masterdata”. Styr vilka fält som går att redigera utifrån det fältet, inte utifrån en posttyp; med Dynamic Forms behöver du inte längre en posttyp för att visa ERP:ts fält som skrivskyddade (kapitel 5, En posttyp för varje flöde). Du kan tillåta att poster skapas utanför mastern, men håll ögonen på redigeringarna.

Bortom provet: vad AI ändrar. En kund säger till en agent: ”ändra vår faktureringsadress till 125 Main Street.” Fältet finns där i Salesforce. Ska agenten uppdatera det? Inte om ERP:t äger det. En agent behöver skrivauktoritet, inte bara åtkomst till fältet: dess handling bör koda in den godkända vägen, skicka en ändringsbegäran och säga ”jag har skickat in ändringen för behandling”, inte felaktigt rapportera ”jag har uppdaterat er faktureringsadress”.

Vad en arkitekt bestämmer här

• Om en redigering i Salesforce ändrar auktoritativa data eller begär en ändring från systemet som äger dem.
• Hur tvåvägsflöden skiljer ursprungliga ändringar från ekon, och hanterar avvisningar, kollisioner, latens och fel.
• Vem som äger varje hierarki, gren för gren om det behövs.
• För en kund som finns i flera ERP:er: en hierarki, likställda konton eller ett konto med ett barn per ERP, avgjort av hur väl klienten håller sina ERP:er synkade.
• Om konkurrerande hierarkier egentligen är olika legitima relationer: juridisk, fakturering, försäljning, service.
• Hur auktoritetsgränser och godkända skrivvägar görs synliga för användare, integrationer, utvecklare och agenter.

Delad auktoritet är inte problemet. Otydlig auktoritet är det. Flera ERP:er kan vara master för olika grenar, Salesforce kan vara master för vissa attribut och begära ändringar av andra, och flera hierarkier kan beskriva ett och samma företag. Allt det fungerar, så länge du för varje viktigt attribut och varje viktig relation kan säga vem som äger den, vem som får ändra den, var den auktoritativa ändringen görs och vad som händer när system är oense. Om du inte kan det hjälper ännu en dubbelriktad pil i diagrammet inte.

Utforska vidare

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