Blog

Best Practices: Pros and Cons of Salesforce Required Fields

Written by OpFocus | Jan 7, 2014 12:00:00 AM

The other day, one of my clients asked me about best practices for Required Fields in Salesforce.com. Essentially, they wanted to know what the difference is between choosing to require a Field upon creation versus requiring it on a Page Layout. This is not the first time I've been asked this question, and as I love all topics related to Salesforce.com security, I thought I would take a moment to describe the differences. First, why even bother requiring Fields? This question has also come up as companies fear that using a Required Field prevents data entry. We've all been there – we’re ready to enter a new Lead or Opportunity or another key piece of information and realize we can't, because we don't have the information for a particular Required Field. When this happens too many times, often your colleagues won't bother to capture the info, and will improvise their own ways of recording the data outside of Salesforce.com. This is not a good solution for anyone. Therefore, before going through and making a bunch of Fields mandatory, be sure to consider the implications. Does the information need to be in there from the start? Or can it be added later? Alternatively, is it better to use Data Validation to make the Field required only in particular situations? These aren't always easy questions to answer from the start. Fortunately, Salesforce.com is flexible enough that you can change your mind later. Now, assuming that you've decided that this Field must be required, the next question is: do you make the field Universally Required or simply required on the Page Layout?

Universally Required Fields

An example of universally requiring a field when first creating the field.

When creating a new Field, you've probably noticed a Checkbox that says “Always require a value in this field in order to save a record.” While this is one way to make a Field required, I almost never check this. It limits your flexibility downstream. These Universally Required Fields will need to be filled in whenever doing a mass data import, and they cannot be removed from a Page Layout. Universally Required Fields also trump Field-level security. As soon as a Field is Universally Required, as a System Administrator, you lose the ability to control Read and Edit access for this Field. Salesforce.com offers a very useful page called “Considerations for Universally Required Fields” that has a great checklist of items to review before making a Field required universally. As a System Administrator, you should ask yourself:

  • Will all data imports have this Field?
  • Will this Field be used on all Record Types and subsequently all Page Layouts?
  • Do you want Users to fill in this Field when editing pre-existing records that do not have a value?

After reviewing these questions, if you feel the Field should be Universally Required, then go ahead and check the box. However, if it should only be required in some cases, consider making it mandatory only on your Page Layouts.

Required Fields on Page Layouts

As you've probably figured out by now, my preferred way to make a Field mandatory is to do so on the Page Layout. I like this approach for several reasons:

  • It still gives me control over Field-level security, allowing me to make a Field mandatory for some Users while completely hiding it from others.
  • As I build new Page Layouts and Record Types in the system, I have the ability to make it required in some cases but not others.
  • When creating new Page Layouts, I can completely remove the Field from the Layout.
  • I am able to Mass Import files, even if the Field is blank for some of the records.
Requiring a field on a page layout.

There are bound to be more reasons, but the common theme running through the bullets above is flexibility. By deselecting the “Required” box when I create the Field, I am giving myself more options for both customizing and securing the system. Regardless of which way you decide to require Fields, the good news is you can move back and forth between the two. If you make a Field Universally Required and find this is tripping up your Users, simply uncheck the box. Likewise, if it proves too complicated to manage Required Fields on Page Layouts, you can go back and make it Universally Required. As always there is a lot to think about with Salesforce.com security, and as my colleague Jesse likes to say,

“There are many paths through the forest.”

If you feel like you could use some guidance figuring out the best security practices for your organization, don't hesitate to reach out to the OpFocus team! I would also welcome your comments below on how you decide between Universally Required Fields, Required Fields on Page Layouts, and Data Validation to ensure the most important information is logged! For more information on Salesforce.com Security, please see my earlier post on the 4 Pillars of Salesforce Security: Controlling Who Can See What.

[tagline_box backgroundcolor="" shadow="yes" shadowopacity="0.1" border="1px" bordercolor="" highlightposition="left" link="https://opfocus.com/contact-us" linktarget="_self" buttoncolor="blue" button="Contact Us" title="Trust your system's security settings?" description="Let our MVPs take a look. As you can see, we love this stuff! " animation_type="slide" animation_direction="left" animation_speed="0.7"][/tagline_box]

View Our Other Helpful Salesforce Guides
View full post