Hold data konsistente

🌐 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 9 af 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Ejerskab og livscyklus · Næste: Design den fysiske model i Salesforce

Spørgsmålet, dette modul besvarer: Hvordan holder jeg data konsistente, og hvad koster hvert lag?

Alle vil have rene data. Jeg har aldrig været til et kravmøde, hvor nogen sagde: »Det, vi virkelig gerne vil have, er inkonsistente data.« Uenigheden kommer senere: Hvor håndhæver vi reglerne? På skærmen? Et påkrævet felt? En valgliste, en valideringsregel, en dubletregel, et flow, Apex? De hjælper alle. De er ikke indbyrdes udskiftelige, og hvert lag har en pris.

Min generelle regel er at skubbe reglen så langt ned, som det med rimelighed kan lade sig gøre. Hvis en værdi kun kan være én af fem ting, så lad ikke folk skrive hvad som helst og ryd op senere med automatisering. Hvis to poster aldrig må dele en identifikator, så regn ikke med, at nogen opdager det i en rapport. Hvis en regel skal holde, uanset om posten kommer fra en skærm, et API, en integration, en dataindlæsning eller en agent, så håndhæv den ikke kun i brugerfladen. Jo tættere reglen sidder på dataene, jo sværere er den at komme uden om. Jeg kalder det konsistensstigen.

Første trin: felttypen og ordforrådet

Den første konsistensregel er den fra modul 6: Vælg den rigtige type. En dato er en Date, et tidspunkt er en Date/Time, penge er Currency. Det er konsistens, før nogen skriver en regel.

Gør en leverings status til et tekstfelt, og du får Delivered, delivered, DELIVERED, Complete, Done og Dropped off, og nogen skal finde ud af, om de seks betyder det samme. Eller definér ordforrådet én gang: Delivered, én værdi, én betydning. Gør det til en begrænset valgliste, så den afviser alt, der ikke står på listen, også via API’et, og til et globalt værdisæt, når flere felter deler listen (modul 6 har detaljerne).

Men brug ikke en valgliste bare for at forhindre folk i at skrive. Er det virkelig en værdi eller en anden entitet? Ni distributionscentre med hvert sit navn kan ligne en valgliste; ni med adresser, ledere, kapacitet og lastbiler er poster. Reglen skal forstærke modellen, ikke kompensere for en dårlig. Og hvis det virkelig er et kontrolleret ordforråd, så styr det ved feltet. Tillad ikke kaos for så at bygge et flow, der gør AZ, Arizona, Ariz og Phoenix area til den værdi, du ville have i første omgang.

Andet trin: påkrævet og unik

Required og Unique er tillokkende, fordi de er enkle: Sæt flueben, problem løst. Nogle gange. Hvis hver lastbil har et flådenummer fra den dag, den oprettes, og ingen to lastbiler deler ét, udtrykker begge felter reelle forretningsregler. Det er stærk konsistens.

Men når platformen først håndhæver en regel, er den ligeglad med, at din proces har en undtagelse tirsdag eftermiddag. Jeg har brugt dette eksempel i klassen i årevis. Et objekt har eksisteret et stykke tid med masser af poster. Nogen tilføjer et felt og sætter flueben i Required. De tester at oprette en post: virker smukt. Så lørdag aften, deployment, testene kører, og en gammel testklasse opretter objektet uden det nye felt. Bum. Eller nogen redigerer en gammel post fra før feltet fandtes. Eller integrationen sender den samme payload, som den har sendt i fem år. Bum. »Men vi har ikke ændret det felt.« Platformen er ligeglad: Du har ændret kontrakten for, hvad en gyldig post er. En ny regel påvirker ikke kun nye data; den ændrer, hvad du kan gøre med de gamle.

Tredje trin: valideringsregler

