Å koble er ikke å mastre

🌐 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)

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

Kapittel 6 av Data Architect, Del 1: Å bli dataarkitekt. Forrige: Datakvalitet og styring.

«Vi trenger én sannhetskilde.» Det er en av de mest gjentatte frasene i arkitektur, og en av de minst gjennomtenkte. For hva da? Ta én konto. ERP-systemet kan eie det juridiske navnet, fakturaadressen og kredittgrensen; Salesforce kundeansvarlig og supportnivå; en samtykkeplattform markedsføringspreferansene. Tre autoriteter på én post, og det er helt normalt. Så når noen sier «Salesforce er vår eneste sannhetskilde for kunden», er mitt neste spørsmål alltid: hvilken sannhet?

Dette kapitlet handler om å svare på det spørsmålet med vilje. Autoritet tildeles attributt for attributt. Å koble poster sammen er ikke å mastre dem. Og Salesforce gir deg ulike verktøy for ulike jobber: duplikathåndtering og sammenslåing i én org; identitetsoppløsning (identity resolution) i Data 360 for én samlet visning på tvers av kilder; en egen MDM-plattform når verdier må avgjøres én gang og sendes tilbake overalt. Det slutter med Kontrollpunkt 1, der del 1 kommer sammen på Steve Trucking.

Bildet er generert med KI.

Standpunktene i dette kapitlet

• Sannhet per attributt. Spør hvor hver bit av dataene opprettes, redigeres og refereres, og hvor raskt de endres. Vis ekstern autoritet i skjemaet med et systemprefiks, som sap_ eller erp_.
• Prospekter er annerledes. De bor i Salesforce før ERP-systemet kjenner dem; ERP-autoriteten gjelder etter konverteringen.
• Register er normen på Salesforce-prosjekter, deretter konsolidering og sameksistens; ren sentralisert MDM er sjelden.
• Slå sammen bare når det finnes en klar vinner. Behold duplikater fra eksterne innlastinger når du kan få bruk for å spore tilbake; sammenslåing ødelegger den historikken. Og bestem hva som skjer med barna: flytt dem, ikke last dem inn, eller behold dem på en inaktiv post.
• En samlet profil er et kart; en golden record er en beslutning. Dette kan være forvirrende: identitetsoppløsning lager et samlet individ, men ikke en golden record.
• Hvor strengt du matcher, er en risikobeslutning. Der sammenblanding er kostbart, matcher du for lite med vilje.
• Tre verktøy for tre jobber: sammenslåing, identitetsoppløsning, MDM.
• Hierarkier har delt mastring. Bestem autoriteten gren for gren.
• «Det vanskeligste er toveisflytene.» En toveisintegrasjon gir ikke to mastere. Bestem hvilke felt som reiser sammen som én transaksjon før den første kollisjonen.
• Gjør masterdata synlige. Et felt som sier at dette er masterdata (ERP-nøkkelen eller et flagg), styrer hva som kan redigeres, ikke en posttype.
• Vi kontrollerer ikke ERP-systemene. Vi kontrollerer hvordan vi representerer dem i Salesforce: én kunde i to ERP-systemer er et hierarki, likestilte poster, eller én konto med et barn per ERP, avhengig av hvor godt klienten holder ERP-systemene sine synkronisert.

Tre verktøy for tre jobber

Jobben	Verktøyet	Hva det gjør med kildene
Duplikater i én org, med en klar vinner	Duplikathåndtering og sammenslåing	Slår sammen opptil tre poster; de andre havner i papirkurven (Recycle Bin)
Én identitet og én samlet visning på tvers av kilder	Identitetsoppløsning i Data 360	Kobler dem; endrer ingen av dem (et register)
Én styrt verdi, sendt tilbake til hvert system	En egen MDM-plattform	Avgjør verdien og distribuerer den (sameksistens eller sentralisert)

Veien gjennom kapitlet

Seks moduler og en oppgave, og hver står på egne ben.

1. Én sannhetskilde per attributt. Autoritetskartet, den hybride golden record og tillitssignaler.
2. De fire måtene å håndtere masterdata på. Register, konsolidering, sameksistens og sentralisert, og hvorfor en felles modell ikke er en felles sannhet.
3. Matching, sammenslåing og overlevelsesregler. Hva en falsk match koster, hva en sammenslåing i Salesforce egentlig gjør (og hva som skjer med barna), og overlevelsesregler som et utsagn om tillit.
4. Et kart er ikke en beslutning. Samsvarsregler og samsvarsmetoder, avstemmingsregler, og hvorfor en samlet profil ikke er en golden record.
5. Når autoriteten er delt. Forespørsler kontra oppdateringer, løkker og kollisjoner, hierarkier med delt mastring, og én kunde i to ERP-systemer.
6. Oppgaven til kontrollpunkt 1, deretter Kontrollpunkt 1: Steve Trucking, slik ville jeg designet det. Prøv oppgaven først: tegn og forsvar designet for del 1, sammenlign det så med mitt, og se hva som endrer seg fra landskapet i kapittel 4.

Når du er ferdig, test deg selv med studieguiden for kapitlet: en sjekkliste til eksamen, vanene utover den, ordene du bør kunne, og noen spørsmål. Den avslutter del 1; studieguiden for del 1 setter alle seks kapitlene sammen.

Hva en arkitekt bestemmer her

• Hvilket system som er autoritativt for hvert viktig attributt, og hvordan det synes i modellen.
• Hvilken mastringsstil som passer hvert datadomene, og hvor mye autoritet mastringslaget får.
• Når du slår sammen, og når du kobler, og hvem som eier hver overlevelsesregel.
• Hvor streng matchingen skal være, basert på hva en falsk match koster.
• Hvor toveisdata og delte hierarkier trenger tydelige grenser.

Utover eksamen: agenter trenger én identitet å handle på, og det øker innsatsen begge veier. For mye matching blir en personvernhendelse, og en agent som «oppdaterer kunden», må skrive til hvert attributts system of record, ikke til den samlede profilen. Hver modul slutter med hva KI endrer.

Les mer

• Salesforce Architects, Data 360 Architecture (opens in a new tab), på engelsk, kontrollert 2026-10-14.
• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) og Identity Resolution Reconciliation Rules (opens in a new tab), på engelsk, kontrollert 2026-10-14.

Neste: Del 2 begynner med Design for skala (coming soon).