Beyond Validation Rules: A Guide to Making Things Required in Salesforce

Validation rules are one of the oldest features in Salesforce. As such, I think people (or admins, myself included) got in the habit of using them to make things required, even when they may not be the best option. However, the years have come and gone, and Salesforce has made many enhancements in Salesforce. Validation rules are no longer necessarily the best way to make something required. 

The options have expanded, and we can now create a much better working experience for our Salesforce users. In this article, we’re going to discuss what those other options are, and what the best use cases are for each. I’ll guide you through a few examples to help understand when to choose which option and include a few special considerations. 

What’s Wrong With Validation Rules?

Like most things in Salesforce, there’s nothing “wrong” with validation rules – they mostly just do exactly what they intend to do. 

The problem is when they’re used for the wrong use cases, or when the requestor doesn’t understand exactly what they have asked for. Let’s say a sales manager says, “All Leads should have a phone number. We can’t possibly sell to a prospect without a phone number! Create a validation rule to require phone numbers on Leads”.

Sure, that’s not a problem – it’s a pretty easy validation rule: ISBLANK( Phone )

In my experience, the complaint emails or Slack messages start coming in within 24 hours of implementation with rules like this. The conversations almost always goes:

Marketing Manager: “Why is the Marketo/Hubspot integration failing? None of the Leads are going into Salesforce.” 

Admin: “The Lead is missing a phone number, and phone number is a required field as of yesterday. Talk to the sales manager, it was their idea.”

Sales Manager: “I wanted that required for the sales people to enter – not that it comes from Marketing.”

Admins should immediately recognize a few problems in this scenario. The admin did not clarify with the original requester what the purpose of the requirement was, and what the use case would be. They also made a change without checking any integrations or impacts first. 

So why is this validation rule the wrong choice in this scenario? This particular validation rule requires a phone number on all Leads, all the time, always and forever. That is not what the sales manager wants. The sales manager wants a phone number to be required in some scenarios, but not others. 

A significant point to remember for validation rules is that they are “system” requirements – they apply to everyone, everything, and always whenever the criteria are met. That includes users, integrations, and even flows. These things can all fail because of validation rules. 

Orgs are also limited to 50 validation rules per object. That sounds like a lot, but when you start having large, global Sales teams, you can run out of validation rules on opportunities pretty quickly. 

Another drawback is that the user doesn’t know about the requirement until after they click save – there is no visual indicator to the user of the particular requirement.

So, how do we make things required without validation rules? Luckily, Salesforce gives us multiple options.

Page Layout

I mention Page Layouts here because many orgs have not migrated over to Lightning Record Pages with field sections yet. In Page Layouts, you can select a particular field to be required. This is a good choice for making a field universally required for users. 

The nice thing about it is that your integrations (in this example, like Marketo and Hubspot) and Flows don’t actually look at the page layout field requirements, so they can still do any inserts or updates as needed. 

Lightning Page Requirements

Making a field required on a Lighting Record Page is the same as making it required on the Page Layout – the requirement will apply to whoever uses that page, and won’t hurt your integrations. 

System Requirement

Similar to validation rules, if you do have a custom field that does need to be hard required, all the time, even for integrations and flows, you can set that requirement directly on the field itself. 

For example, if “Date of Birth” is required for all records, you can set that right when creating or editing the Lead. The impact here is the same as a validation rule, however, it doesn’t count against the limit of only 50 rules. Using this method will allow you to save validation rules for more complicated situations.

Making a Field Sometimes Required

These examples above have all been good for making a field required all of the time (or most of the time, excluding integrations). What should we do though, when we need a field to be required only in certain scenarios, but not in others?

Let’s stick with Leads for this next example. We’ll start with a custom field called “Meeting Date”, and a Lead Status called, “Qualified” (which also happens to be a converted Status.) Our requirement is that whenever a Lead becomes “Qualified” or higher, the Meeting Date must be completed.

A hard system requirement won’t work, because the request is only for Leads that are in “Qualified” or higher – which doesn’t apply to all Leads. The standard Page Layout wouldn’t work either, because it doesn’t include the nuance of only “Qualified” or higher. 

The remaining options in this case are a Lighting Record Page and a validation rule. Which choice is better depends on your situation and requirements. 

Since a validation rule could potentially cause your marketing integration to fail, I’m going to stay away from those unless absolutely necessary. It might be unlikely that a pre-qualified Lead will come in from the integration, but not completely impossible; if it does happen, we don’t want it to fail.

That leaves us with only the Lighting Record Page requirement, with the addition of Field Visibility.

On the Lighting Record Page, we can make the field required and set up field visibility so that the Meeting Date field only appears when the Lead is in “Qualified” or higher. As it’s only visible in that scenario, it’s also only required in that scenario.

This Lead is not in Qualified, and the Meeting Date field is not visible:

Once the Lead becomes Qualified, the Meeting Date field appears with a red asterisk to indicate it is required:

If left blank, the user receives an error message:

After save:

What I love about this method is that the user gets a warning before attempting to save the record – they’re immediately informed that the Meeting Date is required. A validation rule would give you the same error message, but would not show the required red asterisk before save.

Other Considerations

In some cases, you may have multiple Lighting Record Pages or multiple Page Layouts for different Profiles, or groups of users. If there are multiple layouts, keep in mind that you can customize the requirements on those different layouts as needed for those specific teams.

How to Decide

I’ll share a couple of things here that help me decide which kind of requirement to implement for each request I get. 

This is a shortcut chart to indicate what the potential impacts are of each requirement method:

After doing this for many years, here are my own general rules:

Global Actions and Email Integrations

A major problem I see with field requirements is that sometimes, you’ll see records pop up that don’t meet the minimum requirements. Even when you click on the record itself, you might see the red asterisk, knowing it’s a required field, but it’s still blank. 

You’ll probably ask: How did this user create the record without that field? It’s required! 

Global Actions and Email Integrations are usually the main culprits here. 

In this screenshot, we see there are many options for new records. If you need to make a field required, don’t forget to consider small, less-used creation methods as well.

Final Thoughts

If it sounds like this article is bashing validation rules, I’m really not! They have a place in Salesforce and can be used to make some very specific and interesting requirements. 

But as an admin, there are two things that I really dislike –  integration failures caused by the tool I manage, and, even if you excluded your integration user from a particular rule, there’s still no visual indicator to the user that an error message is about to appear.

I hope that this information helps admins to make more informed decisions about how to make fields required in Salesforce and help your users have a smoother work experience.