Håll data konsistenta

🌐 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 9 av 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kursen Data Architect. Varje modul står på egna ben. Föregående: Ägarskap och livscykel · Nästa: Designa den fysiska modellen i Salesforce

Frågan den här modulen besvarar: Hur håller jag data konsistenta, och vad kostar varje lager?

Alla vill ha rena data. Jag har aldrig klivit in på ett kravmöte där någon sa: ”Det vi egentligen vill ha är inkonsistenta data.” Oenigheten kommer senare: var tvingar vi fram reglerna? På skärmen? Ett obligatoriskt fält? En plocklista, en valideringsregel, en dubblettregel, ett flöde, Apex? Alla hjälper. De är inte utbytbara, och varje lager har en kostnad.

Min allmänna regel är att trycka ned regeln så lågt som rimligen går. Om ett värde bara kan vara en av fem saker, låt inte folk skriva vad som helst för att sedan städa upp det med automatisering. Om två poster aldrig får dela en identifierare, förlita dig inte på att någon upptäcker det i en rapport. Om en regel måste gälla oavsett om posten kommer från en skärm, ett API, en integration, en dataladdning eller en agent, tvinga inte fram den bara i gränssnittet. Ju närmare data regeln sitter, desto svårare är den att komma runt. Jag kallar det konsistensstegen.

Steg ett: fälttypen och vokabulären

Den första konsistensregeln är den från modul 6: välj rätt typ. Ett datum är ett Date, en tidpunkt är ett Date/Time, pengar är Currency. Det är konsistens innan någon har skrivit en regel.

Gör en leverans status till ett textfält så får du Delivered, delivered, DELIVERED, Complete, Done och Dropped off, och någon måste lista ut om de sex betyder samma sak. Eller definiera vokabulären en gång: Delivered, ett värde, en betydelse. Gör det till en begränsad plocklista så att den avvisar allt som inte finns på listan, även via API:et, och till en global värdeuppsättning när flera fält delar listan (modul 6 har detaljerna).

Men använd inte en plocklista bara för att hindra folk från att skriva. Är det verkligen ett värde, eller en annan entitet? Nio distributionscentraler med ett namn var kan se ut som en plocklista; nio med adresser, chefer, kapacitet och lastbilar är poster. Regeln ska förstärka modellen, inte kompensera för en dålig. Och om det verkligen är en kontrollerad vokabulär, kontrollera den vid fältet. Tillåt inte kaos för att sedan bygga ett flöde som gör om AZ, Arizona, Ariz och Phoenix area till det värde du ville ha från början.

Steg två: Required och Unique

Required och Unique är lockande eftersom de är enkla: kryssa i rutan, problemet löst. Ibland. Om varje lastbil har ett flottnummer från den dag den skapas, och inga två lastbilar delar ett, uttrycker båda rutorna verkliga affärsregler. Det är stark konsistens.

Men när plattformen väl tvingar fram en regel bryr den sig inte om att din process har ett undantag på tisdagseftermiddagen. Jag har använt det här exemplet i klassrummet i åratal. Ett objekt har funnits ett tag, med gott om poster. Någon lägger till ett fält och kryssar i Required. De testar att skapa en post: fungerar utmärkt. Sedan lördagskväll, driftsättning, testerna körs, och en gammal testklass skapar objektet utan det nya fältet. Pang. Eller så redigerar någon en gammal post från tiden före fältet. Eller så skickar integrationen samma payload som den har skickat i fem år. Pang. ”Men vi ändrade ju inte det fältet.” Plattformen bryr sig inte: du ändrade kontraktet för vad en giltig post är. En ny regel påverkar inte bara nya data; den ändrar vad du kan göra med de gamla.

Steg tre: valideringsregler

