Validation Rules for Data Quality

1. Why Validation Rules Matter

Data quality is the foundation of everything a Salesforce org does. Reports, dashboards, forecasts, automation (Flows, approval processes), integrations, and AI features are only as reliable as the data they consume. If a Closed Won Opportunity has no Amount, a Case is closed without a Resolution, or a Billing Country is typed six different ways, downstream analytics and processes break. Validation rules are the primary declarative tool an administrator uses to enforce data standards at the moment of record save, before bad data ever enters the database.

For the Advanced Administrator exam, validation rules sit inside the Data and Analytics Management domain and also surface in Process Automation and Objects & Applications scenarios. Expect scenario-based questions where you must (a) recognize that a validation rule is the correct solution versus a required field, a Flow, a duplicate rule, or Apex, (b) understand exactly when the rule does and does not fire, (c) interpret or troubleshoot a formula, and (d) know how to build bypass logic for integrations or specific users.

2. What a Validation Rule Is

A validation rule is a formula or expression attached to an object that evaluates data entered on a record and returns TRUE or FALSE. The critical concept: when the formula evaluates to TRUE, the record is considered invalid and the save is blocked. The formula therefore describes the error condition, not the desired condition. This inversion is one of the most heavily tested traps on the exam.

Each validation rule contains:
• Rule Name – unique API-style name.
• Active checkbox – only active rules are enforced.
• Description – best practice to document business intent.
• Error Condition Formula – the Boolean expression (maximum 3,900 characters; compiled size limit of 5,000 bytes).
• Error Message – text shown to the user (maximum 255 characters). Should be clear and actionable.
• Error Location – either Top of Page or a specific Field. If you choose a field that is not on the user's page layout, Salesforce displays the error at the top of the page instead.

Validation rules can be created on standard and custom objects, including Activities (Tasks and Events share rules through the Activity object), Campaign Members, Leads, Cases, Opportunities, Opportunity Products, Quotes, and Person Accounts.

3. How Validation Rules Work

3.1 When they fire
Validation rules are evaluated whenever a record is created or edited, regardless of how the save happens: the UI (Lightning or Classic), Data Loader, Data Import Wizard, API calls, Flows (Create/Update Records elements), Apex, Web-to-Lead and Web-to-Case, and mobile. They are not evaluated on record deletion. They apply even if the referenced field is not on the page layout or not included in the API call.

3.2 Order of execution (simplified, exam-relevant)
1. System validation (required fields, field formats, foreign keys).
2. Before-save record-triggered Flows and before triggers.
3. Custom validation rules (plus system validation again).
4. Duplicate rules.
5. Record saved to database (not committed).
6. After triggers.
7. Assignment rules, auto-response rules.
8. Workflow rules (and their field updates; if a field update occurs, before/after triggers and validation may re-fire once).
9. Escalation rules, after-save Flows, entitlement rules.
10. Roll-up summary recalculation on parent, then grandparent.
11. Criteria-based sharing, commit, post-commit logic (emails, outbound messages).

Exam takeaway: validation rules run after before-save automation but before after-save automation and before the record is committed. If a before-save Flow populates a field, the validation rule sees the populated value.

3.3 Known exceptions – when validation rules do NOT run or behave differently
• Mass Transfer tool – validation rules are not run on records transferred in bulk (they still run when ownership is changed on an individual record).
• Lead conversion – validation rules and triggers run on conversion only if Require Validation for Converted Leads is enabled in Lead Settings. If an Activity validation rule fails during conversion, the lead still converts but the activity is not created.
• Campaign hierarchies ignore validation rules.
• Quick Create (Classic sidebar) does not enforce validation rules.
• Workflow and approval process field updates can bypass validation rules in certain configurations – a classic reason to prefer Flow or to design rules defensively.
• Merging records – rules are not enforced on the surviving master record in the same way as a normal edit.
• Deactivated rules and rules on records saved in a Flow with a fault path – the Flow continues down the fault connector rather than showing the user the error.

