Gegevens consistent houden

🌐 Ook beschikbaar in 28 talen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Afbeelding gegenereerd met AI

Vertaald door AI. Nog niet door de community nagekeken. Lees in het Engels

Module 9 van 10 in het hoofdstuk Salesforce-data-architectuur, hoofdstuk 3 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Eigenaarschap en levenscyclus · Volgende: Ontwerp het fysieke Salesforce-model

De vraag die deze module beantwoordt: Hoe houd ik data consistent, en wat kost elke laag?

Iedereen wil schone data. Ik ben nog nooit een eisensessie binnengelopen waar iemand zei: “Wat we eigenlijk willen, is inconsistente data.” De onenigheid komt later: waar dwingen we de regels af? Op het scherm? Een verplicht veld? Een keuzelijst, een validatieregel, een duplicaatregel, een flow, Apex? Ze helpen allemaal. Ze zijn niet uitwisselbaar, en elke laag heeft een prijs.

Mijn algemene regel is duw de regel zo laag als redelijkerwijs kan. Als een waarde maar een van vijf dingen kan zijn, laat mensen dan niet van alles typen om het later met automatisering op te ruimen. Als twee records nooit dezelfde identificator mogen hebben, vertrouw er dan niet op dat iemand het in een rapport opmerkt. Als een regel moet gelden of het record nu van een scherm komt, een API, een integratie, een dataload of een agent, dwing het dan niet alleen in de UI af. Hoe dichter de regel bij de data zit, hoe moeilijker hij te omzeilen is. Ik noem het de consistentieladder.

Sport één: het veldtype en de woordenlijst

De eerste consistentieregel is die uit module 6: kies het juiste type. Een datum is een Date, een moment is een Date/Time, geld is Currency. Dat is consistentie voordat iemand een regel schrijft.

Maak de status van een levering een tekstveld en je krijgt Delivered, delivered, DELIVERED, Complete, Done en Dropped off, en iemand moet uitzoeken of die zes hetzelfde betekenen. Of definieer de woordenlijst één keer: Delivered, één waarde, één betekenis. Maak er een beperkte keuzelijst van, zodat alles wat niet op de lijst staat geweigerd wordt, zelfs via de API, en een globale waardeset als meerdere velden de lijst delen (module 6 heeft de details).

Maar gebruik een keuzelijst niet alleen om mensen te laten ophouden met typen. Is het echt een waarde, of een andere entiteit? Negen distributiecentra met elk een naam lijken misschien een keuzelijst; negen met adressen, managers, capaciteit en vrachtwagens zijn records. De regel moet het model versterken, niet een slecht model compenseren. En als het echt een gecontroleerde woordenlijst is, beheer haar dan bij het veld. Laat geen chaos toe om dan een flow te bouwen die AZ, Arizona, Ariz en Phoenix area omzet in de waarde die je in de eerste plaats wilde.

Sport twee: verplicht en uniek

Verplicht en uniek zijn aantrekkelijk omdat ze simpel zijn: vinkje aan, probleem opgelost. Soms. Als elke vrachtwagen vanaf de dag dat hij wordt aangemaakt een vlootnummer heeft, en geen twee vrachtwagens hetzelfde delen, drukken beide vinkjes echte bedrijfsregels uit. Dat is sterke consistentie.

Maar zodra het platform een regel afdwingt, kan het hem niet schelen dat je proces op dinsdagmiddag een uitzondering heeft. Ik gebruik dit voorbeeld al jaren in de klas. Een object bestaat al een tijd, met flink wat records. Iemand voegt een veld toe en vinkt Required aan. Ze testen het aanmaken van een record: werkt prachtig. Dan zaterdagavond, deployment, de tests draaien, en een oude testklasse maakt het object aan zonder het nieuwe veld. Boem. Of iemand bewerkt een oud record van voordat het veld bestond. Of de integratie stuurt dezelfde payload die ze al vijf jaar stuurt. Boem. “Maar we hebben dat veld niet veranderd.” Het platform kan het niet schelen: je hebt het contract veranderd over wat een geldig record is. Een nieuwe regel raakt niet alleen nieuwe data; ze verandert wat je met de oude data kunt doen.

Sport drie: validatieregels

