Get Started Free A Validation Rule in Salesforce is a formula that blocks a record from being saved when its data does not meet defined business rules. It evaluates one or more fields and returns TRUE or FALSE. If the formula returns TRUE, Salesforce blocks the save and displays a custom error message. Validation Rules apply to records saved through the user interface, API operations, Data Loader, and most integrations. They don’t support a warning-only mode.
You’ll meet this term whenever a Salesforce admin needs to enforce data quality at the source: blocking past dates, requiring approval flags above a discount threshold, validating phone number format, or making fields conditionally required.
PRACTICAL EXAMPLE
An Opportunity Close Date should always be today or in the future. The admin creates a Validation Rule on the Opportunity object with the formula:
AND(ISCHANGED(CloseDate), CloseDate < TODAY())
and the error message:
“Close Date cannot be in the past. Pick today or a future date.”
The ISCHANGED function limits the rule to transactions where the Close Date is updated. Existing Opportunities with past Close Dates can still be edited unless the Close Date itself is changed.
Quick facts
-
Fires on every save path: UI edits, API calls, Data Loader, XL-Connector, integrations, Apex DML (lead conversion only counts if “Require Validation for Converted Leads” is on) . A common failure pattern: a rule works fine for manual edits in production, then a scheduled integration pushes records and many fail because they don’t meet the rule’s criteria.
-
Evaluate changes made by before-save flows and before triggers: if automation writes a value that conflicts with the rule, users get blocked from saving even when they aren’t editing that field directly.
-
Inverse logic: validation rule formulas describe “the bad state” to prevent, not the good state to allow. Beginners often write formulas that allow exactly what they meant to block.
-
Formulas are case-sensitive by default: Status = “Closed” does not match “closed” or “CLOSED”. Use UPPER() or LOWER() to normalize text before comparing. A frequent source of silent rule failures on picklist and text fields. For picklists, use ISPICKVAL() or TEXT() as appropriate.
-
Bypass via Custom Permission: reference NOT($Permission.Bypass_RuleName__c) in the formula, then assign the permission through a Permission Set for data migrations or admin overrides.
-
Scoped to one object: rules can reference parent fields via dot notation (Account.Industry from Opportunity), but not child object data.
Note
Activating a Validation Rule too early in a record’s lifecycle backfires. If users hit the rule before they have the data to satisfy it, they may enter junk values just to clear the block. Confirm the required data is actually available at the moment of save before activating the rule in production.
Read how to manage Salesforce validation rules with XL-Connector
FAQ
Can we bypass validation rules in Salesforce?
Yes, through a Custom Permission. Create the permission in Setup, reference it in the formula with NOT($Permission.Bypass_RuleName__c), and assign it through a Permission Set. Standard for data migrations, admin overrides, and integration users.
How many validation rules can an object have in Salesforce?
Limits vary by edition: Enterprise and Developer Editions support up to 100 active rules per object, while Unlimited and Performance Editions support up to 500 active rules per object.
When do validation rules fire in Salesforce?
On every save: UI edits, API, Data Loader, integrations, Apex DML, Flow record-triggered actions. They evaluate changes made by before-save flows and before triggers and run before the database commit. They do not fire on undelete operations.
Where do I find validation rules in Salesforce?
Setup, then Object Manager, select the object, click Validation Rules in the left sidebar.