3.4 Useful formula functions and global variables
• ISBLANK() – preferred over ISNULL (works for text fields). Use NOT(ISBLANK()) to require values conditionally.
• ISPICKVAL(field, "Value") – compare picklist values; or TEXT(picklist) to convert for comparison or concatenation.
• INCLUDES(multiselect, "Value") – for multi-select picklists.
• ISNEW() – TRUE on record creation; use NOT(ISNEW()) to apply only on edits.
• ISCHANGED(field) – TRUE if the field value changed during this save.
• PRIORVALUE(field) – the value before the edit (e.g., prevent reopening a Closed case).
• VLOOKUP(field_to_return, field_on_lookup_object, lookup_value) – available only in validation rules; the lookup field must be the Name field of a custom object. Classic use: validate postal code against state using a custom object.
• REGEX(text, pattern) – enforce formats such as phone numbers, SSNs, or email domains.
• $User, $Profile, $UserRole, $Permission, $Setup – build user-based or custom-permission bypasses.
• RecordType.DeveloperName or RecordType.Name – scope a rule to specific record types (avoid hard-coding record type IDs).
• Cross-object references through lookup/master-detail (e.g., Account.Industry on an Opportunity rule). You cannot reference child records directly.
• $ObjectType and the Owner relationship can be used for owner-based conditions.

3.5 Example formulas
Require Amount when Opportunity is Closed Won:
AND( ISPICKVAL(StageName, "Closed Won"), ISBLANK(Amount) )

Prevent Close Date in the past on new records:
AND( ISNEW(), CloseDate < TODAY() )

Prevent reopening a closed Case except by Support Managers (custom permission bypass):
AND( ISPICKVAL(PRIORVALUE(Status), "Closed"), NOT(ISPICKVAL(Status, "Closed")), NOT($Permission.Reopen_Cases) )

Integration user bypass using a profile check:
AND( ISBLANK(Phone), $Profile.Name <> "Integration Profile" )

Enforce email domain format:
NOT( REGEX(Email, "[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}") )

3.6 Limits worth memorizing
• Active validation rules per object: 500 (Unlimited/Performance), 100 (Enterprise/Developer), 20 (Professional) – the exact tier numbers rarely appear, but know the rule count is per object and that only active rules count.
• Formula: 3,900 characters; 5,000 bytes compiled.
• Error message: 255 characters.
• Cross-object references are limited to 15 unique relationships across the object's formulas and rules (shared with formula fields).

4. Validation Rules versus Other Data Quality Tools

Expect questions that force you to choose the simplest declarative tool:
• Universally required field (field-level) – use when the field must always have a value for every record, every user, every record type, including API. No condition needed.
• Page layout required – only enforced in the UI for that layout; not enforced via API or Data Loader. Wrong answer when the scenario mentions integrations.
• Validation rule – conditional requirements ("when X then Y must be"), format enforcement, state transitions, cross-field logic, date logic, and user/profile-based exceptions.
• Duplicate and matching rules – preventing or alerting on duplicate records; not something a validation rule should attempt.
• Picklists / dependent picklists / restricted picklists – constrain allowed values rather than validating free text.
• Flow – when you need to change data or notify someone, not merely block the save. Flows cannot throw a user-friendly blocking error on a standard record save without a validation rule (though Screen Flows have their own validation).
• Apex trigger – only when logic needs child record aggregation, complex queries, or something formulas cannot express. The exam favors declarative first.

5. Best Practices Tested on the Exam

• Write the formula as the error condition (TRUE = block).
• Always fill in the Description and a user-friendly Error Message that tells the user how to fix the problem.
• Avoid hard-coded IDs; use DeveloperName, custom permissions, custom metadata, or hierarchy custom settings for bypass logic. Custom Permissions assigned via permission sets are the modern bypass pattern because they survive sandbox refreshes and deployments.
• Scope rules with ISNEW(), ISCHANGED(), and record type checks so existing legacy records are not suddenly uneditable.
• Before activating a rule on an object with existing data, run a report or Data Loader export to find records that would already fail, then clean or scope accordingly.
• Test with multiple profiles and through Data Loader, not only the UI.
• Keep rules in sandbox first; deploy through change sets or the Metadata API. Validation rules are metadata and can be deployed with the Active flag set to false for a staged rollout.
• For integrations and mass loads, either use a bypass variable, temporarily deactivate the rule (document the risk), or stage data so it already passes.
• Use Setup Audit Trail to see who created, edited, activated, or deactivated validation rules.
• Remember that a validation rule on the parent does not fire when only a child is edited, even if a roll-up summary on the parent changes (roll-up recalculation happens after validation and does not re-evaluate parent validation rules in the standard save path).

6. Troubleshooting Scenarios

