Skip to main content
New tool CRON Expression Builder — preview next run times before you schedule Apex. Open the builder →
3D rendered gear with circuit patterns representing Salesforce validation rules and data integrity.
Admin

Salesforce Validation Rules: Sales & Service Examples

Working validation rule examples for Sales Cloud and Service Cloud, with the formulas, to stop common data entry errors before a record saves.

Key takeaways Validation rules hold data integrity in place without any Apex. Tailor them to the object and the business process in Sales and Service Cloud. Enforce only data a user can realistically provide or work out. Think through the edge cases and the bypass routes, administrators and integrations among them, before you turn a rule on.

Enforcing data integrity with validation rules

Validation rules keep incorrect data from being saved to a record, and they do it without Apex. The examples below cover Sales Cloud (now Agentforce Sales) and Service Cloud (now Agentforce Service).

Sales Cloud (Agentforce Sales) validation rules

Sales reps do a lot of the data entry, and a validation rule can steer them toward accurate values. Aim the rules at data a rep can realistically capture or work out from a customer conversation. Do not enforce fields that need an external lookup or a data enrichment service.

Information required by account type

This one varies the requirement by the Account Type picklist. For Customer accounts, the billing address fields are mandatory.

AND(
  OR(ISBLANK(BillingStreet), ISBLANK(BillingCountry), ISBLANK(BillingCity), ISBLANK(BillingState)),
  (Text(Type) = "Customer")
)

To key off the Account record type instead, substitute (Text(Type) = "Customer") with (RecordTypeId = '[INSERT RECORD TYPE ID]').

Country validation

Standardized country names keep the data consistent. Neither of these is a validation rule formula, but both are worth a look:

  • The Salesforce custom address field, which suggests addresses as the user types.
  • AddressTools on the AppExchange, an app built for address validation and standardization.

Required fields for lead conversion

Make sure the contact and qualification information is there before the Lead converts.

IsConverted && OR(
  ISBLANK(Phone),
  ISBLANK(Email),
  ISPICKVAL(Rating, "")
)

Required fields for closed won opportunities

Same idea on the Opportunity side. Require the fields when it is marked Closed Won.

IsWon && OR(
  ISBLANK(Phone),
  ISBLANK(Email),
  ISPICKVAL(Rating, "")
)

Accounts created only through lead conversion

This rule blocks direct Account creation, so every new account comes from a qualified Lead.

First, create a formula field on the Lead object that captures the Lead Created Date, and map it to a date field on the Account, LeadCreatedDate__c for example.

Then the Account validation rule:

ISBLANK(LeadCreatedDate__c)

One open opportunity at a time

Keep an Account to one active Opportunity before a new one can be created.

First, create a roll-up summary field on the Account that counts open Opportunities, where IsClosed is false.

Then the Opportunity validation rule:

Account.NumberofOpenOpportunities__c > 1

Won opportunities must have an amount greater than 0

Keep a zero or blank Amount off a Closed Won Opportunity so the reporting adds up.

OR( ISBLANK(Amount), Amount <= 0 )

Contract end date must be after the contract start date

Enforce a sensible date order on the contract.

StartDate > EndDate

Order products cannot be modified for "Activated" orders

Once an Order is activated, its Order Products stop being editable, which keeps the transaction intact.

ISPICKVAL(Order.Status, "Activated")

Service Cloud (Agentforce Service) validation rules

Service agents have to capture specific information for the audit trail and for the other departments reading it. Validating early keeps case management simpler.

Cases cannot be edited when owned by a queue

This blocks edits to a Case while it is still assigned to a Queue, which pushes agents to take ownership first.

LEFT(OwnerId, 3) <> "005"

005 is the object prefix for User records. The formula checks whether OwnerId starts with 005; if it does not, the owner is taken to be a Queue. The same rule works on Lead queues.

Case origin cannot be edited

Lock the Case Origin field once the Case has been created.

ISCHANGED(Origin) && NOT(ISNEW())

If case status is not "New", the contact cannot be blank

Require a Contact on the Case once its Status moves off New.

NOT(ISPICKVAL(Status, 'New')) && ISBLANK(ContactId)

Required fields to close a case

Require specific fields, such as Reason, Type, Subject and Description, when a Case is closed.

IsClosed && OR(
  ISPICKVAL(Reason, ""),
  ISPICKVAL(Type, ""),
  ISBLANK(Subject),
  ISBLANK(Description)
)

To enforce the requirement at a different stage, use the Status field instead of IsClosed.

Closed cases cannot be modified

Block any change to a Case once it has been closed.

IsClosed

For a reopened issue, create a new Case and link it through the Parent Case field.

Originally reported by salesforceben.com

Newsletter

One email every Tuesday

New guides, tool updates, and the release-note changes that break things.

No spam. Unsubscribe in one click.

Comments

Loading comments...

Leave a Comment