Custom Settings For Clicks Not Code

If you work on the clicks side of the force and you haven’t heard of Custom Settings and the cool things you can do with them using declarative functionality then this is the blog post for you! There are also many other great blog posts for you out there and a few Dreamforce sessions as well. Why should you keep reading this particular blog post and not crawl off down the internet rabbit hole I just dug for you? Because I’m going to explain what Custom Settings are and then document three examples of how you can use them with clicks not code, but more importantly, my examples are kind of funny… I hope.

What are Custom Settings?

Custom Settings, like Custom Objects., have custom fields that allow you to create records that contain data. However, unlike Custom Objects, Custom Settings can be accessed in any formula, workflow rule, and process builder organization-wide. Custom Settings are indeed settings for your org or application!

There are two types of Custom Settings:

• List: Let you create and populate set of data contained in fields much like custom and standard objects. With List Custom Settings, you can create a series of records with fields that contain data in list. List Custom Settings are available org-wide and do not let you specify a profile or user.
• Hierarchy: Let you use hierarchical logic to specify settings for specific profiles or users. When a Hierarchy Custom Setting is referenced, first the organization level is checked, then the profile, then the user. The lowest value is returned. Declarative functionality can only reference Hierarchy Custom Settings.

It is important to note that Custom Settings use records that contain data, which need to be re-created manually for deployments to production or for non full sandbox refreshes. Yes, this is kind of annoying, which is one of the reasons, I assume, SFDC developed Custom Metadata Types, which unfortunately aren’t available for declarative use yet. Expect a blog about using them in Validation Rules as soon as that forward looking statement comes to fruition.

How can I use Custom Settings?

You can use Hierarchy Custom Settings with multiple fields as needed to manage user/profile settings in your org that can be referenced by formulas, workflow rules, and process builder. You can also reference just the default organization level values in a Hierarchy Custom Setting without specifying settings for specific users and profiles and use Hierarchy Custom Settings in a similar manner to List Custom Settings.

To Create Custom Settings go to Setup>Develop>Custom Settings and click New. Enter a label and description, since this is for declarative, use the setting type of Hierarchy.

For the following examples I created a single Hierarchy Custom Setting called Profile/User Settings:

Example 1: The life raft in a sea of validation rules

As the system admin you just built a bunch of automation that does really cool things. You need to test the automation just to make sure it works without filling out all the required fields that your 50 opportunity validation rules demand.

1. Create a checkbox field in your Profile/User Settings Custom Setting called “Bypass Validation Rules”
   
2. Use the Bypass Validation Rules custom setting in all your validation rules so that validation rules only apply when this custom setting field is set to false for the running user.
   
3. Manage your custom setting records. Set the Organization Level to false for the Bypass Validation Rules field and true for yourself.
   

Now any validation rules that reference your custom setting will not apply to you. You’re free to build and test like you should be. You can also use this for data migrations or adjustments and for any external integrations that sync data back and forth but you don’t want running up against validation rules.

Example 2: Keeping your unruly sales team in check

Sales Development Reps and Account Executives both prospect and create opportunities. The SDRs are power hungry and unruly so they keep trying to work opportunities when they should be assigning qualified opportunities to Account Executives.

1. Create a checkbox field in your Profile/User Settings Custom Setting called “OppVal: Cannot Progress Stage” Make sure to use the description to specify that this setting references a specific validation rule on the Opportunity object.
   
2. Create an Opportunity Validation Rule called “Cannot_Progress_Stage”. In your formula, make sure the criteria includes the OppVal: Cannot Progress Stage Custom Setting field must be true. Now this validation rule will only apply to running user’s with this field set to true.
   
3. Manage your custom setting records. Set the Organization Level to false for the OppVal: Cannot Progress Stage field and true for the Sales Development Rep profile. (Note: if your org is small and your sales team shares one profile, you can set this to true for individual users rather than profiles). Now this Validation rule will only apply to users with the Sales Development Rep profile.
   

Now if I log in as a Sales Development Rep and attempt to progress the stage beyond Qualified I get a snarky error message.

Example 3: One process to rule them all

Sales Development Reps and Account Executives both prospect and create opportunities. The SDRs have an SLA to qualify any newly created Opportunity within 10 days or it gets re-assigned. AEs have more on their plate (office ping pong championships and I guess also demos), but we don’t want to discourage them from prospecting, so they have an SLA to qualify any Opportunities they create within 30 days.

1. Create a number field in your Profile/User Settings Custom Setting called “Opportunity Prospecting SLA”
   
2. Create a process to set the SLA Expiration Date when a new Opportunity is created.
   
3. For your Criteria, make sure the stage is Qualified on create and that there is an SLA value assigned to the running user.
   
4. Create an immediate action to set the SLA Expiration Date field to Today + whatever number of days is specified in the Custom Setting field.
   
5. Manage your custom setting records. Set the Organization Level to null for the Opportunity Prospecting SLA field. Set the value to 10 for Sales Development Rep profile and 30 for the Account Executive profile.
   

Now if I log in as a Sales Development Rep and Create a new Opportunity in the Prospecting Stage, the SLA Expiration Date is automatically set to 10 days from the created date.

The best part is that if you want to adjust the SLAs in future or add SLAs for additional Users or Profiles, you do not need to edit the process, just update the values in the custom setting or create new records. This is much more efficient than cloning processes and changing criteria.

Thanks for sticking with me. Now hopefully you feel more empowered to use Custom Settings in your org. These are just a few examples. To learn even more Click Here