Hold data konsistente

🌐 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 9 av 10 i kapitlet Dataarkitektur i Salesforce, kapittel 3 i kurset Data Architect. Hver modul står på egne ben. Forrige: Eierskap og livssyklus · Neste: Design den fysiske modellen i Salesforce

Spørsmålet denne modulen besvarer: Hvordan holder jeg data konsistente, og hva koster hvert lag?

Alle vil ha rene data. Jeg har aldri gått inn i et kravmøte der noen sa: «Det vi egentlig vil ha, er inkonsistente data.» Uenigheten kommer senere: hvor håndhever vi reglene? På skjermen? Et obligatorisk felt? En plukkliste, en valideringsregel, en duplikatregel, en flow, Apex? Alle hjelper. De er ikke utskiftbare, og hvert lag har en kostnad.

Hovedregelen min er å skyve regelen så langt ned som du med rimelighet kan. Kan en verdi bare være én av fem ting, ikke la folk skrive hva som helst og rydde opp senere med automatisering. Må to poster aldri dele en identifikator, ikke stol på at noen oppdager det i en rapport. Må en regel holde enten posten kommer fra en skjerm, et API, en integrasjon, en datainnlasting eller en agent, ikke håndhev den bare i brukergrensesnittet. Jo nærmere dataene regelen sitter, jo vanskeligere er den å komme rundt. Jeg kaller det konsistensstigen.

Trinn én: felttypen og vokabularet

Den første konsistensregelen er den fra modul 6: velg riktig type. En dato er en Date, et tidspunkt er en Date/Time, penger er Currency. Det er konsistens før noen skriver en regel.

Gjør en leverings status til et tekstfelt, og du får Delivered, delivered, DELIVERED, Complete, Done og Dropped off, og noen må finne ut om de seks betyr det samme. Eller definer vokabularet én gang: Delivered, én verdi, én mening. Gjør det til en begrenset plukkliste, så den avviser alt som ikke står på listen, også gjennom API-et, og et globalt verdisett når flere felt deler listen (modul 6 har detaljene).

Men ikke bruk en plukkliste bare for å hindre folk i å skrive. Er det virkelig en verdi, eller en annen entitet? Ni distribusjonssentre med hvert sitt navn kan se ut som en plukkliste; ni med adresser, ledere, kapasitet og lastebiler er poster. Regelen skal forsterke modellen, ikke kompensere for en dårlig en. Og er det virkelig et kontrollert vokabular, kontroller det på feltet. Ikke tillat kaos og bygg så en flow for å gjøre AZ, Arizona, Ariz og Phoenix area om til verdien du ville ha i utgangspunktet.

Trinn to: Required og Unique

Required og Unique er fristende fordi de er enkle: kryss av i boksen, problemet løst. Noen ganger. Har hver lastebil et flåtenummer fra den dagen den opprettes, og ingen to lastebiler deler ett, uttrykker begge boksene ekte forretningsregler. Det er sterk konsistens.

Men når plattformen først håndhever en regel, bryr den seg ikke om at prosessen din har et unntak tirsdag ettermiddag. Jeg har brukt dette eksemplet på kurs i årevis. Et objekt har eksistert en stund, med mange poster. Noen legger til et felt og krysser av for Required. De tester å opprette en post: fungerer utmerket. Så lørdag kveld, utrulling, testene kjører, og en gammel testklasse oppretter objektet uten det nye feltet. Bom. Eller noen redigerer en gammel post fra før feltet fantes. Eller integrasjonen sender den samme payloaden den har sendt i fem år. Bom. «Men vi endret ikke det feltet.» Plattformen bryr seg ikke: du endret kontrakten for hva en gyldig post er. En ny regel påvirker ikke bare nye data; den endrer hva du kan gjøre med de gamle dataene.

Trinn tre: valideringsregler