• Users report an error at the top of the page instead of next to the field: the field selected as the Error Location is not on their page layout, or the rule uses Top of Page.
• Rule works in UI but not for a Data Loader job: check that the rule is active in that org/sandbox, and that no $Profile/$User bypass applies to the integration user.
• Rule unexpectedly blocks everyone: usually a logic inversion (wrote the desired condition instead of the error condition) or a missing NOT around ISBLANK.
• Rule fires on records nobody touched: a Flow, workflow field update, or Apex is editing the record; the record's existing data violates the rule. Scope with ISCHANGED or clean data.
• Lead conversion creates Accounts without required data: enable Require Validation for Converted Leads.
• Mass Transfer produced invalid records: expected behavior – Mass Transfer bypasses validation rules.
• Picklist comparison returns no error: used = instead of ISPICKVAL or TEXT(); picklists cannot be compared directly with text without conversion.

7. Exam Tips: Answering Questions on Validation Rules for Data Quality

Tip 1 – Decode the keyword. Words like prevent, require only when, must not, ensure format, block users from, conditionally mandatory almost always point to a validation rule. Words like update, notify, create, assign point to Flow. Words like duplicate point to Duplicate Rules. Always required for every record points to a universally required field.

Tip 2 – Remember TRUE means ERROR. When evaluating formula answer choices, mentally plug in a bad record and confirm the formula returns TRUE. Eliminate options that describe the valid state.

Tip 3 – Watch for the integration or Data Loader clue. If the scenario mentions API, integration, or mass loads, page-layout-required fields are wrong and validation rules (or universally required fields) are right. If the scenario asks how to let the integration bypass the rule, look for $Profile, $User, or $Permission (custom permission) in the formula – not deactivating the rule in production.

Tip 4 – Know the exceptions cold. Mass Transfer, lead conversion without the setting enabled, campaign hierarchies, Quick Create, and deletes do not trigger validation rules. Questions about "invalid records appeared after a bulk owner change" test this directly.

Tip 5 – Place validation rules correctly in order of execution. Before-save Flows and before triggers run first, then validation rules, then after-save automation, then roll-ups. If a question asks why a field set by a before-save Flow still passed validation, it is because validation evaluated the already-populated value.

Tip 6 – Pick the right function. ISPICKVAL for picklists, INCLUDES for multi-select, ISBLANK (not ISNULL) for text, PRIORVALUE for state-transition rules, ISNEW to limit to creation, ISCHANGED to limit to edits of a specific field, VLOOKUP to validate against a custom reference object, REGEX for formats.

Tip 7 – Favor scalable, declarative, maintainable answers. Between two correct-looking options, choose the one that avoids hard-coded IDs, uses custom permissions over profile names, uses a single rule over many, and uses declarative tools over Apex.

Tip 8 – Error Location nuance. If a question says the error appears at the top of the page even though a field was chosen, the answer is that the field is not on that user's page layout.

Tip 9 – Existing data. If activating a new rule will make existing records uneditable, the best practice answer involves cleaning data first or scoping the rule with ISNEW()/ISCHANGED() – not ignoring the problem or deactivating the rule later.

Tip 10 – Eliminate distractors. Common wrong answers include: using a workflow rule or Process Builder to block a save (they cannot), using field-level security to validate values (it controls visibility, not content), relying on a dependent picklist to enforce a cross-object condition, and recommending an Apex trigger when a formula can do the job.

8. Quick Review Checklist

• Validation rule = formula; TRUE = record rejected.
• Runs on create and edit via all channels; not on delete.
• Runs after before-save automation, before after-save automation and commit.
• Error Location: field (must be on layout) or top of page.
• Exceptions: Mass Transfer, lead conversion setting, campaign hierarchy, Quick Create, some field updates.
• Bypass: $Permission (custom permission), $Profile, $User, hierarchy custom settings.
• Key functions: ISBLANK, ISPICKVAL, TEXT, INCLUDES, ISNEW, ISCHANGED, PRIORVALUE, VLOOKUP, REGEX, AND, OR, NOT, CASE.
• Limits: 3,900 char formula, 255 char error message, active rule limit per object by edition.
• Choose validation rules for conditional/cross-field/format enforcement; universally required fields for always-required; duplicate rules for duplicates; Flow for changing or notifying.

Master these principles, practice reading formulas as error conditions, and memorize the execution order and exceptions, and you will handle every validation rule question in the Advanced Administrator exam with confidence.