Validation Rule Practice Problems (50) — With Full Explanations

This guide walks through 50 declarative validation-rule formulas for enforcing data-quality constraints without code. Each entry below includes the full problem statement, the governor-limit and best-practice constraints it's testing, and a numbered approach to solving it — then you can open the same problem in ApexArena's browser-based Apex editor and get instant pass/fail feedback against real test cases.

On this page

1. Prevent Closed Opportunity Without Close Date
2. Require Phone on Hot Lead
3. Prevent Negative Opportunity Amount
4. Enforce Future Close Date
5. Validate Email Format on Contact
6. Require Account Name Change Justification
7. Limit Discount Percentage
8. Prevent Duplicate Lead Email
9. Require Description for High-Value Opportunities
10. Prevent Stage Regression
11. Validate Phone Number Format
12. Prevent Self-Referral on Account
13. Require Billing State for US Accounts
14. Enforce Minimum Opportunity Probability
15. Block Case Closure Without Resolution
16. Prevent Contract End Before Start Date
17. Require Industry for New Accounts
18. Block Opportunity Owner Change After Close
19. Validate Zip Code Format
20. Enforce Max Line Items on Quote
21. PRIORVALUE: Prevent Reducing Opportunity Amount
22. REGEX: Validate Phone Number Format
23. Validation Rule: Prevent Task Due Date in the Past on Creation
24. Validation Rule: Enforce Consistent Case Priority and Status
25. Validation Rule: Require Approval Comments for High Discounts
26. Validation Rule: Require an Escalation Reason on Case
27. Validation Rule: Prevent Editing a Locked Opportunity
28. Validation Rule: Enforce a 2-Letter State Code for US Accounts
29. Validation Rule: Restrict Case Type Change After Work Has Started
30. Validation Rule: Require at Least One Contact Method
31. Validation Rule: Require Project End Date After Start Date
32. Validation Rule: Block Large Amount Increases in Late-Stage Negotiation
33. Validation Rule: Enforce Weekday-Only Case Closure
34. Validation Rule: Require Justification for Reopening a Closed Case
35. Validation Rule: Prevent a Contact From Being Its Own Manager
36. Scenario: Require Manager Comment When Overriding a Quote Line's List Price
37. Validation Rule: Require an Email Address on Every Lead
38. Validation Rule: Annual Revenue Must Be Positive
39. Validation Rule: Require a Loss Reason When Opportunity Is Marked Closed Lost
40. Validation Rule: VIP Accounts Must Always Have an Account Manager Assigned
41. Validation Rule: Enforce a Required Invoice Number Format
42. Validation Rule: Only Managers Can Approve Discounts Above 30%
43. Validation Rule: Prevent Changing Amount on a Closed Opportunity
44. Validation Rule: Shipping Address Required Before Submitting an Order
45. Validation Rule: High-Value Opportunities Require Executive Approval
46. Validation Rule: Prevent Marking an Account Inactive While an Active Contract Exists
47. Validation Rule: Country-Specific Tax ID Format Validation
48. Validation Rule: Subscription Term Cannot Exceed 5 Years
49. Validation Rule: Close Date Must Fall Within the Custom Fiscal Year on the Budget
50. Validation Rule: Multi-Field Guard for Large, Late-Stage, Fast-Closing Deals

Easy Validation

1. Prevent Closed Opportunity Without Close Date

Problem #50 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Opportunity that prevents saving a record when the Stage is "Closed Won" or "Closed Lost" but CloseDate is blank.

Requirements

Error fires only when Stage is Closed Won or Closed Lost
Error fires only when CloseDate is null/blank
Show the error message: "A Close Date is required for closed opportunities."

Formula Hint

AND(OR(ISPICKVAL(...)), ISBLANK(...))

Approach

1ISPICKVAL(StageName, "Closed Won") checks a picklist field value.
2ISBLANK(CloseDate) returns true when the date field is empty.
3Wrap both conditions in AND() — both must be true to block save.

Easy Validation

2. Require Phone on Hot Lead

Problem #51 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Lead that requires the Phone field when Rating is "Hot".

Requirements

Trigger only when Rating = Hot
Trigger only when Phone is blank
Error message: "Phone is required for Hot leads."

Approach

1ISPICKVAL(Rating, "Hot") checks the Lead Rating picklist.
2ISBLANK(Phone) is true when Phone is empty or null.

Easy Validation

3. Prevent Negative Opportunity Amount

Problem #52 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Opportunity that prevents saving when Amount is a negative number.

Requirements

Block saves when Amount < 0
Allow saves when Amount is null or 0 or positive
Error message: "Amount cannot be negative."

Approach

1Check NOT(ISBLANK(Amount)) first to avoid null comparison errors.
2Then compare Amount < 0 to catch negative values.

Easy Validation

4. Enforce Future Close Date

Problem #53 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Opportunity that prevents setting CloseDate to a date in the past when creating a new record.

Requirements

Only applies on insert (use ISNEW())
Block when CloseDate < TODAY()
Error message: "Close Date must be today or in the future."

Approach

1ISNEW() returns true only on record creation — prevents blocking edits.
2TODAY() returns the current date without time component.
3CloseDate < TODAY() is true when the date is in the past.

Easy Validation

5. Validate Email Format on Contact

Problem #54 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Contact that validates the Email field contains a proper email format (must contain @ and a dot).

Requirements

Only validate when Email is not blank
Use NOT(REGEX(...)) with a basic email pattern
Error message: "Please enter a valid email address."

Approach

1REGEX(field, pattern) returns true when the field matches the pattern.
2NOT(REGEX(...)) blocks save when the email does NOT match the pattern.
3Guard with NOT(ISBLANK(Email)) to skip validation for empty emails.