Valideringsregler lar oss si mye rikere ting. Er statusen Delivered, må det faktiske leveringstidspunktet være fylt ut. Er stoppet en installasjon, må sjekklisten være fullført før stoppet kan lukkes. De kjører når posten lagres, så de beskytter posten enten den ble lagret fra en side, API-et, en datainnlasting, en integrasjon eller en agent. Det er poenget. Må regelen beskytte posten, legg den der hver skriving møter den.

De har også tenner. Det er både styrken og kostnaden deres.

Problemet med gamle poster

Det er her det blir stygt. Du har en million poster, og i dag legger du til en regel: leveringstidspunktet kan ikke være før rutens avgang. Fornuftig. Men tjue tusen gamle poster bryter den, takket være en migrering for sju år siden. En bruker åpner en av dem og endrer telefonnummeret. Lagre. Regelen slår til. «Jeg endret et telefonnummer. Hvorfor forteller du meg om et leveringstidspunkt fra 2019?» Rimelig spørsmål.

Så en valideringsregel skal ikke bare si hva som må være sant. Den skal si når det skal håndheves. Funksjoner som ISNEW() og ISCHANGED() lar deg avgrense en regel til nye poster, eller til lagringer der de relevante feltene faktisk endres (Validation Rule Considerations (opens in a new tab)).

Men en post endres ikke bare når en person redigerer den, og mange av grunnene har du ikke kontroll over. Integrasjonen oppdaterer statusen i løpet av natta. En flow stempler en dato. En leder tildeler et område på nytt, og eieren endres på ti tusen poster. Noen redigerer en leveringslinje, sammendragsfeltet på leveringen beregnes på nytt, og det lagrer leveringen, så leveringens valideringsregel slår til for en bruker som aldri rørte den (Roll-Up Summary Field (opens in a new tab) advarer om at valideringsfeil kan vises på detaljen eller masteren). Hver av de lagringene møter den nye regelen din. Så for hver ny regel, spør: skal denne regelen gjelde for den lagringen?

Dette er valgene, og du vever dem inn i regelen:

• Alltid, ved hver lagring. Riktig når regelen virkelig handler om posten og de gamle dataene består. Men vit hva «hver lagring» betyr: en batchjobb som bare endrer eieren, eller enhver liten endring i et hvilket som helst felt på posten, må også bestå den.
• Bare for nye poster, med ISNEW(). Regelen sjekker posten én gang, når den opprettes, og aldri igjen. Fortiden blir som den var, men det gjør også fremtiden: en senere endring kan få en ny post til å bryte regelen, og ingen stopper det. Betyr det noe, kombiner den med den neste.
• Bare når feltene den handler om, endres, med ISCHANGED(). Å redigere telefonnummeret vekker ikke regelen om leveringstidspunkt.
• Ikke for visse skrivere. En egendefinert tillatelse (custom permission), sjekket i formelen som $Permission, lar integrasjonsbrukeren eller en datamigrering slippe gjennom, mens folk fortsatt møter regelen (How to Reference a Custom Permission in a Validation Rule (opens in a new tab)). Gi den med vilje og til få.
• Fra en dato og fremover, ved å sammenligne CreatedDate med dagen regelen ble satt i drift, når «ny» betyr «siden vi begynte å håndheve dette». I motsetning til ISNEW() fortsetter den å sjekke de postene ved hver senere lagring, så den samme advarselen gjelder: en liten endring, som en eieroppdatering i batch, kan feile på en post som har glidd ut.

Legger du til en regel på poster du allerede har? Tenk gjennom konsekvensene før du slår den på. Hver eksisterende post må nå bestå den ved neste lagring, og den lagringen kan komme fra et sted du ikke ventet: en nattlig integrasjon, et eierbytte i batch, et sammendragsfelt, en masseoppdatering fra en listevisning. Hvilke av dem kommer til å treffe den, og hva skjer med den jobben når én post feiler? Avsnittet Før du slår den på har rekkefølgen jeg bruker.

Ikke skriv om historien for å gjøre regelen fornøyd

