Use Custom Settings in Process Builder

Do you have processes in process builder where only users of specific profiles will execute a specific action group? Imagine, as your Salesforce org grows over time and new profiles are introduced or old profiles are deprecated. Or, for whatever reason, you had to temporarily remove one of the profiles referenced. You will need to clone those process builders to add or remove the profiles. Since you are touching the process builder by adding a new condition via point and click or formula, you need to retest the process builder to ensure you didn’t break anything in the executing criteria.

Gee, that sounds like a lot of work.

What if I told you there was a simpler way? Need to add a profile? Just add it to the list and check the option for that process builder. Have to remove a profile? Just uncheck the option for that process builder.

Rather than “hardcode” the profile references in process builder, you can manage the profiles outside of process builder with the use of custom settings.

Haven’t yet had the pleasure of meeting custom settings? Let me introduce you to it…

Developers know that Custom Settings are variables that they can use in their code. They can be set and modified without needing to deploy code. Custom settings allow you to use custom data sets across the Salesforce org, or allow you to reference particular users or profiles based on custom criteria.

There are two types of custom settings: list and hierarchy.

Here are Salesforce’s definition of the two:

• List: A type of custom setting that provides a reusable set of static data that can be accessed across your organization. If you use a particular set of data frequently within your application, putting that data in a list custom setting streamlines access to it. Data in list settings does not vary with profile or user, but is available organization-wide.
• Hierarchy: A type of custom setting that uses a built-in hierarchical logic that lets you “personalize” settings for specific profiles or users. The hierarchy logic checks the organization, profile, and user settings for the current user and returns the most specific, or “lowest,” value. In the hierarchy, settings for an organization are overridden by profile settings, which, in turn, are overridden by user settings.

Hierarchy is the only custom setting type that can be used in validation rules, process builder or visual workflow.

To learn how custom settings can be used in validation rules, read my post on Simplify Maintenance of Profile or User References in Validation Rules.

Ok, now that you’re introduced, let me step you through how to set this up and use it in process builder with a simple use case.

Business Use Case: Addison Dogster is a system administrator at Universal Container. Sammy Sunshine is the Sales Director. He’s requested that when users in Retail Sales and Institutional Sales profiles makes various updates to the opportunity record, different actions will happen. If other users make updates, a different set of actions will occur. In a separate request, he has process requirements for the “Sales” profiles versus the other profiles in Case Management.

Solution: Addison is able to solve this declaratively using process builder. But, knowing that more business units will be added into the Salesforce org in the future and putting her maintenance cap on, she decided to use custom settings rather than reference the profiles specifically in her opportunity and case process builder.

Note: In this blog post, we will take the solution as far as referencing the custom setting in the criteria node.

Quick Steps:

1.Create a custom setting by clicking on the New button. I recommend you name the custom setting something that can be used for multiple reasons, rather than name it narrowly just for this process builder. In our case, Addison is going to name it “Org Exceptions.” For those using Salesforce Classic, custom settings can be found in Setup | Develop | Custom Settings. In Lightning Experience, it is found under Custom Code | Custom Settings.

For Object Name field, remember, a custom setting like a custom object. This is the API name that will be used in the custom setting references. Keep the name the same as the label. If you have a space in your label, use “_” where you have the space.

Best practice tips:

• Don’t forget to provide a description so you and other/future admins know what this custom setting is used for.

What is created after you click “Save” looks very much like a custom object.

A. Now, let’s create a custom field. In Addison’s case, she could have made her field object specific so it can be tied back to her process builder but since she has criteria that applies across multiple process builders, she decided to create a field to capture the sales profile attribute. There is no hard rule. Think about your requirements and create a field that makes sense for your scenario.

Best practice tips:

• Don’t forget to provide a description so you and other/future admins know what this custom field is used for.

Here is the end result with the newly created Sales Profile field highlighted in yellow.

For illustration purposes, I’ve added other attributes that can be used with custom settings, such as to bypass triggers, bypass validation rules or use in validation rules.

B. Set up the user profiles where the “Sales Profile” applies to. Click on the “Manage” button.

First, let’s create a new view because the default custom setting view isn’t very helpful. Click on “Create New View.”

For list view items, keep the Setup Owner and add the attributes we’ve added. In this case, it would be the Sales Profiles field. Make sure you make this viewable to all users. Save the list view.

You’ve set up your view. Now, click on the second “New” button.

Here, you can select profile(s) or user(s) to specific attributes.

In the profile field, locate the Retail Sales profile and check the box next to Sales Profiles field. Save the record.

Repeat for the Institutional Sales profile.

When you go back to the list, you can see what attributes are assigned to the user(s) and profile(s).

For illustration purposes, I’ve added a user and other profiles that can be used with custom settings attributes.

2. Lastly, we will create the process builder (Salesforce Classic – Create | Workflows & Approvals | Process Builder or Lightning Experience – Process Automation | Process Builder).

A. Name your process builder and include the description.

B. Select the Opportunity object, when created or edited, and click the “Save” button.

C. In the criteria node, this is where we would reference the custom setting. Custom settings is only accessible via the formula setup so select “Formula evaluates to true” as the Criteria for Executing Actions.

Select “$Setup”

The selection will only show those custom settings fields that are checkboxes.

Select Sales Profiles.

Select Choose.

The custom setting reference is inserted into the process builder.

There is currently a known issue: Process Builder generates a duplicate entity name when using the $Setup field API name in a formula. This is scheduled to be fixed in Summer 16 in June.

Until then, you need to manually remove the duplicate custom setting API name. Otherwise, it will not work.

If you want to use a formula where you want it to run where a user or profile does not have the Sales Profile custom setting attribute, use the syntax: NOT ($Setup.Org_Exceptions__c.Sales_Profiles__c) in the formula.

That’s it. You’ve successfully referenced custom settings in process builder.

Deployment Notes/Tips:

• The new custom setting and process builder can be deployed to Production in a change set.
• The custom settings records are data so they will need to be extracted from your sandbox via data loader and loaded into Production. If you have a custom setting called “ABCCustomSetting”, then you will see it in Data Loader as “ABCCustomSetting (ABCCustomSetting__c)”.
• Activate the process builder as it is deployed as inactive into Production.