Valideringsregler låter oss säga mycket rikare saker. Om statusen är Delivered måste den faktiska leveranstiden vara ifylld. Om stoppet är en installation måste checklistan vara klar innan stoppet kan stängas. De körs när posten sparas, så de skyddar posten oavsett om den sparades från en sida, API:et, en dataladdning, en integration eller en agent. Det är poängen. Om regeln ska skydda posten, lägg den där varje skrivning möter den.

De har också tänder. Det är både deras styrka och deras kostnad.

Problemet med gamla poster

Här blir det fult. Du har en miljon poster, och i dag lägger du till en regel: leveranstiden får inte vara före ruttens avgång. Förnuftigt. Men tjugotusen gamla poster bryter mot den, tack vare en migrering för sju år sedan. En användare öppnar en av dem och ändrar telefonnumret. Spara. Regeln slår till. ”Jag ändrade ett telefonnummer. Varför berättar du om en leveranstid från 2019?” Rimlig fråga.

Så en valideringsregel ska inte bara säga vad som måste vara sant. Den ska säga när det ska tvingas fram. Funktioner som ISNEW() och ISCHANGED() låter dig avgränsa en regel till nya poster, eller till sparningar där de relevanta fälten faktiskt ändras (Validation Rule Considerations (opens in a new tab)).

Men en post ändras inte bara när en person redigerar den, och många av anledningarna ligger utanför din kontroll. Integrationen uppdaterar statusen över natten. Ett flöde stämplar ett datum. En chef tilldelar om ett territorium och ägaren byts på tiotusen poster. Någon redigerar en leveransrad, sammanställningen på leveransen räknas om och det sparar leveransen, så leveransens valideringsregel slår till för en användare som aldrig rörde den (Roll-Up Summary Field (opens in a new tab) varnar för att valideringsfel kan visas på detaljposten eller mastern). Var och en av de sparningarna möter din nya regel. Så för varje ny regel, fråga: ska den här regeln gälla för den sparningen?

Det här är valen, och du vävar in dem i regeln:

• Alltid, vid varje sparning. Rätt när regeln verkligen handlar om posten och de gamla data klarar den. Men vet vad ”varje sparning” innebär: ett batchjobb som bara byter ägare, eller vilken liten ändring som helst i vilket fält som helst på posten, måste också klara den.
• Bara för nya poster, med ISNEW(). Regeln kontrollerar posten en gång, när den skapas, och aldrig mer. Det gamla förblir som det var, men det gör framtiden också: en senare redigering kan få en ny post att bryta mot regeln utan att någon stoppar det. Om det spelar roll, kombinera den med nästa.
• Bara när fälten den handlar om ändras, med ISCHANGED(). Att redigera telefonnumret väcker inte regeln om leveranstid.
• Inte för vissa skribenter. En anpassad behörighet (custom permission), som kontrolleras i formeln som $Permission, låter integrationsanvändaren eller en datamigrering passera medan människor fortfarande möter regeln (How to Reference a Custom Permission in a Validation Rule (opens in a new tab)). Ge den med avsikt och till få.
• Från ett datum och framåt, genom att jämföra CreatedDate med dagen regeln gick live, när ”ny” betyder ”sedan vi började tvinga fram det här”. Till skillnad från ISNEW() fortsätter den att kontrollera de posterna vid varje senare sparning, så samma varning gäller: en mindre ändring, som en ägaruppdatering i batch, kan misslyckas på en post som har glidit.

Lägger du till en regel på poster du redan har? Tänk igenom konsekvenserna innan du slår på den. Varje befintlig post måste nu klara den vid nästa sparning, och den sparningen kan komma från ett ställe du inte väntade dig: en nattlig integration, ett ägarbyte i batch, en sammanställning, en massuppdatering från en listvy. Vilka av dem kommer att träffa den, och vad händer med det jobbet när en post misslyckas? Avsnittet Innan du slår på den har ordningen jag använder.

Skriv inte om historien för att göra regeln nöjd

