Validation Rule
A Validation Rule in Salesforce is a formula that the platform evaluates every time a user saves a record.
Definition
A Validation Rule in Salesforce is a formula that the platform evaluates every time a user saves a record. If the formula returns true, the save fails and the rule's error message displays to the user. Validation Rules are how Salesforce admins enforce data quality at the record-save layer: the rule checks that required-conditional fields are populated, that date relationships make sense, that picklist values are consistent, that custom business logic holds. Every object in Salesforce can have its own set of Validation Rules, and each rule runs independently on save.
Validation Rules sit at one end of the data-quality enforcement spectrum, with Required-on-Page-Layout at the other. Required fields fire a simple "this field is blank" error; Validation Rules fire on any condition you can express in a formula, which means almost anything a record could violate. The cost of that flexibility is performance and maintenance: each Validation Rule adds save-time work, and a record save that fails a Validation Rule produces an error that needs to be readable enough for the user to fix the underlying issue. Orgs that accumulate fifty Validation Rules per object usually find half of them firing on edge cases nobody anticipated.
How Validation Rules enforce data quality at save time
How Validation Rules evaluate
A Validation Rule's formula returns either true (block the save) or false (allow the save). The formula has access to every field on the current record plus a set of global variables ($User, $Profile, $Organization, $Setup, $Permission) and standard functions (ISBLANK, ISNUMERIC, TODAY, ISCHANGED, PRIORVALUE). The platform evaluates every active Validation Rule on the record at save, regardless of which user is saving. If any rule returns true, the save fails immediately and the user sees the configured error message. Other Validation Rules that would also have failed are not evaluated; the platform short-circuits on the first failure.
Common patterns
Most Validation Rules fall into a handful of patterns. Required-conditional rules enforce "this field must be populated if some other condition holds" (e.g., Close Reason required when Stage = Closed Lost). Date-relationship rules enforce ordering between dates (End Date must be after Start Date). Picklist-dependency rules cross-validate two related picklists. Cross-object rules use lookup formulas to check parent-record values from a child record. Field-format rules enforce specific patterns through REGEX or LEN functions. Custom-business-logic rules layer on top of all of these and enforce whatever specific policy your org needs (e.g., Quote Discount cannot exceed 30% unless approved by Sales Ops).
Error messages
The error message a Validation Rule displays matters as much as the formula itself. A good message tells the user exactly what is wrong and how to fix it. "Close Reason is required when Stage = Closed Lost. Pick a reason from the dropdown before saving." reads better than "Validation failed" or "Required field missing." Place the error message on the specific field when possible (Error Location = "Field"), so the error displays inline next to the offending input rather than at the top of the page. Inline errors are far easier to act on than top-of-page errors that the user has to map back to a field manually.
Bypass mechanisms
Some Validation Rules need to apply to most users but not to specific roles or service accounts. The standard bypass pattern uses Custom Permissions: define a Custom Permission like "Bypass Quote Discount Rule," assign it through a Permission Set to the users who can bypass the rule, and reference $Permission.BypassQuoteDiscountRule in the rule's formula. The same pattern works with $User.UserType (to bypass for integration users) or $Setup.CustomMetadata (to bypass during data migrations). Avoid hard-coding profile names in Validation Rules; profile renaming breaks the rule silently, and the error surfaces six months later when nobody remembers the original design.
Performance and limits
Each Validation Rule adds save-time work. The platform evaluates every active Validation Rule on every record save, even on bulk inserts where the same rule runs thousands of times. Most Validation Rules are fast (simple formula evaluation), but cross-object lookups, REGEX patterns, and large IF chains can add visible latency to record saves. The platform caps active Validation Rules at 100 per object, which sounds generous but enterprise orgs hit it regularly. Audit your Validation Rules quarterly, deactivate the ones that no longer fire (use the Setup audit log to see which rules have caught violations in the last 90 days), and consolidate similar rules where possible.
Validation Rule vs Page Layout Required
Both prevent save when a field is blank, but they layer differently. Page Layout Required is per-layout (so a field can be required on the Sales-rep layout but optional on the Service-rep layout); Validation Rules are per-object (the rule applies regardless of which layout the user sees). Page Layout Required produces a generic "this field is required" error; Validation Rules produce a custom message you control. Use Page Layout Required for "this field is always needed for this user type" patterns; use Validation Rules for "this field is needed when some other condition holds" patterns. Mixing the two on the same field can produce confusing UX where the user fixes one error only to hit the next; consolidate to one mechanism per field where possible.
Testing and deployment
Validation Rules are metadata, deployed through change sets, SFDX packages, or the metadata API. Testing them in a sandbox before deploying to production is non-negotiable, because a too-aggressive Validation Rule blocks legitimate saves and produces a flood of support tickets the moment it activates. Production deployment should happen during a quiet period (off-hours, weekend) so users do not hit unexpected save failures during peak work hours. Communicate the new rule and its expected behavior to affected teams before deployment, and have a rollback plan (deactivate the rule in Setup) if it fires on cases you did not anticipate.
How to create a Validation Rule
Creating a Validation Rule is one of the standard data-quality enforcement steps in any Salesforce implementation. The configuration is simple; the design decisions before configuration matter more.
- Open Setup and navigate to the object's Validation Rules
Setup > Object Manager > select the object > Validation Rules. The list shows every existing rule on the object with its Active flag.
- Click New
The New button at the top opens the rule editor. Pick a clear Rule Name (this shows up in error logs and Setup; it stays internal-facing).
- Write the formula
Use the formula editor to express the condition that should block the save. The formula must return true to block. Common starting points: ISBLANK(SomeField), Some_Field__c = "Bad Value", ISCHANGED(Status) && PRIORVALUE(Status) = "Closed".
- Set the error message and location
Write a message that tells the user what to fix. Set Error Location to Field (and pick the specific field) so the error displays inline; only use Top of Page when the rule applies to a combination of fields with no single offending input.
- Test with a sandbox record
Save a record that should pass the rule and confirm it saves; save a record that should fail and confirm the error fires with the expected message.
- Activate the rule
Toggle the Active checkbox to true and save. Activation makes the rule immediately effective on all subsequent record saves.
- Communicate the rule to affected teams
Before deploying to production, tell sales/service/operations teams what the new rule does so they can adjust their data-entry behavior.
- Validation Rules cap at 100 active per object. Audit quarterly and deactivate rules that no longer catch real violations.
- Profile-based bypasses are brittle; use Custom Permissions instead. Profile renaming breaks profile-based rules silently.
- Error Location matters. Inline field errors are far easier for users to act on than top-of-page errors.
- Validation Rules also fire on integration writes by default. Use $User.UserType or a Custom Permission to bypass for service accounts when needed.
Trust & references
Cross-checked against the following references.
- Validation RulesSalesforce Help
- Custom PermissionsSalesforce Help
Straight from the source - Salesforce's reference material on Validation Rule.
- Validation RulesSalesforce Help
Hands-on resources to go deeper on Validation Rule.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Why is understanding Validation Rule important for Salesforce admins?
Q2. In which area of Salesforce would you typically find Validation Rule?
Q3. Can a Salesforce admin configure Validation Rule without writing code?
Discussion
Loading discussion…