Validation rules improve data quality without frustrating users when each rule guards one business moment. It should fire only when the relevant field changes, and say exactly what to fix beside that field. Pair every rule with a bypass for integrations and data loads. Test rules against existing records before activation. Push simple requirements into required fields and picklists instead.
What are validation rules good for, and what belongs somewhere else?
A validation rule is a formula that blocks a save when it evaluates to true. Use it for conditional logic that simpler controls cannot express.
Most frustration comes from rules doing a job another feature does better. Before writing a formula, walk down this ladder and stop at the first control that fits.
- Always required, everywhere: make the field required. Universal required fields also block API and import saves, so reserve them for values every source can supply.
- Limited set of allowed values: use a restricted picklist rather than free text plus a rule.
- Allowed values depend on another field: use a dependent picklist, which guides the user instead of rejecting them.
- Likely duplicate records: use matching and duplicate rules, which can warn rather than block.
- Value can be calculated or defaulted: set it in a before-save flow or a formula field, and stop asking people to type it.
- Requirement depends on stage, status, record type or another field: this is where a validation rule earns its place.
Which validation rule patterns cover most business needs?
Five patterns handle the bulk of real requirements. The table shows each one, a typical need, a gentler option where one exists, and the trap to avoid.
| Rule pattern | Example business need | Safer alternative, if any | Pitfall |
|---|---|---|---|
| Stage-gated requirement | Next Step and Decision Maker must be filled before an opportunity reaches Proposal | Path guidance plus a report of gaps, if coaching is enough | Firing on every edit of an old deal, not only when the stage moves |
| Format check | Tax ID or postal code matches an agreed pattern | Restricted picklist or a lookup to a reference object | Pattern written for one country rejects valid foreign data |
| Cross-field consistency | Discount above a threshold needs a reason code | Dependent picklist when one value drives another | Rule and a flow both writing the same fields, causing confusing failures |
| Preventing backdating | Close date on an open deal cannot be moved into the past | None that is as reliable | Blocking edits to historic records nobody is changing |
| Locking after a status | Contract fields cannot change once status is Activated | Read-only fields on a status-specific Lightning page | Locking out the finance user who must correct a real error |
Conceptually, a stage gate says: the stage changed, the new stage is at or past Proposal, and the required field is blank. A backdating rule says: the deal is open, the close date changed, and the new date is earlier than today. Short formulas make this concrete.
- AND(ISCHANGED(StageName), ISPICKVAL(StageName, "Proposal/Price Quote"), ISBLANK(NextStep)) blocks the move to that stage without a next step.
- AND(ISCHANGED(Status), ISPICKVAL(PRIORVALUE(Status), "Activated")) stops anyone moving a contract out of Activated.
- NOT(REGEX(Tax_ID__c, "[0-9]{2}-[0-9]{7}")) checks a nine-digit tax ID with a hyphen. Add an ISBLANK guard if the field is optional.
ISCHANGED and PRIORVALUE are the most useful functions here. They make a rule react to an edit rather than to the record's whole history. Field names above are illustrative; check the API names and picklist values in your own org.
How do you write error messages users actually understand?
State what is wrong, why it matters and how to fix it, in plain words. Then show the message beside the field the user must change.
- Name the field by its label and say the valid action: "Add a Decision Maker before moving to Proposal."
- Explain the reason in a short clause when it is not obvious, such as finance needing it for invoicing.
- Set the error location to the field, not the top of the page. Salesforce falls back to the page level if that field is hidden, read-only or deleted.
- Never write "Invalid entry" or quote the formula. A rep cannot act on either.
- Translate messages through Translation Workbench if your users work in several languages.
How should integrations, data loads and admins bypass rules?
Give each rule a single, consistent exception that a permission or setting controls. Never hard-code individual users or profile names into formulas.
The common approach is a custom permission, for example Bypass Validation Rules, granted through a permission set. Each formula then includes NOT($Permission.Bypass_Validation_Rules). Assign the permission set to the integration user and the data migration user. Assign it to admins only when they are loading data, and remove it afterward.
Checking $Profile.Name works, but it ties logic to profile names that change and cannot be granted temporarily. Some teams prefer a hierarchy custom setting with a checkbox per user or profile. That lets them toggle bypass at org level during a large load. Either way, document who holds the bypass and review that list on a schedule.
Where do validation rules fall in the order of execution?
Before-save flows run first, then Apex before triggers, then custom validation rules. So a rule checks the values your automation already set, not only what the user typed.
That ordering has practical effects. A before-save flow can fill a missing value and quietly satisfy a rule. If a flow sets a bad value, the rule rejects the whole save, and the user sees an error about a field they never touched.
After-save flows and Apex that update other records start new saves on those records, and their validation rules apply. A failure usually rolls back the entire transaction, including the user's original edit. Screen flows surface the error unless a fault path handles it. Workflow field updates are the documented exception: custom validation rules do not run again after them. Confirm details for your org in the Salesforce order of execution documentation.
When a flow update keeps tripping a rule, fix one side. Either set valid values in the flow, add the bypass to the running user, or narrow the rule so it ignores system-driven changes.
How do you test a validation rule before it reaches users?
Try each rule in a sandbox against realistic records, then measure how many existing records would fail. Rules apply to old records the next time anyone edits them.
- Write test cases for the pass path, the fail path and the bypass user, including an API save.
- Run a report or query that mirrors the formula to count non-compliant existing records.
- Decide whether to clean those records first, exempt them by date, or accept that the next editor must fix them.
- Test with the integration user and a sample import, not only the UI.
- Check lead conversion. Validation on converted records runs only if Require Validation for Converted Leads is enabled in Lead Settings.
Some mass-update tools may not run validation rules, so test each tool you rely on. Do not rely on rules alone where those tools are used.
What limits should you know about?
Active validation rules per object are capped by edition. The cap differs by edition, so check the current figure for yours in Salesforce Help.
If you are near it, that usually signals rules worth consolidating, so ask your account team about options. Allocations change between releases, so confirm current figures with your Salesforce account team. Long before any cap, though, users feel the friction of dozens of rules on one object. Formula size and compile limits also apply to complex rules, which is a reason to keep each one narrow.
How should rules be named and documented?
Name each rule so the object, purpose and trigger point are readable in a list. Put the business owner and reason in the description.
- A pattern such as OPP_Proposal_Requires_NextStep reads clearly in setup and in deployment tools.
- Description: the business need, who asked for it, when it was added and which bypass applies.
- Keep one rule per condition. Combined rules produce messages that cannot say which part failed.
- Record each rule in your org documentation alongside the flows that touch the same fields.
How do you know which rules fire most and still matter?
Salesforce has no built-in counter for validation rule failures. You need a workaround, and every option is approximate.
Some teams log errors from integrations and import results, which name the failing rule. Others build a report that reproduces each formula against current records. Debug logs show rules evaluating but are not a practical counting tool. Asking reps in a short survey which errors they hit most is a cheap way to fill the gaps.
Review rules on a regular cadence. Retire any rule whose business owner has left, whose process changed, or that forces placeholder values. A rule people type around is worse than no rule.
Where have we applied validation rules in real projects?
On a Sales Cloud launch for a technology consultancy, industry segmentation fields came with validation rules for data integrity. That gave segmented marketing a dependable base. For a broker-dealer, stage-based workflows used validation rules to enforce compliance before deals went to market. In both, the rules followed a defined process rather than preceding it.
What does a phase-one validation rule plan look like?
Start small and measured. A handful of well-built rules beats a broad rollout that teaches users to work around the system.
- Inventory existing rules, owners and failure points, then retire or merge the weak ones.
- Create the custom permission and permission set for bypass, and assign them to integration and migration users.
- Pick three to five high-value rules, usually stage gates and backdating, and write their messages with the people who will see them.
- Test in a sandbox, count non-compliant records, and plan the cleanup.
- Release with a short note to users, then review errors and feedback after go-live.
- Add later rules one at a time, using the same review.
If your org already has rules nobody understands, our optimization team can review them as part of a wider configuration check.
