Salesforce Validation Rule Examples: 8 Worth Building

Most lists of Salesforce validation rule examples are lists of required fields. Phone can’t be blank. Industry can’t be blank. Next Step can’t be blank. Reps learn within a week that “TBD” gets them past all three, and the org ends up with full fields and no information.

My position: the validation rules worth building don’t check whether a field has something in it. They check whether a change makes sense. A deal moving backwards out of Closed Won. A close date being pushed into last month. A value someone set on purpose getting quietly erased. Those are the saves that damage your data, and a formula can catch every one of them.

Here are eight, with formulas you can adapt. Field API names are examples; swap in your own.

1. Close dates can’t be moved into the past

The naive version is CloseDate < TODAY(). It works for a day, then it blocks every rep from editing any open deal whose date has already lapsed, including the edit that would fix it.

Only check the date when it’s actually being set:

AND(
  NOT(IsClosed),
  CloseDate < TODAY(),
  OR(ISNEW(), ISCHANGED(CloseDate))
)

Old records stay editable. New bad dates don’t get in. If stale dates are already piling up, that’s a reporting job, not a validation job; the pipeline hygiene checks cover flagging them.

2. Closed deals stay closed

A won deal that drifts back to Negotiation rewrites last quarter’s numbers without anyone noticing. Reopening should be possible, but only for people whose job includes it.

AND(
  ISCHANGED(StageName),
  OR(
    ISPICKVAL(PRIORVALUE(StageName), "Closed Won"),
    ISPICKVAL(PRIORVALUE(StageName), "Closed Lost")
  ),
  NOT($Permission.Reopen_Closed_Deals)
)

PRIORVALUE is the function that makes most good rules possible. It lets the formula compare the record as it was with the record as it’s about to be, which is where the interesting mistakes live.

3. A value, once set, can’t be cleared

Lead Source is the classic. Marketing sets it, someone tidies the record six months later, and attribution disappears. Salesforce’s own Trailhead module uses exactly this pattern:

AND(
  NOT(ISBLANK(TEXT(PRIORVALUE(LeadSource)))),
  ISBLANK(TEXT(LeadSource))
)

Picklists need the TEXT() wrapper before ISBLANK will work on them. The rule allows changing the value. It only blocks erasing it, which is the edit that’s almost never intentional.

4. Closed Lost needs a reason from a list

“Required on Closed Lost” is the right instinct with the wrong field type. A required text box gets “lost”, “n/a”, and a single period. A required picklist gets data you can report on.

AND(
  ISPICKVAL(StageName, "Closed Lost"),
  ISBLANK(TEXT(Loss_Reason__c))
)

Keep the picklist short enough that reps can pick honestly in five seconds. Add a free-text detail field next to it if you want color, and don’t make that one required.

5. Formats that downstream systems depend on

Anything that leaves Salesforce, whether it’s a postal code your shipping tool parses or an ID your billing system matches on, should be checked before it saves. REGEX handles this:

AND(
  ISPICKVAL(BillingCountryCode, "US"),
  NOT(ISBLANK(BillingPostalCode)),
  NOT(REGEX(BillingPostalCode, "\\d{5}(-\\d{4})?"))
)

BillingCountryCode assumes State and Country picklists are enabled; otherwise test the text BillingCountry field. The country condition matters. A US-only pattern applied to every account will reject valid addresses everywhere else. If a field like this is causing sync failures today, it’s worth reading how to catch integration errors before customers do alongside it.

6. Discounts past a threshold need a sign-off

Discount policy usually lives in a slide deck. It can live on the record:

AND(
  Discount_Percent__c > 0.20,
  NOT(Discount_Approved__c)
)

Percent fields evaluate as decimals in formulas, so 20% is 0.20. The rule doesn’t do the approving. It makes sure nothing over the line saves without someone having approved it. If the sign-off itself is more complicated than one checkbox, that’s the territory covered in approvals beyond Flow.

7. Ownership changes go through the right people

Account owners decide commission, territory and who gets the call. Letting anyone reassign them is how accounts migrate toward whoever edits records most.

AND(
  ISCHANGED(OwnerId),
  NOT(ISNEW()),
  NOT($Permission.Reassign_Accounts)
)

If reassignments happen in volume, a validation rule isn’t the whole answer; territory assignment is a build of its own. But this one rule stops the quiet, one-at-a-time drift.

8. Every rule gets a bypass, and the bypass is a permission

Notice that several rules above check $Permission. That’s deliberate, and it’s the most important item on the list.

Sooner or later you’ll need to load historical data, fix records in bulk, or let an integration write values your rules would reject. Trailhead’s validation rule bypass unit recommends a custom permission assigned through a permission set, checked in the rule with NOT($Permission.Your_Bypass_Name), and suggests a session-based permission set when you want the bypass switched on only while it’s needed.

The alternative people reach for, $Profile.Name <> "System Administrator", ties your data rules to a profile name. Rename the profile or give a data-load user a different one and every rule changes behavior. A permission you assign on purpose is easier to reason about. If you’re importing with the Data Import Wizard, this is the difference between a clean load and an error file of rejected rows.

Where validation rules stop

Validation rules are good at one record at a time. They can see the fields on the record being saved and on parent records above it. They can’t count what hangs underneath, so “can’t move to Proposal without a contact role” or “can’t close without an attached quote” is out of reach for a formula alone. Those need a roll-up field to check against (even when Salesforce won’t give you one) or a small piece of code. The Flow vs. Apex breakdown covers where that line falls.

Timing matters too. In Salesforce’s order of execution, custom validation rules run after before-save flows and before triggers, and before duplicate rules. That means a before-save flow can fill in a value your rule then checks. It also means custom validation rules aren’t rerun after a workflow field update, so a value set that late never gets validated. Duplicate checks are a separate layer; duplicate rules that fit your data are their own build.

Treat rules like code, because they behave like it

A validation rule deployed straight to production takes effect on the next save. A badly written one can block every rep from editing opportunities in the middle of a quarter-end push. The fix is boring: write the rule in a sandbox, try it against records that should pass and records that should fail, write an error message that tells the user what to do instead of what they did wrong, and only then promote it.

This is the kind of work an AI can do well once it can actually work in your org. You describe the rule in a sentence (“deals can’t move back out of Closed unless you’re in RevOps”) and the AI writes the formula, the custom permission, the permission set, and a handful of test records that prove it behaves. With Sentinel, Salesforce deploys go to a sandbox first with tests required, every change is logged, and a snapshot is taken before each deploy. That doesn’t promise the AI never writes a bad rule. It means you can see exactly what changed and roll it back when one slips through. For the deploy side, the change sets vs. Metadata API comparison explains why rules belong in files, not clicks.

Pricing is flat per Sentinel and is covered on a short demo call.

The takeaway

Required fields measure whether someone typed. Good validation rules measure whether a change makes sense: transitions, erasures, formats, thresholds, ownership. Build those eight, give every one a permission-based bypass, and push the cross-record checks to the tools that can see related records.

Want your AI writing and shipping these rules in your org this week? Book a Demo Call and we’ll walk through what it would build first.