Formula Fields and Validation Rules in Automation Design

Why This Topic Matters
The Salesforce Advanced Administrator exam tests your ability to design automation that is efficient, maintainable, and declarative-first. Formula fields and validation rules are the foundation of that design philosophy. Many business requirements that admins instinctively solve with Flows or workflow updates can be met more cleanly with a formula field (for derived values) or a validation rule (for data quality enforcement). The exam rewards candidates who choose the simplest tool that fully meets the requirement, understand the order of execution, and avoid common pitfalls such as cross-object limits, compile size, and conflicts between validation rules and automation.

What Formula Fields Are
A formula field is a read-only field whose value is calculated at runtime from other fields on the same record, parent records (via lookup/master-detail relationships), system values, or constants. Key characteristics:
- Return types: Checkbox, Currency, Date, Date/Time, Number, Percent, Text, Time.
- Values are calculated when viewed or queried; they are not stored in the database (so they cannot be used as external IDs, and there are limitations on indexing and some report features).
- Can reference fields up to 10 relationships away (cross-object formulas) but only upward through lookup or master-detail relationships, never downward to child records.
- Limits: 3,900 characters in the formula, 5,000 bytes when saved, 5,000 characters compiled size; up to 15 unique cross-object relationships per object (shared across formulas, validation rules, and other components).
- Common functions: IF, CASE, AND, OR, NOT, ISBLANK, ISPICKVAL, TEXT, DATEVALUE, TODAY, NOW, DATE, ADDMONTHS, IMAGE, HYPERLINK, BLANKVALUE, NULLVALUE, CONTAINS, BEGINS, LEFT, RIGHT, MID, LEN, ROUND, MOD, CEILING, FLOOR, VLOOKUP (validation rules only), ISNEW, ISCHANGED, PRIORVALUE, $User, $Profile, $Permission, $Setup, $CustomMetadata, $RecordType, $UserRole, $Label.

What Validation Rules Are
A validation rule is a formula that evaluates to TRUE or FALSE when a record is saved. If the formula evaluates to TRUE, the save is blocked and an error message displays (at the top of the page or next to a specified field). Key characteristics:
- The formula describes the error condition, not the valid condition. This inversion is a classic exam trap.
- Can reference fields on the same object and parent objects via cross-object formulas.
- Special functions available in validation rules: ISNEW(), ISCHANGED(), PRIORVALUE(), VLOOKUP() (which only works against custom objects and is only available in validation rules).
- Can be bypassed using a custom permission check such as NOT($Permission.Bypass_Validation) or a profile check, which is the recommended way to let integration users or data loaders skip rules.
- Validation rules fire on both UI and API saves, including Data Loader and Flow-driven DML. They do not fire on records created or updated by certain system processes unless explicitly configured, and they are not re-run on existing records until those records are edited.
- Active validation rules apply to all record types unless you add a $RecordType or RecordType.Name condition.

How They Work Within the Order of Execution
Understanding when each component runs is essential for designing automation that does not conflict:
1. Original record loaded, new field values overwrite old values.
2. System validation (required fields, field formats) and, for UI saves, page layout required fields.
3. Record-triggered Flows configured to run before save (Fast Field Updates).
4. Before triggers (Apex).
5. Most system validation again plus custom validation rules.
6. Duplicate rules.
7. Record saved to the database (not yet committed).
8. After triggers (Apex).
9. Assignment rules, auto-response rules, workflow rules (field updates may cause the record to re-run system validation but NOT custom validation rules).
10. Escalation rules, processes and flows launched by workflow or Process Builder, record-triggered Flows that run after save.
11. Entitlement rules, roll-up summary fields recalculated on parent records, parent and grandparent save routines.
12. Criteria-based sharing evaluation, commit, post-commit logic (email, outbound messages).

Important implications from this sequence:
- A before-save Flow runs before validation rules, so values set by a before-save Flow are validated. This is a good way to auto-populate a field that a validation rule requires.
- Workflow field updates and after-save Flows run after validation rules, so a value set there is not checked by custom validation rules on that same transaction (though workflow field updates can trigger a re-save that re-fires some logic).
- Formula fields are never "saved" by automation; they recalculate automatically, so they can be used inside validation rules and Flow criteria without needing to be updated.
- Roll-up summary fields recalculate after validation rules, so a validation rule referencing a roll-up on the parent sees the value from before the current child change.

Design Decisions: When to Use Which Tool
- Use a formula field when the requirement is to display, calculate, or categorize a value derived from existing data, and the value never needs to be edited or stored. Examples: days until close date, a status icon, a full name concatenation, a discount tier based on amount, a parent account's region displayed on the opportunity.
- Use a validation rule when the requirement is to prevent a save under specific conditions. Examples: Close Date cannot be in the past when Stage is Closed Won; Discount over 20% requires VP approval checkbox; Industry is required when Account Type is Customer; only users with a certain profile may change Stage back from Closed.
- Use a Flow when a value must be stored (for reporting on historical values, sorting on indexed fields, or external system sync), when the logic needs to update other records, send notifications, or branch into multiple actions, or when the formula would exceed compile limits.
- Use a roll-up summary (or a Flow for lookup relationships) when you need aggregated child data, because formula fields cannot look down to children.
- Use a custom permission to bypass validation rules rather than hardcoding profile names or usernames.
- Prefer a formula field over a Flow when a stored value would require re-updating all existing records; formula fields are retroactive by nature.