Met validatieregels kunnen we veel rijkere dingen zeggen. Als de status Delivered is, moet het werkelijke bezorgtijdstip ingevuld zijn. Als de stop een installatie is, moet de checklist compleet zijn voordat de stop kan worden afgesloten. Ze draaien als het record wordt opgeslagen, dus ze beschermen het record of het nu wordt opgeslagen vanaf een pagina, de API, een dataload, een integratie of een agent. Dat is het punt. Als de regel het record moet beschermen, zet haar dan waar elke schrijfactie haar tegenkomt.

Ze hebben ook tanden. Dat is hun kracht en hun prijs.

Het probleem van de oude records

Hier wordt het lelijk. Je hebt een miljoen records, en vandaag voeg je een regel toe: het bezorgtijdstip mag niet vóór het vertrek van de route liggen. Logisch. Maar twintigduizend oude records overtreden haar, dankzij een migratie van zeven jaar geleden. Een gebruiker opent er een en verandert het telefoonnummer. Opslaan. De regel gaat af. “Ik heb een telefoonnummer veranderd. Waarom begin je over een bezorgtijdstip uit 2019?” Terechte vraag.

Een validatieregel moet dus niet alleen zeggen wat er waar moet zijn. Ze moet zeggen wanneer het afgedwongen wordt. Functies als ISNEW() en ISCHANGED() laten je een regel beperken tot nieuwe records, of tot opslagacties waarbij de relevante velden echt veranderen (Validation Rule Considerations (opens in a new tab), Engels).

Maar een record verandert niet alleen als een persoon het bewerkt, en veel van de redenen heb je niet in de hand. De integratie werkt ‘s nachts de status bij. Een flow zet een datum. Een manager wijst een gebied opnieuw toe en de eigenaar verandert op tienduizend records. Iemand bewerkt een leveringsitem, het samenvattingsveld op de levering wordt opnieuw berekend, en dat slaat de levering op, dus de validatieregel van de levering gaat af voor een gebruiker die hem nooit aanraakte (Roll-Up Summary Field (opens in a new tab) waarschuwt dat validatiefouten op het detail of op de master kunnen verschijnen). Elk van die opslagacties komt je nieuwe regel tegen. Vraag dus bij elke nieuwe regel: moet deze regel gelden voor die opslag?

Dit zijn de keuzes, en je verwerkt ze in de regel:

• Altijd, bij elke opslag. Juist als de regel echt over het record gaat en de oude data slaagt. Maar weet wat “elke opslag” betekent: een batchjob die alleen de eigenaar verandert, of elke kleine bewerking van welk veld dan ook op het record, moet er ook doorheen.
• Alleen voor nieuwe records, met ISNEW(). De regel controleert het record één keer, bij het aanmaken, en nooit meer. Het verleden blijft zoals het was, maar de toekomst ook: een latere bewerking kan een nieuw record de regel laten overtreden en niemand houdt het tegen. Als dat ertoe doet, combineer het dan met de volgende.
• Alleen als de velden waar het om gaat veranderen, met ISCHANGED(). Het telefoonnummer bewerken maakt de regel voor de levertijd niet wakker.
• Niet voor bepaalde schrijvers. Een aangepaste machtiging (custom permission), in de formule gecontroleerd als $Permission, laat de integratiegebruiker of een datamigratie door terwijl mensen nog steeds aan de regel moeten voldoen (How to Reference a Custom Permission in a Validation Rule (opens in a new tab), Engels). Geef haar bewust en aan weinigen.
• Vanaf een datum, door CreatedDate te vergelijken met de dag waarop de regel live ging, als “nieuw” betekent “sinds we dit afdwingen”. Anders dan ISNEW() blijft dit die records controleren bij elke latere opslag, dus dezelfde waarschuwing geldt: een kleine wijziging, zoals een eigenaarsupdate in batch, kan mislukken op een record dat is afgedreven.

Een regel toevoegen aan records die je al hebt? Denk de gevolgen door voordat je hem aanzet. Elk bestaand record moet er nu bij de volgende opslag aan voldoen, en die opslag kan komen van een plek die je niet verwachtte: een nachtelijke integratie, een eigenaarswissel in batch, een samenvattingsveld, een massa-update vanuit een lijstweergave. Welke daarvan gaan hem raken, en wat gebeurt er met die job als één record faalt? De sectie Voordat je haar aanzet heeft de volgorde die ik gebruik.