Valideringsregler lader os sige meget rigere ting. Hvis status er Delivered, skal det faktiske leveringstidspunkt være udfyldt. Hvis stoppet er en installation, skal tjeklisten være færdig, før stoppet kan lukkes. De kører, når posten gemmes, så de beskytter posten, uanset om den blev gemt fra en side, API’et, en dataindlæsning, en integration eller en agent. Det er hele pointen. Hvis reglen skal beskytte posten, så placér den, hvor hver eneste skrivning møder den.

De har også tænder. Det er både deres styrke og deres pris.

Problemet med de gamle poster

Her bliver det grimt. Du har en million poster, og i dag tilføjer du en regel: Leveringstidspunktet må ikke ligge før rutens afgang. Fornuftigt. Men tyve tusind gamle poster bryder den takket være en migrering for syv år siden. En bruger åbner en af dem og ændrer telefonnummeret. Gem. Reglen slår til. »Jeg ændrede et telefonnummer. Hvorfor fortæller du mig om et leveringstidspunkt fra 2019?« Rimeligt spørgsmål.

Så en valideringsregel skal ikke kun sige, hvad der skal være sandt. Den skal sige, hvornår det skal håndhæves. Funktioner som ISNEW() og ISCHANGED() lader dig afgrænse en regel til nye poster eller til gem, hvor de relevante felter faktisk ændres (Validation Rule Considerations (opens in a new tab)).

Men en post ændres ikke kun, når en person redigerer den, og mange af grundene er uden for din kontrol. Integrationen opdaterer status i løbet af natten. Et flow stempler en dato. En leder omfordeler et område, og ejeren ændres på ti tusind poster. Nogen redigerer en leveringslinje, roll-up’et på leveringen genberegnes, og det gemmer leveringen, så leveringens valideringsregel slår til for en bruger, der aldrig rørte den (Roll-Up Summary Field (opens in a new tab) advarer om, at valideringsfejl kan vises på detaljen eller masteren). Hver eneste af de gem møder din nye regel. Så for hver ny regel skal du spørge: Skal denne regel gælde for det gem?

Det er valgene, og du væver dem ind i reglen:

• Altid, ved hvert gem. Rigtigt, når reglen virkelig handler om posten, og de gamle data består. Men vid, hvad »hvert gem« betyder: Et batchjob, der kun ændrer ejeren, eller enhver lille redigering af et hvilket som helst felt på posten, skal også bestå den.
• Kun for nye poster, med ISNEW(). Reglen tjekker posten én gang, når den oprettes, og aldrig igen. Fortiden forbliver, som den var, men det gør fremtiden også: En senere redigering kan få en ny post til at bryde reglen, og ingen vil stoppe det. Hvis det betyder noget, så kombinér den med den næste.
• Kun når de felter, den handler om, ændres, med ISCHANGED(). At redigere telefonnummeret vækker ikke reglen om leveringstidspunktet.
• Ikke for bestemte skrivere. En brugerdefineret tilladelse (custom permission), tjekket i formlen som $Permission, lader integrationsbrugeren eller en datamigrering komme igennem, mens mennesker stadig møder reglen (How to Reference a Custom Permission in a Validation Rule (opens in a new tab)). Giv den med vilje og til få.
• Fra en dato og frem, ved at sammenligne CreatedDate med den dag, reglen gik live, når »ny« betyder »siden vi begyndte at håndhæve det her«. I modsætning til ISNEW() bliver den ved med at tjekke de poster ved hvert senere gem, så den samme advarsel gælder: En lille ændring, som en batchopdatering af ejeren, kan fejle på en post, der har flyttet sig.

Tilføjer du en regel til poster, du allerede har? Tænk konsekvenserne igennem, før du slår den til. Hver eksisterende post skal nu bestå den ved sit næste gem, og det gem kan komme et sted fra, du ikke havde forventet: en natlig integration, en batchændring af ejer, et roll-up, en masseopdatering fra en listevisning. Hvilke af dem vil ramme den, og hvad sker der med det job, når én post fejler? Afsnittet Før du slår den til har den rækkefølge, jeg bruger.

Omskriv ikke historien for at gøre reglen glad

