Creating fields and managing page layouts is often one of the very first things Salesforce Admins learn to do. There are a few reasons for this – it’s fun, it’s pretty easy, and there’s instant gratification. A new field can be created by a brand-new beginner and added to a page layout in just a couple of minutes. If you have a fast org and a good internet connection, you might even be able to beat the 60-second mark.
However, because new fields are quick and easy to create, this also happens to be one of the first areas that new admins get into trouble. New fields have a lot of options, and doing something wrong is just as easy as doing something right. Salesforce isn’t going to warn you about best practices when creating a new field, after all. It gets created, and then it’s done. What happens next is between you and the users. So, rather than go into every single field, their use cases, and best practices, we’re going to go over the most common request for any field type: how to make a field required. Let’s dive in!
Page Layout
Making a field required on a page layout is probably the most common way to make a field required. It’s also pretty user friendly – the user sees a red asterisk next to any required field, and cannot proceed with any edit or create an action without filling out the field. One thing to note about page layout field requirements is that they are UI based – integrations could still make updates to a record, or create records, even though they’re missing this required field.
Lightning Record Page
Making a field required on a Lightning record page is essentially the same as doing so on the page layout, and the considerations and use cases are the same too – although it’s worth noting that the experience is slightly different for Lightning in comparison with Salesforce Classic.
What makes the difference here is knowing what type of page your users are interacting with. If you’re using a “Details” component on your page, then the field should be required with a page layout. If you’re using something like a field set component on a Lightning page, you would set the field to “Required” in that field set.
Global Action
Global actions are effectively the same as a page layout or a Lightning record page. The behavior is the same (red asterisk in the UI). I’m making a special point to mention them here because they’re so frequently forgotten. If you’re going to make a field required on a page layout or Lightning record page, make it required on the global action too (if one exists).
Field-Level Requirement
A field-level requirement is a more strict form of field requirement. This type of requirement makes sure that a field is never left blank under any circumstances. Integrations will respect this requirement, and will fail on any field that is missing this requirement. The UI behavior here is also a red asterisk, and users will always be forced to fill out the field. To users, there appears to be no difference between a field-level requirement and a page layout or Lighting page requirement.
Validation Rule
For me, validation rules are probably the most rare use case for making a field required. I call them out here only because it is possible. While you probably wouldn’t use a validation rule exactly like this, I think it’s important to mention. This option is the only one with a different UI behavior; the user will see nothing until after they fail to populate the given field – then, they will get a generated error message that you control.
Until that point, though, the field does not appear to be required. The more likely use case here is that a field is required, but only under certain conditions. For example, “Account Tier” might be required only when an account becomes a customer.
I know that is a lot to remember, but it’s important to understand the implications of each of these types of field requirements. To make it easier to remember, I’ve collated the key information in this handy table.
| Method | Where It’s Used | Considerations | When to Use | User Experience |
|---|---|---|---|---|
| Field Level Required | In the setup of that field. | Also blocks integrations and CSV imports. | When the field should be filled out every single time by every single user and integration. | A red asterisk appears next to the field. No users can proceed without populating a value. |
| Field Set | Used in Lightning on a Lightning Record Page. | Page Layout requirements do not apply to API integrations or bulk CSV imports. | When a field is required for users but not necessarily required for an integration user. | |
| Page Layout | Using Classic and in the Details component on a Lightning Record Page. | |||
| Global Action Layout | In the layout of a Global Action. | People often forget to make things required here! | ||
| Validation Rule | On any field (or combination of fields). | Error messages can be confusing, incomplete, or misleading. Can be frustrating for users because there is no asterisk warning. Validation Rules can be written to include or exclude certain users. API integrations have to meet Validation Rule criteria, unless specifically excluded. | When you want to display a particular error message to users, or you only want the field required under certain conditions. | There is no immediate visual indicator for the user. A red error only appears once the user fails to meet a certain criteria. Error messages are created by the admin. |
Summary
I hope all this was helpful! Making a field required can seem like such an easy task, but making the wrong choice here will have a huge impact on your users. Field requirements are some of the most obvious things your users are going to notice in Salesforce, and often generate the most complaints!
Setting field requirements up correctly will save you from mountains of bad data in the future, and guide your users to doing the right thing in the right way – not only the first time, but every time going forward.