Herschrijf de geschiedenis niet om de regel tevreden te stellen

En de twintigduizend oude records? Als de data verkeerd is en je de juiste waarden kent, corrigeer haar. Maar ik heb een ander soort “oplossing” gezien: niemand kent de historische waarheid, ze willen alleen dat de records erdoor komen, dus werken ze ze bij met waarden die aan de regel van vandaag voldoen. Daar hou ik niet van. Oude records bijwerken zodat ze voldoen verandert LastModifiedDate en vernietigt belangrijke historische informatie, en waarden verzinnen betekent doen alsof we iets over het verleden weten wat we niet weten. Geef de regel een uitzondering voor records van vóór de regel in plaats van de geschiedenis te herschrijven. Het kan lelijk zijn, maar het is eerlijk.

UI-validatie is geen datavalidatie

Maak een veld verplicht op een page layout en gebruikers kunnen niet opslaan zonder het. Dan voegt de nachtelijke integratie 50.000 records in. Gebruikte die jouw pagina? Nee. De bulkload, de API-client en de agent ook niet. Een eis in de UI beschermt dat scherm, niet de data. Veldvalidatie op dynamic forms kan op dezelfde manier ontweken worden. Vraag dus: waar kan deze data binnenkomen? Lightning, het portaal, mobiel, de integratie, de API, een bulkload, Flow, Apex, een agent. Hoe meer deuren er zijn, hoe minder ik een regel vertrouw die er maar één bewaakt.

Sport vier: duplicaatregels

Nu gaan we van consistentie binnen een record naar consistentie tussen records. Acme Corporation, ACME Corp, Acme Inc.: vier klanten of één? Geen veldregel kan dat beantwoorden. Overeenkomstregels (matching rules) bepalen hoe records worden vergeleken; duplicaatregels bepalen wat er gebeurt als een waarschijnlijk duplicaat gevonden wordt: toestaan met een waarschuwing, blokkeren of rapporteren. Je kunt tot vijf actieve duplicaatregels per object hebben en tot drie overeenkomstregels in elk, en matchsleutels beperken elke vergelijking tot de 100 meest waarschijnlijke duplicaten (Things to Know About Duplicate Rules (opens in a new tab), Engels).

Hun prijs is frictie. Als elke account die een verkoper aanmaakt Possible duplicate found zegt, is dat soms precies wat je wilt, en soms leren mensen erdoorheen te klikken zonder te lezen. Legitieme records kunnen op elkaar lijken, en een integratie heeft misschien ander gedrag nodig dan een persoon. En de waarschuwing is van Salesforce zelf: de melding en de lijst met mogelijke duplicaten passen misschien niet in een eigen scherm dat je gebouwd hebt, en als de opslag headless is, een integratie, een dataload, een agent, is er helemaal geen scherm om hem op te tonen. Beslis dus hoe een duplicaat op elk pad naar boven komt: een waarschuwing voor een persoon, een geblokkeerde opslag en een foutmelding voor de API, of de optie Report en duplicate record sets die iemand later beoordeelt. Goede architectuur is geen maximale handhaving; het is de juiste handhaving.

En controleer welke deuren een duplicaatregel echt bewaakt (Things to Know About Duplicate Rules (opens in a new tab), Engels). Via de API en de data-importtools ziet niemand de waarschuwing: een regel die op waarschuwen staat, blokkeert de opslag gewoon. Sommige paden slaan de regels helemaal over: Quick Create, de knop Undelete, een handmatige samenvoeging, records die Lightning Sync of Einstein Activity Capture toevoegt. En records die op hetzelfde moment opgeslagen worden, worden niet met elkaar vergeleken, alleen met records die al in Salesforce staan. Laad een bestand met dezelfde klant er twee keer in, en beide rijen kunnen erdoor komen. Een duplicaatregel is een goed net. Het is geen slot op de deur.

Examenkennis. Duplicaatregels vergelijken records die op hetzelfde moment worden opgeslagen niet met elkaar, alleen met records die al in Salesforce staan. Via de API en de importtools is er geen waarschuwing: een duplicaat dat de regel vangt, wordt gewoon niet opgeslagen. En een opslag met alles wat die in gang zet, draait als één transactie: als een deel faalt, wordt alles teruggedraaid.