Hvad med de tyve tusind gamle poster? Hvis dataene er forkerte, og du kender de rigtige værdier, så ret dem. Men jeg har set en anden slags »rettelse«: Ingen kender den historiske sandhed, de skal bare have posterne til at bestå, så de opdaterer dem med værdier, der opfylder dagens regel. Det bryder jeg mig ikke om. At opdatere gamle poster, så de overholder reglen, ændrer LastModifiedDate og ødelægger vigtig historisk information, og at opfinde værdier betyder at lade som om, vi ved noget om fortiden, som vi ikke gør. Giv reglen en undtagelse for poster, der er ældre end den, i stedet for at omskrive historien. Det kan være grimt, men det er ærligt.

Validering i brugerfladen er ikke datavalidering

Gør et felt påkrævet i et sidelayout, og brugerne kan ikke gemme uden det. Så indsætter den natlige integration 50.000 poster. Brugte den din side? Nej. Det gjorde bulkindlæsningen, API-klienten og agenten heller ikke. Et krav i brugerfladen beskytter den skærm, ikke dataene. Feltvalidering i dynamiske formularer kan omgås på samme måde. Så spørg: Hvor kan disse data komme ind? Lightning, portalen, mobil, integrationen, API’et, en bulkindlæsning, Flow, Apex, en agent. Jo flere døre der er, jo mindre stoler jeg på en regel, der kun vogter én af dem.

Fjerde trin: dubletregler

Nu går vi fra konsistens inden for en post til konsistens på tværs af poster. Acme Corporation, ACME Corp, Acme Inc.: fire kunder eller én? Ingen feltregel kan svare på det. Matchningsregler (matching rules) definerer, hvordan poster sammenlignes; dubletregler (duplicate rules) bestemmer, hvad der sker, når en sandsynlig dublet bliver fundet: tillad med en advarsel, bloker eller rapportér. Du kan have op til fem aktive dubletregler pr. objekt og op til tre matchningsregler i hver, og matchnøgler indsnævrer hver sammenligning til de 100 mest sandsynlige dubletter (Things to Know About Duplicate Rules (opens in a new tab)).

Deres pris er friktion. Hvis hver konto, en sælger opretter, siger Possible duplicate found (mulig dublet fundet), er det nogle gange præcis det, du vil have, og nogle gange lærer folk at klikke videre uden at læse. Legitime poster kan ligne hinanden, og en integration kan have brug for en anden adfærd end en person. Og advarslen er Salesforces egen: Dens besked og dens liste over mulige dubletter passer måske ikke ind i en brugerdefineret skærm, du har bygget, og når gemmet er headless, en integration, en dataindlæsning, en agent, er der slet ingen skærm at vise den på. Så beslut, hvordan en dublet kommer frem på hver vej: en advarsel til en person, et blokeret gem og en fejl til API’et eller muligheden Report og duplicate record sets, som nogen gennemgår senere. God arkitektur er ikke maksimal håndhævelse; det er den rigtige håndhævelse.

Og tjek, hvilke døre en dubletregel faktisk vogter (Things to Know About Duplicate Rules (opens in a new tab)). Via API’et og dataimportværktøjerne ser ingen advarslen: En regel, der er sat til at advare, blokerer simpelthen gemmet. Nogle veje springer helt over reglerne: Quick Create, knappen Undelete, en manuel sammenfletning, poster tilføjet af Lightning Sync eller Einstein Activity Capture. Og poster, der gemmes i samme øjeblik, sammenlignes ikke med hinanden, kun med poster, der allerede er i Salesforce. Indlæs en fil med den samme kunde to gange, og begge rækker kan slippe igennem. En dubletregel er et godt net. Den er ikke en lås på døren.

Eksamensviden. Dubletregler sammenligner ikke poster, der gemmes i samme øjeblik, med hinanden, kun med poster, der allerede er i Salesforce. Via API’et og importværktøjerne er der ingen advarsel: En dublet, som reglen fanger, bliver simpelthen ikke gemt. Og et gem og alt, hvad det sætter i gang, kører som én transaktion: Hvis en del fejler, rulles det hele tilbage.

