Validation and Verification in Salesforce

What do Salesforce Validation Rules check?

Controlling duplicates is one way to protect data quality. Validation Rules are Salesforce's other native, no-cost tool for the job: a rule checks that data entered by a user meets a specific standard before the record can save — a required name field, for instance. Admins write these as yes/no statements; if the criteria aren't met, an error message stops the save until the record is fixed.

It's a simple mechanism, and it covers a lot of an organization's basic needs on its own.

How a validation rule is built

• Rule criteria — a logical, formula-like expression that decides whether the data is valid. For example: if the name field is empty, block the save.
• Error message — a customizable message shown when the criteria fail, telling the user what to fix.

Common applications:

• Requiring fields to be filled out.
• Validating formats — phone numbers, email addresses.
• Enforcing business logic, like requiring a close date to be in the future.

Where it's used in practice:

• Spotting recurring data-entry mistakes and writing a rule to block them.
• Translating a business process into an enforceable rule.

How to test a validation rule properly

A rule that's too strict blocks legitimate work; one that's too loose lets the bad data back in. Before rolling one out:

1. Understand the requirement driving the rule, and what should happen when it triggers.
2. Write test scenarios covering both the cases that should pass and the ones that should fail.
3. Use realistic sample data that covers the different conditions the rule checks.
4. Test both directions — data that should be blocked, and data that shouldn't.
5. Test across user profiles, since permissions can change how a rule behaves.
6. Test across record types if your org uses more than one.
7. Check the error message is clear enough to tell a user how to fix the problem.
8. Test on bulk data, not just single records — a rule that's fine one record at a time can still slow down a bulk load.
9. Run regression tests whenever the rule or the org's configuration changes.
10. Use the Developer Console to simulate the rule against test records before it goes live.
11. Document the test cases so the next person doesn't have to reconstruct them.
12. Check the audit trail after testing to confirm which rules actually fired.
13. Balance strictness against flexibility — too many rules, or rules that are too strict, slow down the people who have to use the org every day.

Where do validation rules fall short?

Data validation ranges from a simple format check on an email address to a rule spanning several conditions and dependent fields, like geocodes. Salesforce's native validation covers a good share of that range, but not all of it.

• No cross-record verification. A validation rule checks one record at a time; it can't compare data across multiple objects. That needs an Apex trigger instead.
• Skipped during some processes. Lead conversion is the clearest example — validation may not apply uniformly, and some steps of the conversion can skip it.
• Silent in certain scenarios. Campaign hierarchy changes and mass ownership transfers are two places where rules simply don't trigger.
• Bypassed during mass record changes. Tools like Mass Transfer change ownership on many records at once, and validation rules typically only fire when records are edited individually.

Used well, validation rules are genuinely useful for enforcing business logic and catching common entry mistakes — the testing steps above are how you keep them that way. But they have real edges: no cross-record checks, gaps during lead conversion, and blind spots during mass changes. Where those edges matter, Apex triggers or a dedicated tool pick up what the native rules can't reach.

The next chapter turns to the wider set of challenges Salesforce administrators run into while trying to keep their data reliable.