5.3 Validation Rules & Error Handling Strategies

Validation Rules & Error Handling Strategies

Data integrity is the bedrock of any successful enterprise Salesforce implementation. Without rigorous data quality guardrails, downstream automations fail, business analytics produce misleading insights, and sales and service teams lose confidence in the CRM platform. Validation rules are Salesforce's primary declarative mechanism for enforcing business constraints and preventing invalid, inconsistent, or incomplete data from entering the database.

---

Core Mechanics & Architectural Philosophy

A Validation Rule consists of a formula expression and a user-facing error message. The most fundamental concept to master for the Platform App Builder exam is the boolean evaluation rule:

Formula Evaluates to TRUE   --->  Data is INVALID  --->  Save Aborted & Error Displayed
Formula Evaluates to FALSE  --->  Data is VALID    --->  Save Permitted to Proceed

Unlike traditional programming assertions where a condition must evaluate to true to continue, in Salesforce a validation rule formula defines the invalid condition. When the formula evaluates to TRUE, the platform halts the save cycle, rolls back pending in-memory database modifications, and displays the designated error message to the user or API client.

Universal Platform Scope

Validation rules enforce data integrity across every data entry and manipulation vector in the Salesforce ecosystem:

• Standard Lightning record page edits and full edit modals.
• Inline editing in list views and multi-line edit grids.
• Salesforce Mobile App interactions.
• Quick Actions and Screen Flows.
• Automated background updates via Record-Triggered Flows and Apex triggers.
• External data operations via SOAP, REST, and Bulk APIs (including Data Loader, MuleSoft, and third-party ETL tools).
• Public data intake endpoints, including Web-to-Lead and Web-to-Case.

---

Essential Validation Formula Functions

Building sophisticated validation rules requires mastery of five specialized functions that inspect record state, historical field values, and string formatting patterns:

1. ISNEW()

Returns TRUE if the record is currently being inserted into the database as a new record; returns FALSE during record update transactions. ISNEW() is essential when rules must apply exclusively during record creation, such as mandating specific onboarding fields that should not block edits on historical legacy records:

AND(
  ISNEW(),
  ISBLANK(Initial_Security_Deposit__c)
)

2. ISCHANGED(field)

Compares the proposed new value of a field against its existing value currently stored in the database. Returns TRUE if the value has changed; returns FALSE if unchanged. During record creation (ISNEW()), ISCHANGED() evaluates to FALSE ; use OR(ISNEW(), ISCHANGED(Field__c)) when the rule must also apply on creation.

3. PRIORVALUE(field)

Returns the value of a field immediately prior to the current save transaction. On a newly created record, PRIORVALUE() returns the current value; use NOT(ISNEW()) if the rule must apply only to existing records. During updates, PRIORVALUE() and is the key function for enforcing state transition rules, preventing backwards stage progression, and locking fields after milestones are reached:

/* Prevent moving Opportunity Stage backward once reached Closed Won */
AND(
  ISPICKVAL(PRIORVALUE(StageName), "Closed Won"),
  NOT(ISPICKVAL(StageName, "Closed Won"))
)

4. REGEX(text, regex_pattern)

Matches a text field against a regular expression pattern and returns TRUE if the text conforms to the regex. In validation rules, because the formula must return TRUE on error, app builders wrap REGEX() inside NOT() to fire an error whenever data fails the formatting rule. In Salesforce formulas, backslashes must be escaped with double backslashes (e.g., \d):

/* Enforce US 5-digit or 9-digit Zip Code format */
AND(
  NOT(ISBLANK(PostalCode)),
  NOT(REGEX(PostalCode, "\\d{5}(-\\d{4})?"))
)

5. VLOOKUP(field_to_return, field_on_lookup_object, lookup_value)

A specialized function with three strict platform limitations:

1. Only available in Validation Rules (cannot be used in formula fields or Flows).
2. Only available on Custom Objects.
3. Can only look up against the standard Name field of another custom object.

VLOOKUP() searches a target custom object table where field_on_lookup_object (the Name field) matches lookup_value and returns field_to_return. A classic exam scenario uses VLOOKUP() to validate that a custom state postal code matches a tax rate record in a State_Tax__c lookup table.