Hur gör vi med de tjugotusen gamla posterna? Om data är fel och du vet de rätta värdena, rätta dem. Men jag har sett en annan sorts ”lösning”: ingen vet den historiska sanningen, de behöver bara att posterna klarar regeln, så de uppdaterar dem med värden som uppfyller dagens regel. Det gillar jag inte. Att uppdatera gamla poster så att de följer regeln ändrar LastModifiedDate och förstör viktig historisk information, och att hitta på värden innebär att låtsas att vi vet något om det förflutna som vi inte vet. Ge regeln ett undantag för poster som är äldre än den i stället för att skriva om historien. Det kan vara fult, men det är ärligt.

Validering i gränssnittet är inte datavalidering

Gör ett fält obligatoriskt på en sidlayout så kan användarna inte spara utan det. Sedan infogar den nattliga integrationen 50 000 poster. Använde den din sida? Nej. Det gjorde inte bulkladdningen, API-klienten eller agenten heller. Ett krav i gränssnittet skyddar den skärmen, inte data. Fältvalidering i dynamiska formulär (dynamic forms) kan undvikas på samma sätt. Så fråga: var kan de här data komma in? Lightning, portalen, mobilen, integrationen, API:et, en bulkladdning, Flow, Apex, en agent. Ju fler dörrar det finns, desto mindre litar jag på en regel som bara vaktar en av dem.

Steg fyra: dubblettregler

Nu går vi från konsistens inom en post till konsistens mellan poster. Acme Corporation, ACME Corp, Acme Inc.: fyra kunder eller en? Ingen fältregel kan svara på det. Matchningsregler definierar hur poster jämförs; dubblettregler avgör vad som händer när en trolig dubblett hittas: tillåt med en varning, blockera eller rapportera. Du kan ha upp till fem aktiva dubblettregler per objekt och upp till tre matchningsregler i varje, och matchningsnycklar (match keys) begränsar varje jämförelse till de 100 troligaste dubbletterna (Things to Know About Duplicate Rules (opens in a new tab)).

Kostnaden är friktion. Om varje konto som en säljare skapar säger Possible duplicate found (möjlig dubblett hittad) är det ibland precis vad du vill, och ibland lär sig folk att klicka sig förbi utan att läsa. Legitima poster kan likna varandra, och en integration kan behöva ett annat beteende än en person. Och varningen är Salesforces egen: dess avisering och dess lista över möjliga dubbletter kanske inte smälter in i en anpassad skärm som du har byggt, och när sparningen sker headless, en integration, en dataladdning, en agent, finns det ingen skärm alls att visa den på. Så bestäm hur en dubblett dyker upp på varje väg: en varning för en person, en blockerad sparning och ett fel för API:et, eller alternativet Report och dubblettpostuppsättningar (duplicate record sets) som någon granskar senare. Bra arkitektur är inte maximal tvingande kontroll; det är rätt tvingande kontroll.

Och kontrollera vilka dörrar en dubblettregel faktiskt vaktar (Things to Know About Duplicate Rules (opens in a new tab)). Via API:et och dataimportverktygen ser ingen varningen: en regel som är satt att varna blockerar helt enkelt sparningen. Vissa vägar hoppar helt över reglerna: Quick Create, knappen Undelete, en manuell sammanslagning, poster som läggs till av Lightning Sync eller Einstein Activity Capture. Och poster som sparas i samma ögonblick jämförs inte med varandra, bara med poster som redan finns i Salesforce. Ladda en fil med samma kund två gånger, så kan båda raderna slinka igenom. En dubblettregel är ett bra nät. Den är inget lås på dörren.

Provkunskap. Dubblettregler jämför inte poster som sparas i samma ögonblick med varandra, bara med poster som redan finns i Salesforce. Via API:et och importverktygen visas ingen avisering: en dubblett som regeln fångar sparas helt enkelt inte. Och en sparning och allt den sätter igång körs som en transaktion: om någon del misslyckas rullas allt tillbaka.