Hva med de tjue tusen gamle postene? Er dataene feil og du vet de riktige verdiene, rett dem. Men jeg har sett en annen type «fiks»: ingen vet den historiske sannheten, de trenger bare at postene består, så de oppdaterer dem med verdier som tilfredsstiller dagens regel. Det liker jeg ikke. Å oppdatere gamle poster så de oppfyller regelen, endrer LastModifiedDate og ødelegger viktig historisk informasjon, og å finne på verdier betyr å late som om vi vet noe om fortiden som vi ikke vet. Gi regelen et unntak for poster som er eldre enn den, i stedet for å skrive om historien. Det kan være stygt, men det er ærlig.

Validering i brukergrensesnittet er ikke datavalidering

Gjør et felt obligatorisk i et sideoppsett, så kan ikke brukerne lagre uten det. Så setter den nattlige integrasjonen inn 50 000 poster. Brukte den siden din? Nei. Det gjorde heller ikke bulkinnlastingen, API-klienten eller agenten. Et krav i brukergrensesnittet beskytter den skjermen, ikke dataene. Feltvalidering i dynamiske skjemaer (dynamic forms) kan unngås på samme måte. Så spør: hvor kan disse dataene komme inn? Lightning, portalen, mobil, integrasjonen, API-et, en bulkinnlasting, Flow, Apex, en agent. Jo flere dører det finnes, jo mindre stoler jeg på en regel som bare vokter én av dem.

Trinn fire: duplikatregler

Nå går vi fra konsistens inne i en post til konsistens på tvers av poster. Acme Corporation, ACME Corp, Acme Inc.: fire kunder eller én? Ingen feltregel kan svare på det. Samsvarsregler (matching rules) definerer hvordan poster sammenlignes; duplikatregler bestemmer hva som skjer når en sannsynlig duplikat blir funnet: tillat med en advarsel, blokker, eller rapporter. Du kan ha opptil fem aktive duplikatregler per objekt og opptil tre samsvarsregler i hver, og samsvarsnøkler (match keys) snevrer inn hver sammenligning til de 100 mest sannsynlige duplikatene (Things to Know About Duplicate Rules (opens in a new tab)).

Kostnaden deres er friksjon. Sier hver konto en selger oppretter Possible duplicate found (mulig duplikat funnet), er det noen ganger akkurat det du vil, og noen ganger lærer folk å klikke seg forbi uten å lese. Legitime poster kan ligne hverandre, og en integrasjon kan trenge annen oppførsel enn en person. Og advarselen er Salesforces egen: varselet og listen over mulige duplikater passer kanskje ikke inn i en egendefinert skjerm du har bygd, og når lagringen er headless (uten grensesnitt), en integrasjon, en datainnlasting, en agent, finnes det ingen skjerm i det hele tatt å vise den på. Så bestem hvordan en duplikat kommer til syne på hver vei: en advarsel for en person, en blokkert lagring og en feilmelding for API-et, eller Report-valget og duplikatpostsett (duplicate record sets) som noen kan gå gjennom senere. God arkitektur er ikke maksimal håndheving; det er riktig håndheving.

Og sjekk hvilke dører en duplikatregel faktisk vokter (Things to Know About Duplicate Rules (opens in a new tab)). Gjennom API-et og dataimportverktøyene ser ingen advarselen: en regel satt til å varsle blokkerer bare lagringen. Noen veier hopper helt over reglene: Quick Create, Undelete-knappen, en manuell sammenslåing, poster lagt til av Lightning Sync eller Einstein Activity Capture. Og poster som lagres i samme øyeblikk, sammenlignes ikke med hverandre, bare med poster som allerede finnes i Salesforce. Last inn en fil med samme kunde to ganger, og begge radene kan slippe gjennom. En duplikatregel er et godt nett. Den er ikke en lås på døren.

Eksamenskunnskap. Duplikatregler sammenligner ikke poster som lagres i samme øyeblikk med hverandre, bare med poster som allerede finnes i Salesforce. Gjennom API-et og importverktøyene kommer det ikke noe varsel: en duplikat regelen fanger, blir rett og slett ikke lagret. Og en lagring og alt den setter i gang, kjører som én transaksjon: feiler en del, rulles alt tilbake.

