When Things Are Required

"Requiring" a field can mean a whole bunch of different things and I see confusion from admins all the time. There are [at least] four ways to require fields. Let's look at them in the order I prefer to think about them:

1. On the Page Layout

The easiest and most useful place to require a field is on the page layout. Here, all you have to do is check a box and any user that creates a new record or edits an existing one will have to put a value in the field before they can save. We're all familiar with the red asterisk that designates a required question on a survey or field on a form.

If you want to be certain your users will enter a value, this is the place to require your field. Required fields are a powerful way to keep your data complete. [Of course, requiring a field doesn't ensure clean data. If users want to save a record, they'll enter a garbage value just to get past a field requirement...]

Obviously you'll have to put some thought into which fields are required on the page layout (or on which page layouts). But I don't think I need to spill a lot of ink about how to think about this.

Remember, though, that a requirement on the page layout is not imposed on record creates or edits that happen through imports and integrations. This is important to keep in mind. If an integration leaves a field blank that's required on the page layout, the next user to edit this record will be forced to fill the field. Depending on your use case this could be quite an annoyance or it could be a useful part of how the work gets done.

2. At the Database Level

The most fundamental place that you can make a field required is to set that requirement at the level of the field definition in the database.

But generally speaking, you should shy away from requiring fields this way. I often get confused clients that have created a new field and now their users can't save records. Or they are editing the page layout and can't uncheck the Required box for that field. That's because they have required the field with that innocent-looking checkbox on the field definition and they didn't the implications.

Just as the field text in the wizard implies, if this box is checked then every record must have a value in this field. Records that existed before you created the field will no longer be able to be edited without putting a value here. New records will always have to be created with a value in this field. When you put this field on a page layout it will always show as a required field. [This implies that you must put the field on page layouts as well, but there is no technical requirement that forces you to do this. Of course, if the field isn't shown or if users don't have access to the field, they won't be able to create records, since filling the field is a requirement.]

Requiring a field at the database level is very powerful. Also risky. And sometimes confusing. I recommend that you rarely require fields using this checkbox. Not never, but it should only be done with careful consideration. If you are creating a net new object it's OK to require fields this way. But you should still only do it for fields that you truly intend will always be required for the object you are creating. Remember: a field required at the database level is required in all cases. That means imports, integrations, API calls, or other non-user interface creates and edits are still subject to the requirement for this field. If you're creating a new field on an object that already exists and is in use, you need to have a plan for how all the existing records are going to get a value in this new field. If you don't fill it every user that interacts with those records is going to be unable to save. And if they interact secondarily—like by kicking off a flow, or changing a rollup summary value—then there is going to be an error because the related record can't save. This could be an error that stops the user from doing their work. Or it could be errors that you have to deal with as the admin, like form submissions failing or asynchronous rollups being unable to calculate.

Let's say you are creating an Exam object. I think it's a safe assumption that the data would be meaningless without a Date of Test field. So go ahead and require that at the database level. And, of course, who took the test is going to be pretty important, so you'll need a Student field, and that can be required. But probably the Score field should not be required at the database level.

Why not?

I often have cases where we want to enter exam records without scores to know that students took the test, but the score information isn't ready right away. If you want to do this then you can't require Score. If Score is required at the database level it will be impossible to enter any exam records in any way until you have the results. But an exam with a student and a date is still useful information because you can run a report of which students did not take the exam yet, and thus need a make-up date.

As far as that Student field, we know that fields that relate one record to come in two types: lookup and master-detail.

One main difference between the two types is that master-detail fields are always required at the database level. It actually says this in the field type description. Master-detail fields define a "parent-child" relationship and I think that's a useful metaphor. It is not possible for a child to exist without a parent or (two). Lookup fields are not "parent-child," they're a little looser and, therefore, don't have to be required at the database level. They come with choices about how the database should respond to deletion of the record being looked-up to.

You could make a lookup required and then choose the "Delete this record also" option and you now have as tight a relationship as exists for a master-detail field. But the flip side is that you could not set a lookup to be required and then you could allow deletion of the related record to just clear the lookup field.

Going back to our Exam object example, either of these field types is equally good for the Student field. If you select Lookup, setting it required at the database level is still probably valuable: I can't see how the exam record would be useful if you didn't know who took it because that student has been deleted from Salesforce!

By the way: A field required at the database level will always be have a greyed out check in the Edit column when you're looking at that field in the object settings for profiles and permission sets, even if this profile/permset has no access to the object.

Here's the logic: If this profile/permset were to grant create or edit access to that object then the user must be able to edit that field, since the field is required in all cases. Imagine if you tried to grant someone Create/Edit on Account but tried to keep them from editing the Name field. How would that work? Of course, if the profile/permission set isn't granting object-level Create or Edit then no fields are editable. But if it grants Create or Edit, edit for this field has to come along for the ride.

3. Validation Rules

Requiring a field with a validation rule will (unless you specify otherwise) apply equally to the user interface and to integrations and imports. So perhaps you have reasons not to set a field required at the database level. But you are going to require the field on the page layout and you also want to require it on all imports. A validation rule is a great tool for this.

The real beauty of validation rules is that they can be much more flexible than just "fill this field." You can write a validation that requires one field if another is filled. Or, conversely, requires that one be blank unless another is filled. I regularly do this kind of thing with the Payment Date field on NPSP's Payments object. I want that field blank if the payment isn't paid.

But if it is, I want to ensure I get the date.

4. Before Save Flow with Custom Error Message

(This should maybe only be numbered 3.5.)

A relatively recent feature that works similarly to validation rules is a before save flow with a custom error message. Fundamentally, I'd call these a fancy and more-modern type of validation rules, in that they can prevent saving if a record doesn't meet your criteria and can display a message to the user so they can fix the data.

What makes before save flows even better than validation rules is that you have all the power of Flow to go into checking if the data meets your requirements. A validation rule is just a formula and, therefore, is limited to formula functions and spanning lookup relationships to see related data. In a before save flow, on the other hand, you can look up other records (such as child records), run calculations or comparisons, or do just about anything else you can imagine before showing the user a message. There's a huge amount of power here!