Eén grens. Duplicaatregels houden één org schoon. Ze lossen identiteit op organisatieniveau niet op. Als Salesforce Acme Corporation heeft, het ERP ACME-10382 en de facturering klant 77193, kan een duplicaatregel je niet vertellen dat dat hetzelfde bedrijf is. Dat zijn stamgegevens, hoofdstuk 6.

Sport vijf: automatisering

Sommige regels zijn te complex voor de lagere sporten: ze hebben gerelateerde records nodig, een ander systeem, afhankelijke records, een proces in meerdere stappen. Dat is Flow, Apex, soms integratielogica. (Niet Workflow Rules of Process Builder; die worden niet meer ondersteund.) Automatisering is krachtig en duurder: meer bewegende delen, meer testen, meer foutafhandeling, meer manieren waarop de ene automatisering over de andere struikelt. En code brengt haar eigen fouten mee. Als het veldtype het kan afdwingen, schrijf ik geen Apex. Als een validatieregel het duidelijk zegt, bouw ik geen flow omdat Flow er nu eenmaal is. Los een veldprobleem niet op met een procesmotor.

Alles of niets: als records samen veranderen

Tot nu toe beschermt elke sport één opslag. Maar records veranderen samen: een levering en haar items, een order en zijn regels, een flow die drie objecten bijwerkt. Hier geeft het platform je een sterke garantie. Een opslag en alles wat die in gang zet, de triggers, de flows, de klassen die ze aanroepen, draaien als één transactie: als een deel faalt, wordt het geheel teruggedraaid en wordt er niets vastgelegd (Apex Transactions (opens in a new tab), Engels). Je krijgt geen halve levering.

Bulkwerk is de uitzondering die je zelf kiest. Een dataload of een Apex-Database-methode kan gedeeltelijk succes toestaan: de goede records worden opgeslagen, de slechte komen terug met hun fouten, en iemand moet ermee aan de slag (DML Statements vs. Database Class Methods (opens in a new tab), Engels). Dat is vaak goed voor een load van een miljoen rijen, maar dan is consistentie een proces: wie leest het foutenbestand, en wat gebeurt er met de records die faalden?

En dan is er de timing. Twee opslagacties op hetzelfde moment kunnen allebei door een controle komen waar elk afzonderlijk op zou falen. Een flow die naar een bestaande order zoekt en er dan een aanmaakt, kan er twee doorlaten, en we zagen net dat duplicaatregels records die tegelijk worden opgeslagen niet vergelijken. Een veld dat als Unique gemarkeerd is, of een externe ID, wordt bij elke opslag door het platform gecontroleerd, dus maar één van de twee wint. Dat is nog een reden om uniciteit omlaag te duwen naar het veld. Locks, contentie en nieuwe pogingen zijn een onderwerp op zich; hoofdstuk 11, Transacties, gelijktijdigheid en betrouwbaarheid, gaat er diep op in.

Duw de regel omlaag, tot ze daar niet thuishoort

“Zo laag als redelijkerwijs kan” betekent niet “altijd het laagst”. Als een veld pas verplicht is zodra een verkoopkans een bepaalde fase bereikt, is het verplicht maken in het schema verkeerd; de regel is voorwaardelijk, dus een validatieregel is de juiste sport. Als een duplicaat een persoon moet waarschuwen maar een goedgekeurde integratie een eigen reconciliatie heeft, ontwerp dan voor beide paden. Het doel: de laagste laag die de bedrijfsregel correct weergeeft.

Elke laag heeft een prijs

Click to enlarge

Dit is de afweging die ik je wil laten zien. Veldtypen en gecontroleerde waarden zijn simpel en sterk, maar alleen voor wat een veld kan uitdrukken. Verplicht en uniek zijn grof: eenmaal aan moet elke schrijfactie eraan voldoen. Validatieregels drukken rijkere voorwaarden uit, maar kunnen bewerkingen van oude records blokkeren en een deployment verrassen. Duplicaatregels beschermen over records heen, maar geven frictie voor gebruikers en integraties. Automatisering kan alles aan, maar maakt je eigenaar van orkestratie, fouten, tests en prestaties. Er is geen gratis laag. Kies de laag van elke regel in de wetenschap hoe ze faalt.

Voordat je haar aanzet