Medium Validation

6. Require Account Name Change Justification

Problem #55 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Account that requires the custom field Name_Change_Reason__c to be filled in whenever the Name field is changed on an existing record.

Requirements

Only applies on edit (not new records)
Use ISCHANGED(Name) to detect the change
Require Name_Change_Reason__c to be non-blank
Error message: "Please provide a reason for changing the Account Name."

Approach

1ISCHANGED(Name) is only valid in update context — use NOT(ISNEW()) to be safe.
2ISBLANK(Name_Change_Reason__c) checks the justification field is empty.
3All three conditions must be true to block the save.

Medium Validation

7. Limit Discount Percentage

Problem #56 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Opportunity that prevents the custom field Discount__c from exceeding 30% unless the record owner has the Manager profile (simulate with a custom field Is_Manager__c checkbox on User).

Requirements

Block when Discount__c > 30
Allow when owner's Owner.Is_Manager__c is true
Error message: "Discount cannot exceed 30% without manager approval."

Approach

1Owner.Is_Manager__c traverses the lookup to the User object.
2NOT(Owner.Is_Manager__c) is true when the owner is NOT a manager.
3Both conditions must hold: high discount AND non-manager.

Medium Validation

8. Prevent Duplicate Lead Email

Problem #57 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Lead that blocks saving when the Email field is changed to match a known pattern that indicates a temporary/test email (contains "+test" or ends with "@example.com").

Requirements

Block emails containing "+test"
Block emails ending with "@example.com"
Use CONTAINS() and ENDS() functions
Error message: "Test email addresses are not allowed."

Approach

1CONTAINS(Email, "+test") returns true if "+test" appears anywhere in the email.
2ENDS(Email, "@example.com") returns true if the email ends with that domain.
3OR() fires the block if either condition is true.

Easy Validation

9. Require Description for High-Value Opportunities

Problem #58 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Opportunity that requires the Description field when Amount is greater than $500,000.

Requirements

Block when Amount > 500000 AND Description is blank
Error message: "Description is required for opportunities over $500,000."

Approach

1Amount > 500000 checks the numeric threshold.
2ISBLANK(Description) checks the text field is empty.

Hard Validation

10. Prevent Stage Regression

Problem #59 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Opportunity that prevents the StageName from being moved backwards in the sales cycle.

Stage order: Prospecting → Qualification → Proposal → Negotiation → Closed Won

Requirements

Use ISPICKVAL(PRIORVALUE(StageName), ...) to detect the previous stage
Block if the new stage is earlier in the pipeline than the previous stage
Error message: "Opportunity stage cannot be moved backwards."

Approach

1PRIORVALUE(StageName) gives the stage value before the current edit.
2ISCHANGED(StageName) ensures we only run this check when stage actually changed.
3Build the regression check as nested OR/AND comparing new vs prior stage.

Medium Validation

11. Validate Phone Number Format

Problem #60 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Contact that enforces a 10-digit US phone number format (XXX) XXX-XXXX using REGEX().

Requirements

Only validate when Phone is not blank
Valid format: (555) 555-5555
Error message: "Phone must be in (XXX) XXX-XXXX format."

Approach