Én grense. Duplikatregler holder én org ren. De løser ikke identitet på tvers av virksomheten. Har Salesforce Acme Corporation, ERP-systemet ACME-10382 og faktureringen kunde 77193, kan ikke en duplikatregel fortelle deg at det er det samme firmaet. Det er masterdata, kapittel 6.

Trinn fem: automatisering

Noen regler er for komplekse for de nedre trinnene: de trenger relaterte poster, et annet system, avhengige poster, en prosess i flere steg. Det er Flow, Apex, noen ganger integrasjonslogikk. (Ikke Workflow Rules eller Process Builder; de har ikke lenger støtte.) Automatisering er kraftig og dyrere: flere bevegelige deler, mer testing, mer feilhåndtering, flere måter én automatisering kan snuble i en annen på. Og kode tar med seg egne feil. Kan felttypen håndheve det, skriver jeg ikke Apex. Sier en valideringsregel det tydelig, bygger jeg ikke en flow bare fordi Flow er der. Ikke løs et feltproblem med en prosessmotor.

Alt eller ingenting: når poster endres sammen

Så langt beskytter hvert trinn én lagring. Men poster endres sammen: en levering og linjene dens, en ordre og ordrelinjene, en flow som oppdaterer tre objekter. Her gir plattformen deg en sterk garanti. En lagring og alt den setter i gang, triggerne, flowene, klassene de kaller, kjører som én transaksjon: feiler en del, rulles det hele tilbake og ingenting committes (Apex Transactions (opens in a new tab)). Du får ikke en halv levering.

Bulkarbeid er unntaket du velger. En datainnlasting eller en Apex Database-metode kan tillate delvis suksess: de gode postene lagres, de dårlige kommer tilbake med feilene sine, og noen må ta seg av dem (DML Statements vs. Database Class Methods (opens in a new tab)). Det er ofte riktig for en innlasting av en million rader, men da er konsistens en prosess: hvem leser feilfilen, og hva skjer med postene som feilet?

Og så er det timingen. To lagringer i samme øyeblikk kan begge bestå en sjekk som hver av dem ville feilet alene. En flow som ser etter en eksisterende ordre og så oppretter en, kan slippe gjennom to, og vi så nettopp at duplikatregler ikke sammenligner poster som lagres samtidig. Et felt merket Unique, eller en External ID, sjekkes av plattformen ved hver lagring, så bare én av dem vinner. Det er én grunn til å skyve unikhet ned til feltet. Låser, konkurranse om ressurser og nye forsøk er et eget tema; kapittel 11, Transaksjoner, samtidighet og pålitelighet, går i dybden.

Skyv regelen ned, helt til den ikke hører hjemme der

«Så langt ned som du med rimelighet kan» betyr ikke «alltid lavest». Er et felt bare obligatorisk når en salgsmulighet når et visst stadium, er det feil å gjøre det obligatorisk i skjemaet; regelen er betinget, så en valideringsregel er riktig trinn. Skal en duplikat advare en person, men en godkjent integrasjon har sin egen avstemming, design for begge veiene. Målet: det laveste laget som representerer forretningsregelen riktig.

Hvert lag har en kostnad

Click to enlarge

Dette er avveiningen jeg vil at du skal se. Felttyper og kontrollerte verdier er enkle og sterke, men bare for det et felt kan uttrykke. Required og Unique er sløve: når de først er på, må hver skriving oppfylle dem. Valideringsregler uttrykker rikere betingelser, men kan blokkere endringer i gamle poster og overraske en utrulling. Duplikatregler beskytter på tvers av poster, men gir friksjon for brukere og integrasjoner. Automatisering håndterer alt, men gjør deg til eier av orkestrering, feil, tester og ytelse. Det finnes ikke noe gratis lag. Velg laget for hver regel med kunnskap om hvordan det feiler.

Før du slår den på