Een regel toevoegen aan een bestaande org is een uitrol, geen vinkje. Hoeveel records overtreden haar vandaag, en waarom? Zijn ze echt fout? Kunnen we de juiste waarde weten? Is de regel historisch waar, of pas vanaf nu? Welke integraties, tests en automatiseringen gaan haar raken? Een goede volgorde: meten, opschonen wat aantoonbaar fout is, de regel afbakenen, een bewuste uitzondering toevoegen voor legitieme historie, elk schrijfpad testen, en dan afdwingen. Meten en opschonen zijn disciplines op zich, profilering, standaardisatie, monitoring, stewardship, en hoofdstuk 5, Datakwaliteit en governance, behandelt ze. Veel beter dan op vrijdag een vinkje zetten en de gevolgen op zaterdagavond ontdekken.

Voorbij het examen: wat AI verandert. Een agent kan sneller records maken dan welke persoon ook, en slechte records net zo snel. “Gebruikers weten dat ze dat niet moeten doen” is geen bescherming als de gebruiker een agent is. Zet de belangrijke regels in de datalaag, waar elke schrijver ze tegenkomt, zodat de agent de ongeschreven regels van het bedrijf niet hoeft te onthouden.

Steve Trucking: bescherm de levering

Neem een levering. Haar status komt uit één woordenlijst: een keuzelijst, beperkt. De orderreferentie van de retailpartner moet uniek zijn per partner, dus het is een externe ID, gemarkeerd als uniek, gebruikt om de vrachtlijst te upserten. Het werkelijke bezorgtijdstip is verplicht zodra de status Delivered is: een validatieregel, beperkt tot die wijziging. Een installatiestop kan pas worden afgesloten als de checklist compleet is en de verplichte foto’s zijn gemaakt (bij een vaatwasser de wateraanvoer, de afvoer en de waterpas): een validatieregel, of automatisering als die de foto’s moet controleren die buiten het platform staan. Dezelfde order die twee keer binnenkomt via een opnieuw verstuurde vrachtlijst wordt door de externe ID opgevangen; twee verschillende orders die op elkaar lijken zijn een vraag voor matching.

Merk op dat ik niet zei “zet ze allemaal in een flow”. Elke regel staat op zijn eigen sport. Vraag bij elke regel: wat is de laagste laag die dit correct afdwingt voor elk schrijfpad dat ertoe doet?

Wat een architect hier beslist

• Op welke sport elke regel hoort: veldtype, gecontroleerde woordenlijst, verplicht of uniek, validatieregel, duplicaatregel of automatisering.
• Welke schrijfpaden beschermd moeten worden: UI, portaal, mobiel, integraties, bulkloads, API’s, automatisering en agents.
• Of een nieuwe regel geldt voor historische records, of beperkt wordt tot nieuwe en gewijzigde data met een uitzondering voor het verleden.
• Of bestaande slechte data op basis van bewijs gecorrigeerd kan worden, in plaats van herschreven zodat ze erdoor komt.
• Hoeveel frictie, complexiteit en onderhoud een regel waard is.

Schone data komt niet van mensen vragen goede data in te voeren. Ze komt van een architectuur die het juiste makkelijk maakt, het verkeerde moeilijk, en de belangrijke regels moeilijk te omzeilen. Hierna zetten we het hoofdstuk in elkaar op een uitsnede van Steve Trucking.

Verder lezen

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) en Roll-Up Summary Field (opens in a new tab) (Engels, gecontroleerd op 2026-10-13)
• Salesforce Help, Picklist Limitations (opens in a new tab) (Engels, gecontroleerd op 2026-10-02)
• Salesforce Help, Validation Rule Considerations (opens in a new tab) (Engels, gecontroleerd op 2026-10-02)
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (Engels, gecontroleerd op 2026-10-13): de limieten, de paden waarop regels niet draaien, opslag via API en import geblokkeerd zonder waarschuwing, gelijktijdige opslag niet vergeleken.
• Apex Developer Guide, Apex Transactions (opens in a new tab) en DML Statements vs. Database Class Methods (opens in a new tab) (Engels, gecontroleerd op 2026-10-13): één transactie wordt als geheel teruggedraaid; Database-methoden kunnen gedeeltelijk succes toestaan.
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab) (Engels, gecontroleerd op 2026-10-02)