Én afgrænsning. Dubletregler holder én org ren. De løser ikke identitet på tværs af virksomheden. Hvis Salesforce har Acme Corporation, ERP-systemet har ACME-10382, og faktureringen har kunde 77193, kan en dubletregel ikke fortælle dig, at det er den samme virksomhed. Det er masterdata, kapitel 6.

Femte trin: automatisering

Nogle regler er for komplekse til de nederste trin: De kræver relaterede poster, et andet system, afhængige poster, en proces i flere trin. Det er Flow, Apex, nogle gange integrationslogik. (Ikke Workflow Rules eller Process Builder; de understøttes ikke længere.) Automatisering er kraftfuld og dyrere: flere bevægelige dele, mere test, mere fejlhåndtering, flere måder, hvorpå én automatisering kan falde over en anden. Og kode bringer sine egne fejl med. Hvis felttypen kan håndhæve det, skriver jeg ikke Apex. Hvis en valideringsregel siger det klart, bygger jeg ikke et flow, bare fordi Flow er der. Løs ikke et feltproblem med en procesmotor.

Alt eller intet: når poster ændres sammen

Indtil nu beskytter hvert trin ét gem. Men poster ændres sammen: en levering og dens linjer, en ordre og dens linjer, et flow, der opdaterer tre objekter. Her giver platformen dig en stærk garanti. Et gem og alt, hvad det sætter i gang, triggerne, flowene, de klasser, de kalder, kører som én transaktion: Hvis en del fejler, rulles det hele tilbage, og intet bliver committet (Apex Transactions (opens in a new tab)). Du får ikke en halv levering.

Bulkarbejde er den undtagelse, du selv vælger. En dataindlæsning eller en Apex-Database-metode kan tillade delvis succes: De gode poster gemmes, de dårlige kommer tilbage med deres fejl, og nogen skal tage sig af dem (DML Statements vs. Database Class Methods (opens in a new tab)). Det er ofte rigtigt for en indlæsning af en million rækker, men så er konsistens en proces: Hvem læser fejlfilen, og hvad sker der med de poster, der fejlede?

Og så er der timingen. To gem i samme øjeblik kan begge bestå et tjek, som hver af dem ville fejle alene. Et flow, der leder efter en eksisterende ordre og derefter opretter én, kan lukke to igennem, og vi har lige set, at dubletregler ikke sammenligner poster, der gemmes samtidig. Et felt markeret som Unique, eller et External ID, tjekkes af platformen ved hvert gem, så kun én af dem vinder. Det er endnu en grund til at skubbe unikhed ned til feltet. Låse, konkurrence om ressourcer og genforsøg er et emne for sig; kapitel 11, Transaktioner, samtidighed og pålidelighed, går i dybden.

Skub reglen ned, indtil den ikke hører hjemme der

»Så langt ned, som det med rimelighed kan lade sig gøre« betyder ikke »altid det nederste«. Hvis et felt først er påkrævet, når en salgsmulighed når en bestemt fase, er det forkert at gøre det påkrævet i skemaet; reglen er betinget, så en valideringsregel er det rigtige trin. Hvis en dublet skal advare en person, men en godkendt integration har sin egen afstemning, så design til begge veje. Målet: det laveste lag, der korrekt repræsenterer forretningsreglen.

Hvert lag har en pris

Click to enlarge

Det er den afvejning, jeg vil have dig til at se. Felttyper og kontrollerede værdier er enkle og stærke, men kun for det, et felt kan udtrykke. Required og Unique er stumpe: Når de først er slået til, skal hver skrivning opfylde dem. Valideringsregler udtrykker rigere betingelser, men kan blokere redigeringer af gamle poster og overraske en deployment. Dubletregler beskytter på tværs af poster, men tilføjer friktion for brugere og integrationer. Automatisering kan håndtere hvad som helst, men gør dig ansvarlig for orkestrering, fejl, test og ydeevne. Der findes intet gratis lag. Vælg hver regels lag med viden om, hvordan det fejler.