En gräns. Dubblettregler håller en org ren. De löser inte identitet på företagsnivå. Om Salesforce har Acme Corporation, ERP-systemet har ACME-10382 och faktureringen har kund 77193, kan en dubblettregel inte säga dig att det är samma företag. Det är masterdata, kapitel 6.

Steg fem: automatisering

Vissa regler är för komplexa för de lägre stegen: de behöver relaterade poster, ett annat system, beroende poster, en process i flera steg. Det är Flow, Apex, ibland integrationslogik. (Inte Workflow Rules eller Process Builder; de har inte längre support.) Automatisering är kraftfull och dyrare: fler rörliga delar, mer testning, mer felhantering, fler sätt för en automatisering att snubbla över en annan. Och kod för med sig egna fel. Om fälttypen kan tvinga fram det skriver jag inte Apex. Om en valideringsregel säger det tydligt bygger jag inte ett flöde bara för att Flow finns. Lös inte ett fältproblem med en processmotor.

Allt eller inget: när poster ändras tillsammans

Hittills skyddar varje steg en sparning. Men poster ändras tillsammans: en leverans och dess rader, en order och dess rader, ett flöde som uppdaterar tre objekt. Här ger plattformen dig en stark garanti. En sparning och allt den sätter igång, triggrarna, flödena, klasserna de anropar, körs som en transaktion: om någon del misslyckas rullas det hela tillbaka och ingenting sparas permanent (Apex Transactions (opens in a new tab)). Du får inte en halv leverans.

Bulkarbete är undantaget du väljer. En dataladdning eller en Apex Database-metod kan tillåta partiell framgång: de bra posterna sparas, de dåliga kommer tillbaka med sina fel, och någon måste ta hand om dem (DML Statements vs. Database Class Methods (opens in a new tab)). Det är ofta rätt för en laddning av en miljon rader, men då är konsistensen en process: vem läser felfilen, och vad händer med posterna som misslyckades?

Och sedan har vi timingen. Två sparningar i samma ögonblick kan båda klara en kontroll som var och en skulle misslyckas med ensam. Ett flöde som letar efter en befintlig order och sedan skapar en kan släppa igenom två, och vi såg nyss att dubblettregler inte jämför poster som sparas samtidigt. Ett fält markerat som Unique, eller ett External ID, kontrolleras av plattformen vid varje sparning, så bara en av dem vinner. Det är ytterligare en anledning att trycka ned unikheten till fältet. Lås, konkurrens om resurser och omförsök är ett eget ämne; kapitel 11, Transaktioner, samtidighet och tillförlitlighet, går på djupet.

Tryck ned regeln, tills den inte hör hemma där

”Så lågt som rimligen går” betyder inte ”alltid lägst”. Om ett fält bara är obligatoriskt när en affärsmöjlighet når ett visst stadium är det fel att göra det obligatoriskt i schemat; regeln är villkorad, så en valideringsregel är rätt steg. Om en dubblett ska varna en person men en godkänd integration har sin egen avstämning, designa för båda vägarna. Målet: det lägsta lager som korrekt representerar affärsregeln.

Varje lager har en kostnad

Click to enlarge

Det här är avvägningen jag vill att du ser. Fälttyper och kontrollerade värden är enkla och starka, men bara för det som ett fält kan uttrycka. Required och Unique är trubbiga: när de väl är på måste varje skrivning uppfylla dem. Valideringsregler uttrycker rikare villkor men kan blockera redigering av gamla poster och överraska en driftsättning. Dubblettregler skyddar mellan poster men lägger till friktion för användare och integrationer. Automatisering klarar vad som helst men gör att du äger orkestrering, fel, tester och prestanda. Det finns inget gratis lager. Välj varje regels lager med vetskap om hur det fallerar.

Innan du slår på den