Å legge til en regel i en eksisterende org er en utrulling, ikke en avkrysningsboks. Hvor mange poster bryter den i dag, og hvorfor? Er de faktisk feil? Kan vi vite den riktige verdien? Er regelen sann historisk, eller bare fra nå av? Hvilke integrasjoner, tester og automatiseringer kommer til å treffe den? En god rekkefølge: mål, rydd det du kan bevise er feil, avgrens regelen, legg til et bevisst unntak for legitim historikk, test hver skrivevei, og håndhev så. Måling og opprydding er egne disipliner, profilering, standardisering, overvåking, forvaltning, og kapittel 5, Datakvalitet og styring, dekker dem. Mye bedre enn å krysse av i en boks på fredag og oppdage konsekvensene lørdag kveld.

Utover eksamen: hva KI endrer. En agent kan opprette poster raskere enn noen person, og dårlige poster like raskt. «Brukerne vet at de ikke skal gjøre det» er ingen beskyttelse når brukeren er en agent. Legg de viktige reglene i datalaget, der hver skriver møter dem, så agenten ikke må huske bedriftens uskrevne regler.

Steve Trucking: beskytt leveringen

Ta en levering. Statusen kommer fra ett vokabular: en plukkliste, begrenset. Detaljhandelspartnerens ordrereferanse må være unik per partner, så den er en External ID, merket unik, brukt til upsert av manifestet. Det faktiske leveringstidspunktet er obligatorisk når statusen er Delivered: en valideringsregel, avgrenset til den endringen. Et installasjonsstopp kan ikke lukkes før sjekklisten er fullført og de påkrevde bildene er tatt (for en oppvaskmaskin: vannledningen, avløpet og at den står i vater): en valideringsregel, eller automatisering hvis den må sjekke bildene som er lagret utenfor plattformen. Den samme ordren som kommer to ganger fra et manifest som ble sendt på nytt, fanges av External ID-en; to forskjellige ordrer som ligner hverandre, er et samsvarsspørsmål.

Legg merke til at jeg ikke sa «legg alt i en flow». Hver regel sitter på sitt eget trinn. For hver regel, spør: hva er det laveste laget som håndhever dette riktig for hver skrivevei som betyr noe?

Hva en arkitekt bestemmer her

• Hvilket trinn hver regel hører hjemme på: felttype, kontrollert vokabular, obligatorisk eller unik, valideringsregel, duplikatregel eller automatisering.
• Hvilke skriveveier som må beskyttes: brukergrensesnitt, portal, mobil, integrasjoner, bulkinnlastinger, API-er, automatisering og agenter.
• Om en ny regel gjelder historiske poster, eller er avgrenset til nye og endrede data med et unntak for fortiden.
• Om eksisterende dårlige data kan rettes ut fra bevis, i stedet for å skrives om så de består.
• Hvor mye friksjon, kompleksitet og vedlikehold en regel er verdt.

Rene data kommer ikke av å be folk legge inn gode data. De kommer av en arkitektur som gjør det riktige lett, det gale vanskelig og de viktige reglene vanskelige å omgå. Neste: vi setter kapitlet sammen på en bit av Steve Trucking.

Les mer

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) og Roll-Up Summary Field (opens in a new tab), på engelsk, kontrollert 2026-10-13.
• Salesforce Help, Picklist Limitations (opens in a new tab), på engelsk, kontrollert 2026-10-02.
• Salesforce Help, Validation Rule Considerations (opens in a new tab), på engelsk, kontrollert 2026-10-02.
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab), på engelsk, kontrollert 2026-10-13: grensene, veiene der reglene ikke kjører, lagringer via API og import som blokkeres uten varsel, samtidige lagringer som ikke sammenlignes.
• Apex Developer Guide, Apex Transactions (opens in a new tab) og DML Statements vs. Database Class Methods (opens in a new tab), på engelsk, kontrollert 2026-10-13: én transaksjon rulles tilbake som en enhet; Database-metoder kan tillate delvis suksess.
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab), på engelsk, kontrollert 2026-10-02.