---

Error Message UX and UI Placement Mechanics

When a validation rule formula evaluates to TRUE, Salesforce prevents the save and presents the configured error message. App builders must select one of two UI display locations:

---

Validation Rules in the Platform Order of Execution

Use the relative order to reason about a save. The full sequence includes conditional stages and repeat-save behavior; this is the essential App Builder path:

1. Salesforce loads the record and submitted values and performs initial system checks.
2. Before-save record-triggered flows modify the in-memory triggering record.
3. Before Apex triggers run, followed by system checks and custom validation rules.
4. Duplicate rules run. The record is saved and receives an ID on insert, but the transaction is still uncommitted.
5. After Apex triggers, assignment rules, auto-response rules, and legacy workflow processing run.
6. Escalation rules, legacy processes and their invoked flows, and immediate after-save record-triggered flows execute, followed by applicable entitlement processing.
7. Roll-up calculations and related parent save procedures run. Salesforce then commits the transaction.
8. Post-commit processing includes queued asynchronous Flow paths and email delivery.

A before-save flow can populate a value before a custom validation rule evaluates it, but do not depend on it to rescue an input rejected by an earlier system-required-field check. Immediate after-save flows are not post-commit jobs: a later error can still roll back their work.

Legacy workflow field updates have special repeat-save behavior. They rerun before/after Apex triggers without rerunning custom validation rules in that workflow update cycle. Approval field updates also do not automatically pass through custom validation rules. Distinguish these from ordinary Flow Update Records operations, which use normal record-save behavior. Test the actual combination of automation in a sandbox.

---

Enterprise Bypass Architectures for Migrations and Integrations

During large-scale data migrations (e.g., importing 300,000 legacy records via Data Loader) or high-frequency automated integrations (e.g., an ERP syncing invoices via an API integration user), historical data frequently violates newly implemented validation rules.

The Anti-Pattern: Manual Deactivation

A naive administrator might navigate into Setup, manually uncheck "Active" on 25 validation rules, run the migration, and reactivate the rules afterward. This approach introduces extreme organizational risk:

• Standard business users interacting with Salesforce during the migration window can enter dirty, invalid data without restriction.
• Administrators frequently forget to reactivate all rules or fail to reactivate them with original configurations.
• Automated unit tests and continuous integration deployments can fail during the deactivated window.

Solution 1: Custom Permissions ($Permission)

The modern enterprise standard leverages Custom Permissions incorporated directly into the validation rule formula expression. Custom Permissions provide granular, metadata-driven bypass capability that can be assigned directly to specific integration users or migration administrators via Permission Sets.

Step-by-Step Implementation:

1. Navigate to Setup and create a Custom Permission named Bypass_Validation_Rules.
2. Create a Permission Set named Data_Migration_Exemptions and enable the Bypass_Validation_Rules custom permission.
3. Assign the Permission Set to the integration user or migration admin.
4. Update the validation rule formula to check $Permission.Bypass_Validation_Rules:

AND(
  NOT($Permission.Bypass_Validation_Rules),
  ISBLANK(Mandatory_Tax_ID__c)
)

When standard users edit a record, $Permission.Bypass_Validation_Rules evaluates to FALSE, making NOT(...) evaluate to TRUE, so the validation rule enforces normally. When the migration user saves a record, $Permission.Bypass_Validation_Rules evaluates to TRUE, making NOT(...) evaluate to FALSE, which immediately evaluates the entire AND() statement to FALSE, allowing the record to save seamlessly.

Solution 2: Hierarchical Custom Settings ($Setup)

Another widely deployed architecture utilizes a Hierarchical Custom Setting (e.g., Automation_Bypass__c) with a checkbox field Bypass_Validation__c. Hierarchical custom settings allow default configurations at the Organization level (set to FALSE), with granular overrides at the Profile or User level (set to TRUE for the Integration Profile):

AND(
  NOT($Setup.Automation_Bypass__c.Bypass_Validation__c),
  CloseDate < TODAY()
)

---

Validation Rule Function Matrix

Official Source Check

Checked October 19, 2026: Official save order.