Att lägga till en regel i en befintlig org är en utrullning, inte en kryssruta. Hur många poster bryter mot den i dag, och varför? Är de faktiskt fel? Kan vi veta det rätta värdet? Är regeln sann historiskt, eller bara från och med nu? Vilka integrationer, tester och automatiseringar kommer att träffa den? En bra ordning: mät, städa det du kan bevisa är fel, avgränsa regeln, lägg till ett medvetet undantag för legitim historik, testa varje skrivväg och tvinga sedan fram den. Att mäta och städa är egna discipliner, profilering, standardisering, övervakning, dataförvaltning, och kapitel 5, Datakvalitet och styrning, tar upp dem. Mycket bättre än att kryssa i en ruta på fredagen och upptäcka konsekvenserna på lördagskvällen.

Bortom provet: vad AI förändrar. En agent kan skapa poster snabbare än någon människa, och dåliga poster lika snabbt. ”Användarna vet att man inte gör så” är inget skydd när användaren är en agent. Lägg de viktiga reglerna i datalagret, där varje skribent möter dem, så att agenten inte behöver komma ihåg företagets oskrivna regler.

Steve Trucking: skydda leveransen

Ta en leverans. Dess status kommer från en vokabulär: en plocklista, begränsad. Detaljhandelspartnerns orderreferens måste vara unik per partner, så den är ett External ID, markerat som unikt, som används för att göra upsert av manifestet. Den faktiska leveranstiden är obligatorisk när statusen är Delivered: en valideringsregel, avgränsad till den ändringen. Ett installationsstopp kan inte stängas förrän checklistan är klar och de obligatoriska fotona är tagna (för en diskmaskin: vattenledningen, avloppsledningen och att den står i våg): en valideringsregel, eller automatisering om den måste kontrollera foton som lagras utanför plattformen. Samma order som kommer två gånger från ett manifest som skickats om fångas av External ID; två olika ordrar som liknar varandra är en matchningsfråga.

Lägg märke till att jag inte sa ”lägg alla i ett flöde”. Varje regel sitter på sitt eget steg. För varje regel, fråga: vilket är det lägsta lager som tvingar fram det här korrekt för varje skrivväg som spelar roll?

Vad en arkitekt bestämmer här

• Vilket steg varje regel hör hemma på: fälttyp, kontrollerad vokabulär, obligatoriskt eller unikt, valideringsregel, dubblettregel eller automatisering.
• Vilka skrivvägar som måste skyddas: gränssnitt, portal, mobil, integrationer, bulkladdningar, API:er, automatisering och agenter.
• Om en ny regel gäller historiska poster, eller är avgränsad till nya och ändrade data med ett undantag för det förflutna.
• Om befintliga dåliga data kan rättas utifrån belägg, i stället för att skrivas om för att klara regeln.
• Hur mycket friktion, komplexitet och underhåll en regel är värd.

Rena data kommer inte av att be folk mata in bra data. De kommer från en arkitektur som gör det rätta lätt, det felaktiga svårt och de viktiga reglerna svåra att kringgå. Härnäst sätter vi ihop kapitlet på en del av Steve Trucking.

Utforska vidare

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) och Roll-Up Summary Field (opens in a new tab) (på engelska, kontrollerad 2026-10-13).
• Salesforce Help, Picklist Limitations (opens in a new tab) (på engelska, kontrollerad 2026-10-02).
• Salesforce Help, Validation Rule Considerations (opens in a new tab) (på engelska, kontrollerad 2026-10-02).
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (på engelska, kontrollerad 2026-10-13): gränserna, vägarna där reglerna inte körs, sparningar via API och import som blockeras utan avisering, samtidiga sparningar som inte jämförs.
• Apex Developer Guide, Apex Transactions (opens in a new tab) och DML Statements vs. Database Class Methods (opens in a new tab) (på engelska, kontrollerad 2026-10-13): en transaktion rullas tillbaka som en enhet; Database-metoder kan tillåta partiell framgång.
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab) (på engelska, kontrollerad 2026-10-02).