Common Design Patterns
- Conditional requirement: AND(ISPICKVAL(Type, "Customer"), ISBLANK(TEXT(Industry))). Note that picklists must be wrapped in TEXT() for ISBLANK, or use ISPICKVAL(Industry, "").
- Prevent change after a state: AND(ISCHANGED(Amount), ISPICKVAL(StageName, "Closed Won"), NOT($Permission.Edit_Closed_Opps)).
- Only on create: ISNEW() combined with the condition.
- Compare to prior value: PRIORVALUE(Status) to detect regressions in a lifecycle.
- Cross-object check: Account.Active__c = FALSE blocks creating opportunities on inactive accounts.
- Data format enforcement: NOT(REGEX(Postal_Code__c, "\\d{5}(-\\d{4})?")).
- Record-type-specific rule: RecordType.DeveloperName = "Enterprise".
- Formula-driven image indicators: IMAGE("/img/samples/flag_red.gif", "Red") inside IF logic for visual status.
- Helper formula field: build a complex Boolean formula field, then reference it in validation rules, report filters, and Flow decision elements to centralize logic.

Pitfalls and Gotchas the Exam Likes to Test
- Writing the validation formula as the "valid" condition instead of the error condition.
- Forgetting that a blank number field in a formula is treated as zero by default unless the formula is configured to treat blanks as blanks.
- Using = with picklists (invalid); you must use ISPICKVAL or TEXT().
- Expecting a formula field to look at child records or to be searchable/indexed like a stored field.
- Expecting workflow field updates or after-save Flow updates to trigger validation rules (they do not, except re-running system validation).
- Hitting the 15 unique cross-object relationship limit or the 5,000-byte compile limit; the fix is often to split logic into helper formula fields or move logic to a Flow.
- Assuming validation rules retroactively clean existing data; they only evaluate on save.
- Hardcoding IDs or profile names; use $Permission, custom metadata, or record type developer names instead.
- Validation rules on a parent object are evaluated when a child master-detail record changes only if the parent itself is saved; roll-up changes alone do not fire parent validation rules unless the parent record is being edited.
- Validation rules and required fields: a before-save Flow can populate a required field, but an after-save Flow cannot rescue a save already blocked by validation.
- Validation errors thrown during a Flow's DML cause the Flow to fail; design Flows with fault paths and consider whether the validation rule should bypass the automation user.

Exam Tips: Answering Questions on Formula Fields and Validation Rules in Automation Design
1. Identify the verb in the requirement. "Display," "calculate," "show," "indicate" point to a formula field. "Prevent," "require," "ensure," "must not be saved" point to a validation rule. "Update," "create," "notify," "send" point to a Flow.
2. Apply the declarative-first hierarchy. When two answers both work, choose formula field over Flow, validation rule over Apex trigger, and roll-up summary over Flow when the relationship is master-detail. The exam almost always prefers the lowest-complexity native tool.
3. Check whether the value must be stored. If the scenario mentions reporting on historical values, sorting large data volumes, integrations reading the field, or using it as an external ID, a formula field is wrong and a Flow-updated stored field is right.
4. Check the direction of the relationship. Parent-to-child (summing children, counting related records) rules out formula fields. Child-to-parent (showing the account owner on a contact) is exactly what cross-object formulas do.
5. Invert the logic mentally for validation rules. Read each answer's formula and ask, "Does this evaluate TRUE when the data is bad?" Eliminate answers that return TRUE for good data.
6. Watch for picklist handling. Any answer using Picklist_Field = "Value" without ISPICKVAL or TEXT() is syntactically invalid and can be eliminated immediately.
7. Use the order of execution to resolve timing questions. If a question asks why a validation rule did not catch a value set by automation, the answer involves the automation running after validation (workflow field update, after-save Flow). If a question asks how to auto-fill a field so a validation rule passes, the answer is a before-save Flow.
8. Recognize bypass scenarios. When integration users, data migrations, or admins need exceptions, the best answer uses a custom permission ($Permission) in the validation rule, not deactivating the rule or hardcoding a user ID.
9. Look for ISNEW, ISCHANGED, PRIORVALUE keywords. Scenarios about "on creation only," "when the field changes," or "was previously" map directly to these functions, which exist only in validation rules and some Flow formula contexts, not in formula fields.
10. Spot limit-driven questions. If a scenario describes a formula that cannot be saved or an error about compile size or too many relationships, the correct remediation is simplifying with helper formula fields, using custom metadata or custom settings, or moving logic to a Flow, not creating a trigger as the first option.
11. Eliminate answers that violate best practice. Hardcoded record IDs, profile names in formulas, deactivating rules to load data, and duplicating logic across multiple components are red flags.
12. Pay attention to record types and multiple rules. If a requirement applies to one business process, the correct answer scopes the validation rule with RecordType.DeveloperName or a record-type-aware formula rather than creating a global rule.
13. Read error placement details. Questions may ask where an error should appear; validation rules support top-of-page or next-to-field display, and the field must be on the page layout for field-level display to show.
14. Remember what validation rules do not cover. They do not run on existing records until edited, do not fire on deletes, and do not protect against changes made through workflow field updates in the same transaction. Use these facts to eliminate answers that over-promise.
15. Manage time. Formula and validation questions often include long formulas. Scan for the obvious disqualifiers first (syntax errors, inverted logic, wrong tool), then evaluate the remaining options against the requirement.

Summary
Formula fields compute and display; validation rules guard the save; Flows act and store. Mastering the order of execution, the relationship direction rules, the limits, and the inverted logic of validation formulas allows you to pick the right tool quickly. On the exam, favor the simplest declarative solution, verify the formula actually returns TRUE for bad data, confirm the relationship traversal direction, and use custom permissions for bypass logic. These habits will convert most automation-design questions in this domain into straightforward eliminations.