Før du slår den til

At tilføje en regel til en eksisterende org er en udrulning, ikke et flueben. Hvor mange poster bryder den i dag, og hvorfor? Er de faktisk forkerte? Kan vi kende den rigtige værdi? Er reglen sand historisk eller kun fra nu af? Hvilke integrationer, test og automatiseringer vil ramme den? En god rækkefølge: mål, ryd op i det, du kan bevise er forkert, afgræns reglen, tilføj en bevidst undtagelse for legitim historik, test hver skrivevej, og håndhæv så. Måling og oprydning er discipliner for sig, profilering, standardisering, overvågning, dataforvaltning, og kapitel 5, Datakvalitet og styring, dækker dem. Langt bedre end at sætte et flueben om fredagen og opdage konsekvenserne lørdag aften.

Ud over eksamen: hvad AI ændrer. En agent kan oprette poster hurtigere end nogen person, og dårlige poster lige så hurtigt. »Brugerne ved godt, at de ikke må gøre det« er ingen beskyttelse, når brugeren er en agent. Læg de vigtige regler i datalaget, hvor hver skriver møder dem, så agenten ikke skal huske virksomhedens uskrevne regler.

Steve Trucking: beskyt leveringen

Tag en levering. Dens status kommer fra ét ordforråd: en valgliste, begrænset. Detailpartnerens ordrereference skal være unik pr. partner, så den er et External ID, markeret som unik, som bruges til upsert af manifestet. Det faktiske leveringstidspunkt er påkrævet, når status er Delivered: en valideringsregel, afgrænset til den ændring. Et installationsstop kan ikke lukkes, før dets tjekliste er færdig, og de påkrævede fotos er taget (for en opvaskemaskine vandtilførslen, afløbet og nivelleringen): en valideringsregel eller automatisering, hvis den skal tjekke fotos, der er gemt uden for platformen. Den samme ordre, der ankommer to gange fra et gensendt manifest, fanges af External ID’et; to forskellige ordrer, der ligner hinanden, er et spørgsmål om matchning.

Læg mærke til, at jeg ikke sagde »læg dem alle i et flow«. Hver regel sidder på sit eget trin. For hver regel skal du spørge: Hvad er det laveste lag, der håndhæver dette korrekt for hver skrivevej, der betyder noget?

Hvad en arkitekt beslutter her

• Hvilket trin hver regel hører hjemme på: felttype, kontrolleret ordforråd, påkrævet eller unik, valideringsregel, dubletregel eller automatisering.
• Hvilke skriveveje der skal beskyttes: brugerflade, portal, mobil, integrationer, bulkindlæsninger, API’er, automatisering og agenter.
• Om en ny regel gælder for historiske poster eller er afgrænset til nye og ændrede data med en undtagelse for fortiden.
• Om eksisterende dårlige data kan rettes ud fra dokumentation i stedet for at blive omskrevet, så de består.
• Hvor meget friktion, kompleksitet og vedligeholdelse en regel er værd.

Rene data kommer ikke af at bede folk om at indtaste gode data. De kommer af en arkitektur, der gør det rigtige nemt, det forkerte svært og de vigtige regler svære at omgå. Næste gang samler vi kapitlet på et udsnit af Steve Trucking.

Læs mere

• 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, kontrolleret 2026-10-13.
• Salesforce Help, Picklist Limitations (opens in a new tab), på engelsk, kontrolleret 2026-10-02.
• Salesforce Help, Validation Rule Considerations (opens in a new tab), på engelsk, kontrolleret 2026-10-02.
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab), på engelsk, kontrolleret 2026-10-13: grænserne, de veje, hvor reglerne ikke kører, gem via API og import, der blokeres uden advarsel, samtidige gem, der 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, kontrolleret 2026-10-13: Én transaktion rulles tilbage som en helhed; Database-metoder kan tillade delvis succes.
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab), på engelsk, kontrolleret 2026-10-02.