1REGEX uses Java regex syntax: \\( escapes the literal parenthesis in Salesforce formulas.
2\\d{3} matches exactly 3 digits.
3NOT(REGEX(...)) fires the error when the phone does NOT match the pattern.

Medium Validation

12. Prevent Self-Referral on Account

Problem #61 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Account that prevents an account from referencing itself in the ParentId lookup field.

Requirements

Block when ParentId equals the account's own Id
Error message: "An Account cannot be its own parent."

Approach

1In formula context, Id refers to the current record's Id.
2ParentId = Id is a direct equality check — simple but effective.

Easy Validation

13. Require Billing State for US Accounts

Problem #62 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Account that requires BillingState when BillingCountry is "United States" or "US".

Requirements

Block when country is US/United States AND state is blank
Error message: "Billing State is required for US accounts."

Approach

1Use direct string equality: BillingCountry = "United States".
2OR() covers both "US" and "United States" abbreviations.
3ISBLANK(BillingState) checks if the state was left empty.

Medium Validation

14. Enforce Minimum Opportunity Probability

Problem #63 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Opportunity that requires Probability to be at least 10% when the stage is "Qualification" or later.

Requirements

Block when Stage is Qualification/Proposal/Negotiation AND Probability < 10
Error message: "Probability must be at least 10% for qualified opportunities."

Approach

1ISPICKVAL checks picklist values — make sure the label matches exactly.
2Probability < 10 checks the numeric percentage field.

Easy Validation

15. Block Case Closure Without Resolution

Problem #64 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Case that prevents closing a case (Status = "Closed") unless the Description field contains a resolution note (is not blank).

Requirements

Block when Status = Closed AND Description is blank
Error message: "Please add a resolution description before closing this case."

Approach

1ISPICKVAL(Status, "Closed") matches the Status picklist value.
2ISBLANK(Description) checks the long text area is empty.

Easy Validation

16. Prevent Contract End Before Start Date

Problem #65 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on a custom object Contract__c that ensures End_Date__c is always after Start_Date__c.

Requirements

Block when both dates are filled and End_Date__c <= Start_Date__c
Error message: "End Date must be after Start Date."

Approach

1Guard both date fields with NOT(ISBLANK(...)) before comparing.
2End_Date__c <= Start_Date__c catches both equal and earlier end dates.

Easy Validation

17. Require Industry for New Accounts

Problem #66 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Account that makes Industry required only when creating a new account.

Requirements

Only applies on insert (ISNEW())
Block when Industry picklist is blank
Error message: "Industry is required when creating a new Account."

Approach

1ISNEW() returns true only when the record is being created.
2Industry is a picklist — use ISBLANK(TEXT(Industry)) to check if it is empty.
3TEXT() converts the picklist to a string so ISBLANK() can evaluate it.

Hard Validation

18. Block Opportunity Owner Change After Close

Problem #67 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Opportunity that prevents changing the OwnerId after the opportunity is Closed Won.

Requirements

Block when Stage is Closed Won AND OwnerId has changed
Use ISCHANGED(OwnerId) and ISPICKVAL(StageName, "Closed Won")
Error message: "Owner cannot be changed on a Closed Won opportunity."

Approach

1ISPICKVAL(StageName, "Closed Won") checks the current stage.
2ISCHANGED(OwnerId) is true when OwnerId is different from its previous value.
3No ISNEW() needed — ISCHANGED() automatically returns false on new records.

Medium Validation

19. Validate Zip Code Format

Problem #68 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Account that validates BillingPostalCode is a valid US ZIP code — either 5 digits (12345) or ZIP+4 (12345-6789).

Requirements

Only validate when BillingPostalCode is not blank
Use REGEX() for the pattern match
Error message: "Please enter a valid ZIP code (e.g., 12345 or 12345-6789)."

Approach

1\\d{5} matches exactly 5 digits in Salesforce REGEX formula syntax.
2(-\\d{4})? makes the ZIP+4 suffix optional.
3NOT(REGEX(...)) fires the error when the code does NOT match.

Hard Validation

20. Enforce Max Line Items on Quote

Problem #69 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on a custom object Quote__c that prevents saving when the rollup summary field Total_Line_Items__c exceeds 50 line items.

Requirements

Block when Total_Line_Items__c > 50
Only applies on edit (use NOT(ISNEW())) since rollup is computed after save
Error message: "A quote cannot have more than 50 line items."

Approach

1Rollup summary fields are calculated server-side, so they reflect values from the previous save.
2NOT(ISNEW()) prevents false positives on brand-new quotes with 0 line items.
3Total_Line_Items__c > 50 is a direct numeric comparison on the rollup field.

Medium Validation

21. PRIORVALUE: Prevent Reducing Opportunity Amount

Problem #312 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on the Opportunity object that prevents users from reducing the Amount field once it has been set.

The rule should fire (return TRUE to block save) when:

The record is being edited (not newly created)
The new Amount is less than the previous value
The previous Amount was not null

Key Function

PRIORVALUE(field) — returns the field's value before the current edit
ISNEW() — returns TRUE if the record is being created for the first time

Approach

1Use NOT(ISNEW()) to make sure the rule only applies on edits.
2PRIORVALUE(Amount) gives the Amount before the current save.
3Combine conditions: NOT(ISNEW()) AND Amount < PRIORVALUE(Amount) AND NOT(ISNULL(PRIORVALUE(Amount))).

Medium Validation

22. REGEX: Validate Phone Number Format

Problem #313 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on the Contact object that ensures the Phone field (if not blank) matches the format (XXX) XXX-XXXX where X is a digit.

Valid examples: (415) 555-1234, (800) 867-5309

The rule should fire (return TRUE) when Phone is not blank but does not match the expected pattern.

Key Function

REGEX(text, pattern) — returns TRUE if text matches the regex pattern
NOT(REGEX(...)) — returns TRUE when it does NOT match (use in validation)

Approach

1The regex for (XXX) XXX-XXXX is: $\d{3}$ \d{3}-\d{4}
2Use NOT(REGEX(Phone, pattern)) so the rule fires on mismatch.
3Wrap in AND(NOT(ISBLANK(Phone)), NOT(REGEX(...))) to only validate non-blank values.

Easy Validation

23. Validation Rule: Prevent Task Due Date in the Past on Creation

Problem #399 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Task that prevents creating a new Task with a Due Date (ActivityDate) that's already in the past.

Requirements

Error fires only when the Task is being created — editing an existing, already-overdue Task must not be blocked.
Error fires only when ActivityDate is earlier than today.

Formula Hint

AND(ISNEW(), ActivityDate < TODAY())

Approach

1ISNEW() is true only while the record is being created for the first time — never true on an edit of an existing record.
2TODAY() returns the current Date with no time component, safe to compare directly against a Date field.
3Without ISNEW(), this rule would also block legitimately editing an old, already-overdue Task — always scope past-date checks to creation only.

Medium Validation

24. Validation Rule: Enforce Consistent Case Priority and Status

Problem #400 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Case that prevents saving a Case with Status = "Escalated" while Priority is still set to "Low" — an escalated case should never remain flagged as low priority.

Requirements

Error fires only when both Status is Escalated and Priority is Low.
Any other Status/Priority combination must save without error.

Formula Hint

AND(ISPICKVAL(Status, "Escalated"), ISPICKVAL(Priority, "Low"))

Approach

1ISPICKVAL(fieldName, "Value") is the correct way to compare a picklist field to a specific value.
2Both conditions must hold at the same time — wrap them in AND(), not OR().
3Do not compare Status or Priority with plain = "text" — picklist fields require ISPICKVAL().

Medium Validation

25. Validation Rule: Require Approval Comments for High Discounts

Problem #401 · Salesforce Apex Coding Challenge

Problem Statement

An Opportunity has a custom Discount__c percentage field and a custom Approval_Comments__c text field. Write a Validation Rule that requires Approval_Comments__c to be filled in whenever Discount__c exceeds 20%.

Requirements

Error fires only when Discount__c > 20.
Error fires only when Approval_Comments__c is blank.
A discount of 20% or less never requires comments, regardless of whether they're filled in.

Formula Hint

AND(Discount__c > 20, ISBLANK(Approval_Comments__c))

Approach

1Compare the number field directly: Discount__c > 20 (no ISPICKVAL needed — this is not a picklist).
2ISBLANK(Approval_Comments__c) is true when the text field is empty.
3Validation Rule formulas do not need (and don't have) a named-constant mechanism for a literal threshold like 20 — a plain number here is normal.

Halfway there — solve them live

Every problem above runs in a real in-browser Apex editor with instant pass/fail feedback and best-practice linting. No Salesforce org needed.

Create Free Account →

Easy Validation

26. Validation Rule: Require an Escalation Reason on Case

Problem #415 · Salesforce Apex Coding Challenge

Problem Statement

A Case has a custom text field Escalation_Reason__c. Write a Validation Rule that blocks saving whenever Status is set to "Escalated" but Escalation_Reason__c is left blank.

Formula Hint

AND(ISPICKVAL(Status, "Escalated"), ISBLANK(Escalation_Reason__c))

Approach

1ISPICKVAL(Status, "Escalated") checks the Case Status picklist.
2ISBLANK(Escalation_Reason__c) is true when the reason field is empty.
3Both conditions must hold together — wrap them in AND().

Easy Validation

27. Validation Rule: Prevent Editing a Locked Opportunity

Problem #416 · Salesforce Apex Coding Challenge

Problem Statement

An Opportunity has a custom checkbox Locked__c. Write a Validation Rule that blocks any edit to an Opportunity once it's been marked locked — but still allows the record to be created in the first place (even if created with the box already checked).

Formula Hint

AND(Locked__c, NOT(ISNEW()))

Approach

1Locked__c is a checkbox field — reference it directly as a boolean, no ISPICKVAL needed.
2NOT(ISNEW()) restricts the rule to edits only, so creating a new (even pre-locked) record still succeeds.
3Combine both with AND() — the rule should fire only when locked AND being edited.

Medium Validation

28. Validation Rule: Enforce a 2-Letter State Code for US Accounts

Problem #417 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Account that requires BillingState to be a valid 2-letter code whenever BillingCountryCode is "US".

Requirements

Only applies when the country is the US.
Skips the check entirely when BillingState is blank (a separate "state required" rule would cover that case).
Fires when a non-blank BillingState doesn't match a 2-letter pattern.

Formula Hint

AND(ISPICKVAL(BillingCountryCode, "US"), NOT(ISBLANK(BillingState)), NOT(REGEX(BillingState, "[A-Za-z]{2}")))

Approach

1BillingCountryCode is a picklist — use ISPICKVAL(BillingCountryCode, "US").
2Skip blank BillingState values with NOT(ISBLANK(BillingState)) — don't conflate "missing" with "invalid format".
3REGEX(BillingState, "[A-Za-z]{2}") matches a 2-letter code; NOT(...) fires the rule when it does not match.

Medium Validation

29. Validation Rule: Restrict Case Type Change After Work Has Started

Problem #418 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Case that prevents changing the Type field once a Case has moved past its initial "New" status — changing the Type mid-investigation would invalidate work already done under the original classification.

Formula Hint

AND(NOT(ISPICKVAL(Status, "New")), ISCHANGED(Type))

Approach

1NOT(ISPICKVAL(Status, "New")) is true for any status other than New.
2ISCHANGED(Type) is true only on an edit where Type's value differs from before the save — it is always false on record creation.
3A brand-new Case (Status = New) can still have its Type set freely; only Type changes after that are blocked.

Medium Validation

30. Validation Rule: Require at Least One Contact Method

Problem #419 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Contact that blocks saving when both Phone and Email are blank — every Contact must have at least one way to be reached.

Formula Hint

AND(ISBLANK(Phone), ISBLANK(Email))

Approach

1The rule should fire only when NEITHER contact method is present — that's an AND of two ISBLANK() checks, not an OR.
2If you used OR() here instead, the rule would incorrectly fire even when just one of the two fields is blank.
3A Contact with only a Phone, or only an Email, must still save successfully.

Medium Validation

31. Validation Rule: Require Project End Date After Start Date

Problem #420 · Salesforce Apex Coding Challenge

Problem Statement

A custom Project__c object has Start_Date__c and End_Date__c date fields. Write a Validation Rule that blocks saving whenever both dates are filled in but End_Date__c is before Start_Date__c.

Formula Hint

AND(NOT(ISBLANK(Start_Date__c)), NOT(ISBLANK(End_Date__c)), End_Date__c < Start_Date__c)

Approach

1Guard both dates with NOT(ISBLANK(...)) first — comparing a blank Date field can behave unexpectedly.
2Once both are guaranteed non-blank, a plain End_Date__c < Start_Date__c comparison catches the invalid order.
3A Project with only one date filled in (or neither) should still be allowed to save.

Hard Validation

32. Validation Rule: Block Large Amount Increases in Late-Stage Negotiation

Problem #421 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Opportunity that blocks increasing Amount by more than 20% once the deal has reached the "Negotiation/Review" stage — a sudden large jump this late usually signals a data-entry mistake rather than a legitimate scope change.

Formula Hint

AND(ISPICKVAL(StageName, "Negotiation/Review"), NOT(ISNEW()), NOT(ISNULL(PRIORVALUE(Amount))), Amount > (PRIORVALUE(Amount) * 1.2))

Approach

1Scope to the late stage first: ISPICKVAL(StageName, "Negotiation/Review").
2NOT(ISNEW()) restricts this to edits — a brand-new Opportunity has no prior Amount to compare against.
3PRIORVALUE(Amount) gives the value before this save; guard against it being null before using it in arithmetic.
4Amount > PRIORVALUE(Amount) * 1.2 fires when the new Amount is more than 20% higher than before.

Hard Validation

33. Validation Rule: Enforce Weekday-Only Case Closure

Problem #422 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Case that prevents closing a Case (Status = "Closed") on a Saturday or Sunday, since support staff aren't available to confirm the resolution over the weekend.

Key Technique — Weekday Check via a Known Reference Date

DATE(1900, 1, 7) was a Sunday. Since days-of-week repeat every 7 days, MOD(TODAY() - DATE(1900, 1, 7), 7) gives a number from 0–6 that's always the same for a given day of the week: 0 = Sunday, 6 = Saturday.

Formula Hint

AND(ISPICKVAL(Status, "Closed"), OR(MOD(TODAY() - DATE(1900,1,7), 7) = 0, MOD(TODAY() - DATE(1900,1,7), 7) = 6))

Approach

1Formula fields and Validation Rules have no native DAYOFWEEK() function — the MOD-against-a-known-Sunday trick is the standard workaround.
2DATE(1900, 1, 7) is a fixed, known Sunday — subtracting it from TODAY() and taking MOD 7 gives a repeating 0-6 weekday cycle.
3OR() checks for either remainder that corresponds to Saturday or Sunday.

Medium Validation

34. Validation Rule: Require Justification for Reopening a Closed Case

Problem #423 · Salesforce Apex Coding Challenge

Problem Statement

A Case has a custom text field Reopen_Reason__c. Write a Validation Rule that requires Reopen_Reason__c to be filled in whenever a previously-"Closed" Case's Status is changed to anything else.

Key Technique — Comparing a Prior Picklist Value

PRIORVALUE() on a picklist field returns a special picklist-comparison value that cannot be compared directly with = or checked with ISPICKVAL(). Wrap it in TEXT() first — TEXT(PRIORVALUE(Status)) = "Closed" — to safely compare it as a plain string.

Formula Hint

AND(ISCHANGED(Status), TEXT(PRIORVALUE(Status)) = "Closed", NOT(ISPICKVAL(Status, "Closed")), ISBLANK(Reopen_Reason__c))

Approach

1ISCHANGED(Status) is true only when Status actually differs from its prior value on this save.
2PRIORVALUE() on a picklist needs TEXT() around it before you can compare it with = — you cannot pass PRIORVALUE(Status) directly to ISPICKVAL().
3NOT(ISPICKVAL(Status, "Closed")) confirms the Case is moving away from Closed, not staying there or being re-closed.
4ISBLANK(Reopen_Reason__c) is the actual condition being enforced — everything else just scopes it to a genuine reopen.

Easy Validation

35. Validation Rule: Prevent a Contact From Being Its Own Manager

Problem #424 · Salesforce Apex Coding Challenge

Problem Statement

A Contact has a custom self-lookup field Manager__c. Write a Validation Rule that blocks saving a Contact whose Manager__c points back to itself.

Formula Hint

Id = Manager__c

Approach

1A Validation Rule formula doesn't need to be wrapped in AND() when there is only one condition — a single Boolean expression is enough.
2Id always refers to the current record being saved — comparing it to Manager__c directly checks for a self-reference.
3When Manager__c is blank, Id = Manager__c naturally evaluates to false, so records with no manager set are unaffected.

Medium Validation

36. Scenario: Require Manager Comment When Overriding a Quote Line's List Price

Problem #442 · Salesforce Apex Coding Challenge

Problem Statement

A custom Quote_Line__c object has List_Price_Override__c, Standard_List_Price__c, and Override_Justification__c fields. Write a Validation Rule that requires Override_Justification__c to be filled in whenever a rep overrides the list price to something other than the standard price.

Requirements

Only fires when an override price is actually entered (not blank).
Only fires when the override differs from the standard price — re-entering the same value shouldn't count as an override.
Fires when Override_Justification__c is blank.

Formula Hint

AND(NOT(ISBLANK(List_Price_Override__c)), List_Price_Override__c <> Standard_List_Price__c, ISBLANK(Override_Justification__c))

Approach

1NOT(ISBLANK(List_Price_Override__c)) confirms an override value was actually entered.
2Comparing List_Price_Override__c <> Standard_List_Price__c catches only genuine overrides, not a value that happens to match the standard price.
3ISBLANK(Override_Justification__c) is the actual condition being enforced — everything else scopes it to a real override.

Easy Validation

37. Validation Rule: Require an Email Address on Every Lead

Problem #483 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Lead that blocks saving any Lead whose Email field is left blank. Sales needs every Lead to have a working email address before it can enter the queue.

Requirements

Error fires whenever Email is blank, on both create and edit.
A Lead with any non-blank Email value must save without error.

Formula Hint

ISBLANK(Email)

Approach

1ISBLANK(field) returns true when a text field is empty — exactly the condition that should block the save.
2No AND()/OR() wrapper is needed here — this is a single condition, so the bare ISBLANK() call is the whole formula.
3Do not scope this with ISNEW() — a Lead that later has its Email cleared out on edit should also be blocked.

Easy Validation

38. Validation Rule: Annual Revenue Must Be Positive

Problem #484 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Account that prevents saving an AnnualRevenue value of zero or less. A blank AnnualRevenue is fine (it just means the data hasn't been collected yet) — only an explicit non-positive number should be rejected.

Requirements

Error fires only when AnnualRevenue is populated and is <= 0.
A blank AnnualRevenue must never trigger the error.

Formula Hint

AND(NOT(ISBLANK(AnnualRevenue)), AnnualRevenue <= 0)

Approach

1A number field can be directly compared with <= 0 — no ISPICKVAL or TEXT() conversion needed.
2Guard with NOT(ISBLANK(AnnualRevenue)) first — otherwise a blank number field may be treated as 0 and wrongly blocked.
3AND() ensures both the "has a value" check and the "value is non-positive" check must be true together.

Medium Validation

39. Validation Rule: Require a Loss Reason When Opportunity Is Marked Closed Lost

Problem #485 · Salesforce Apex Coding Challenge

Problem Statement

An Opportunity has a custom picklist field Loss_Reason__c. Write a Validation Rule that blocks saving an Opportunity as "Closed Lost" unless Loss_Reason__c has been filled in — management needs to know why every deal was lost.

Requirements

Error fires only when StageName is "Closed Lost".
Error fires only when Loss_Reason__c is blank.
Any other stage must save without error, regardless of Loss_Reason__c.

Formula Hint

AND(ISPICKVAL(StageName, "Closed Lost"), ISBLANK(Loss_Reason__c))

Approach

1StageName is a picklist field, so it must be compared with ISPICKVAL(StageName, "Closed Lost"), never StageName = "Closed Lost".
2ISBLANK(Loss_Reason__c) is true when the reason picklist/text field has not been set.
3Wrap both checks in AND() so the rule only fires for the specific Closed Lost + missing reason combination.

Medium Validation

40. Validation Rule: VIP Accounts Must Always Have an Account Manager Assigned

Problem #486 · Salesforce Apex Coding Challenge

Problem Statement

An Account has a custom picklist Account_Tier__c and a custom lookup field Account_Manager__c (to User). Write a Validation Rule that blocks saving an Account tiered as "VIP" unless it has an Account_Manager__c assigned.

Requirements

Error fires only when Account_Tier__c is "VIP".
Error fires only when Account_Manager__c is blank.
Non-VIP Accounts must always save, with or without an Account Manager.

Formula Hint

AND(ISPICKVAL(Account_Tier__c, "VIP"), ISBLANK(Account_Manager__c))

Approach

1Account_Tier__c is a picklist, so use ISPICKVAL(Account_Tier__c, "VIP") to test its value.
2ISBLANK() works on lookup fields too — it is true when no related User record has been set.
3AND() ensures the rule only fires for VIP accounts missing a manager, not for every blank Account_Manager__c.

Medium Validation

41. Validation Rule: Enforce a Required Invoice Number Format

Problem #487 · Salesforce Apex Coding Challenge

Problem Statement

A custom Invoice__c object has a text field Invoice_Number__c. A Validation Rule formula cannot query other Invoice records, so it cannot detect a true cross-record duplicate — but it can enforce that every Invoice Number is present and follows a consistent, predictable format (INV- followed by exactly 5 digits, e.g. INV-00042). Keeping the format consistent is what makes duplicate numbers easy to spot with a report or a before-insert Apex/flow check elsewhere.

Requirements

Error fires when Invoice_Number__c is populated but does not match the pattern INV-##### (5 digits).
This rule does not, and cannot, verify uniqueness against other Invoice records — only format/presence.

Formula Hint

AND(NOT(ISBLANK(Invoice_Number__c)), NOT(REGEX(Invoice_Number__c, "INV-[0-9]{5}")))

Approach

1REGEX(text, regexPattern) returns true when the ENTIRE field value matches the pattern — use "INV-[0-9]{5}" to require the literal prefix plus 5 digits.
2Wrap REGEX() in NOT() so the rule fires when the value does NOT match the required format.
3Guard with NOT(ISBLANK(Invoice_Number__c)) so a blank Invoice Number is caught by a separate, clearer message rather than a confusing regex failure.

Hard Validation

42. Validation Rule: Only Managers Can Approve Discounts Above 30%

Problem #488 · Salesforce Apex Coding Challenge

Problem Statement

An Opportunity has a custom Discount_Percent__c number field. Write a Validation Rule that blocks saving a discount above 30% unless the current user is a Sales Manager (by Profile) or holds a custom permission Approve_Large_Discounts (via a Custom Permission).

Requirements

Error fires only when Discount_Percent__c > 30.
The error must not fire if the running user's Profile is "Sales Manager".
The error must not fire if the running user holds the Approve_Large_Discounts custom permission, even on another Profile.

Formula Hint

AND(Discount_Percent__c > 30, NOT(ISPICKVAL($Profile.Name, "Sales Manager")), NOT($Permission.Approve_Large_Discounts))

Approach

1$Profile.Name is a picklist-like merge field — compare it with ISPICKVAL($Profile.Name, "Sales Manager"), the same way you would any picklist.
2$Permission.ApiName evaluates to true/false for whether the running user holds that Custom Permission — no ISPICKVAL needed since it is already boolean.
3The rule must fire only when ALL THREE are true: over the threshold, NOT a Sales Manager, and NOT holding the override permission — combine with AND() and NOT().

Hard Validation

43. Validation Rule: Prevent Changing Amount on a Closed Opportunity

Problem #489 · Salesforce Apex Coding Challenge

Problem Statement

Write a Validation Rule on Opportunity that locks the Amount field once a deal is already Closed Won or Closed Lost — Finance has reported deals with amounts changing weeks after close, throwing off reporting.

Requirements

Only applies on edit of an existing record, never on creation.
Error fires only when Amount has actually changed on this edit.
Error fires only when the Opportunity was already Closed Won/Lost before this edit and its stage is not changing as part of this same save (so reopening a Closed Opportunity and changing the Amount as part of that same transaction is still allowed).

Formula Hint

AND(NOT(ISNEW()), ISCHANGED(Amount), OR(ISPICKVAL(StageName, "Closed Won"), ISPICKVAL(StageName, "Closed Lost")), PRIORVALUE(StageName) = StageName)

Approach

1ISCHANGED(Amount) is true only on the edit where Amount actually differs from its prior saved value.
2PRIORVALUE(StageName) = StageName confirms the Stage itself is not being changed in this same edit — so a rep reopening the deal and changing Amount together is allowed.
3NOT(ISNEW()) plus ISCHANGED() together are how you scope a "field is locked once XYZ" rule to edits only, never to the initial creation.

Hard Validation

44. Validation Rule: Shipping Address Required Before Submitting an Order

Problem #490 · Salesforce Apex Coding Challenge

Problem Statement

A custom Order__c object has a picklist Status__c and four custom text fields for the shipping address: Shipping_Street__c, Shipping_City__c, Shipping_Postal_Code__c, and Shipping_Country__c. Write a Validation Rule that blocks moving Status__c to "Submitted" unless the full shipping address has been filled in.

Requirements

Error fires only when Status__c is "Submitted".
Error fires if any of the four shipping address fields is blank.
Orders in any other status can be saved freely, address complete or not.

Formula Hint

AND(ISPICKVAL(Status__c, "Submitted"), OR(ISBLANK(Shipping_Street__c), ISBLANK(Shipping_City__c), ISBLANK(Shipping_Postal_Code__c), ISBLANK(Shipping_Country__c)))

Approach

1ISPICKVAL(Status__c, "Submitted") scopes the whole rule to only the Submitted status.
2OR() across all four ISBLANK() checks means the rule fires if even one address component is missing.
3AND() combines the status gate with the OR() of missing-field checks — both must line up for the error to appear.

Hard Validation

45. Validation Rule: High-Value Opportunities Require Executive Approval

Problem #491 · Salesforce Apex Coding Challenge

Problem Statement

An Opportunity has a custom checkbox Executive_Approval__c. Write a Validation Rule that blocks moving an Opportunity worth more than $500,000 into "Negotiation/Review" or "Closed Won" unless Executive_Approval__c has been checked.

Requirements

Error fires only when Amount > 500000.
Error fires only when Executive_Approval__c is unchecked.
Error fires only when StageName is "Negotiation/Review" or "Closed Won" — earlier stages are unaffected.

Formula Hint

AND(Amount > 500000, NOT(Executive_Approval__c), OR(ISPICKVAL(StageName, "Negotiation/Review"), ISPICKVAL(StageName, "Closed Won")))

Approach

1A checkbox field is already boolean — use NOT(Executive_Approval__c) directly, no ISPICKVAL or comparison operator needed.
2OR() across the two late-stage ISPICKVAL() checks means either stage is enough to require approval.
3AND() ties the amount threshold, the missing-approval checkbox, and the stage check together — all three must hold for the error to fire.

Expert Validation

46. Validation Rule: Prevent Marking an Account Inactive While an Active Contract Exists

Problem #492 · Salesforce Apex Coding Challenge

Problem Statement

Validation Rules cannot fire on delete in Salesforce — there is no delete context for a Validation Rule to evaluate, so "prevent deleting an Account with active Contracts" is not something a Validation Rule formula can implement directly (that requires a before delete Apex trigger). The realistic, formula-based equivalent is preventing an Account from being marked inactive while it still has an active Contract — which a roll-up summary field can expose to a Validation Rule.

Assume Account has a custom picklist Account_Status__c and a roll-up summary number field Active_Contract_Count__c that counts related Contracts with Status = "Activated". Write a Validation Rule that blocks setting Account_Status__c to "Inactive" while Active_Contract_Count__c is greater than zero.

Requirements

Error fires only when Account_Status__c is being set to "Inactive".
Error fires only when Active_Contract_Count__c > 0.
This rule cannot and does not block actual record deletion — only the status change.

Formula Hint

AND(ISPICKVAL(Account_Status__c, "Inactive"), Active_Contract_Count__c > 0)

Approach

1Validation Rules have no delete context — a roll-up summary count field exposed on the Account is how you make "has active Contracts" visible to a formula at all.
2ISPICKVAL(Account_Status__c, "Inactive") scopes the rule to only the status transition that matters.
3Active_Contract_Count__c > 0 is a plain number comparison — the roll-up field already did the counting work for you.

Expert Validation

47. Validation Rule: Country-Specific Tax ID Format Validation

Problem #493 · Salesforce Apex Coding Challenge

Problem Statement

Account has a custom text field Tax_ID__c and uses the standard BillingCountryCode field (ISO country picklist code, e.g. "US", "CA", "GB"). Each country has a different Tax ID format:

US (EIN): 2 digits, a dash, 7 digits — e.g. 12-3456789
CA (Business Number + RT): 9 digits, RT, 4 digits — e.g. 123456789RT0001
GB (VAT number): GB followed by 9 digits — e.g. GB123456789
Any other country: just require some non-empty value.

Write a Validation Rule that blocks saving a populated Tax_ID__c that does not match its country's expected format.

Requirements

Only validates when Tax_ID__c is populated — a blank Tax ID is a separate concern, not handled by this rule.
Uses CASE() keyed off BillingCountryCode to pick the right REGEX() pattern per country.
Falls back to a generic non-empty check for countries without a specific format rule.

Formula Hint

AND(NOT(ISBLANK(Tax_ID__c)), CASE(BillingCountryCode, "US", NOT(REGEX(Tax_ID__c, "[0-9]{2}-[0-9]{7}")), "CA", NOT(REGEX(Tax_ID__c, "[0-9]{9}RT[0-9]{4}")), "GB", NOT(REGEX(Tax_ID__c, "GB[0-9]{9}")), NOT(REGEX(Tax_ID__c, ".+"))))

Approach

1CASE(BillingCountryCode, "US", resultIfUS, "CA", resultIfCA, "GB", resultIfGB, defaultResult) lets you branch per-country in one expression.
2Each REGEX() must match the ENTIRE Tax_ID__c value against that country's expected pattern — wrap it in NOT() so the rule fires on a mismatch.
3The final CASE() argument (no matching label) is the default/else branch — use it for every country without a specific pattern.

Expert Validation

48. Validation Rule: Subscription Term Cannot Exceed 5 Years

Problem #494 · Salesforce Apex Coding Challenge

Problem Statement

A custom Subscription__c object has date fields Subscription_Start_Date__c and Subscription_End_Date__c. Write a Validation Rule that blocks saving a Subscription whose term (End Date minus Start Date) exceeds 5 years (treated as 1826 days, accounting for a leap year in most 5-year spans).

Requirements

Only validates when both dates are populated.
Subtracting two Date fields yields a whole number of days — compare that difference against 1826.
A term of exactly 5 years (1826 days or fewer) is allowed; anything longer is blocked.

Formula Hint

AND(NOT(ISBLANK(Subscription_Start_Date__c)), NOT(ISBLANK(Subscription_End_Date__c)), (Subscription_End_Date__c - Subscription_Start_Date__c) > 1826)

Approach

1Subtracting one Date field from another (EndDate - StartDate) returns a plain Number of days in a Salesforce formula.
2Guard both dates with ISBLANK() first — subtracting a blank Date from a populated one produces a meaningless result.
35 years is approximated as 1826 days (365 * 5 + 1 for a leap day) — compare the day difference against that constant with a plain > operator.

Expert Validation

49. Validation Rule: Close Date Must Fall Within the Custom Fiscal Year on the Budget

Problem #495 · Salesforce Apex Coding Challenge

Problem Statement

This organization runs a custom fiscal year that starts April 1 and ends March 31 of the following calendar year (e.g. FY2027 runs from April 1, 2026 through March 31, 2027) — different from Salesforce's built-in Fiscal Year settings. Write a Validation Rule on Opportunity that confirms whether a given CloseDate falls inside the fiscal year that contains it, by computing that fiscal year's own start and end dates directly from CloseDate.

Requirements

Derive the fiscal year's start date as April 1: if CloseDate's month is January–March, the fiscal year started April 1 of the previous calendar year; if April–December, it started April 1 of the same calendar year.
Derive the fiscal year's end date as March 31 of the year following that start.
The formula should confirm CloseDate is not before its own fiscal year's start or after its own fiscal year's end — which, by construction, is always true, so this rule intentionally never blocks a save on its own. It exists to demonstrate the fiscal-year boundary math as a reusable building block for other rules that compare CloseDate against a different record's fiscal year (e.g. a Budget's locked fiscal year field).

Formula Hint

DATE(YEAR(CloseDate) - IF(MONTH(CloseDate) < 4, 1, 0), 4, 1)  /* fiscal year start */
DATE(YEAR(CloseDate) + IF(MONTH(CloseDate) < 4, 0, 1), 3, 31) /* fiscal year end */

Approach

1MONTH(CloseDate) < 4 identifies Jan/Feb/Mar, which belong to the fiscal year that started the previous April.
2DATE(year, month, day) builds a Date from three numbers — use it to construct both the fiscal-year start (April 1) and end (March 31) relative to CloseDate.
3IF(MONTH(CloseDate) < 4, 1, 0) subtracted from YEAR(CloseDate) gives the correct fiscal-year-start calendar year in one expression.

Master Validation

50. Validation Rule: Multi-Field Guard for Large, Late-Stage, Fast-Closing Deals

Problem #496 · Salesforce Apex Coding Challenge

Problem Statement

Finance flagged a pattern of large deals being rushed to close without proper review. Write a Validation Rule on Opportunity (with custom field Deal_Desk_Review__c, a text field logging the Deal Desk reviewer's initials) that blocks saving when all of the following are true at once:

Amount is greater than $250,000,
StageName is "Negotiation/Review",
CloseDate is less than 3 days away from today, and
Deal_Desk_Review__c has not been filled in.

Any deal missing even one of these four conditions (e.g. it's a smaller deal, or it's already been reviewed) must save without error.

Requirements

All four conditions must combine with AND() — this is a narrow, specific guard, not a broad one.
CloseDate - TODAY() gives the number of days until close; use it to test the "fast-closing" condition.

Formula Hint

AND(Amount > 250000, ISPICKVAL(StageName, "Negotiation/Review"), (CloseDate - TODAY()) < 3, ISBLANK(Deal_Desk_Review__c))

Approach

1Four independent conditions across four different fields all combine with a single AND() — list them one per line for readability.
2CloseDate - TODAY() subtracts a Date from a Date, returning a plain Number of days (can be negative if CloseDate has already passed).
3ISBLANK(Deal_Desk_Review__c) is the "not yet reviewed" gate — once a reviewer fills it in, this rule stops firing for that record.

Practice All 50 Problems Free

Write and run real Apex code right in your browser — instant pass/fail feedback, best-practice linting, and governor limit monitoring. No Salesforce org needed.

Create Free Account → Explore All Problems