Custom Settings: An Admin’s Playground

The Difference

A Custom Permission is really just a Label, a special record that can be tied to Profiles and Permission Sets. A Custom Setting is more like a Custom sObject in “lite” form. Unlike true Custom Objects, you cannot create picklist or lookup fields. You can create text, email, checkboxes and most other primitive types.

Custom Settings cannot be attached to Profiles in the same manner as Custom Permissions. Depending on the type of Custom Setting (more on that in a moment), a Custom Setting is either completely unassociated to anything or you can associate individual records of a custom setting to a Profile or User.

There are two types of Custom Settings:

• List
• Hierarchy

You can read the exciting paragraph long definition of each here.

My definition:

List Custom Setting: Great for creating static records of data. Particularly useful in Apex Code and Visualforce. Cannot be used in Validation and Workflow Rules

Hierarchy Custom Setting: Great for Validation and Workflow Rules. Requires referencing a User or Profile.

How we would use a Custom Setting

In our Custom Permission scenario, we wanted to block all edits unless you had a specific Custom Permission assigned to you. What if we wanted to block edits at certain stages for different users? We could use Custom Permissions for this, but it’ll require creating multiple validation rules or very complicated and long ones.

Enter, Custom Settings. First, we need to create our Custom Setting. You’ll find them under the Develop menu in setup.

You create it similarly to creating a new Custom Object. In this example, I’m creating a Custom Setting called “Fancy Validation” and I have a single custom field for the “Stage Value.” Since we are going to be using this in a Validation Rule, we’re creating a Hierarchy Custom Setting. We’ll leave the Lists for the Apex folks and a different post.

Once you’ve created your object, we need to add the equivalent to records to our Custom Setting. We do this by clicking on “Manage.”

There are two parts to managing a Hierarchy Custom Setting. One option is to create a Default Organization Level. This will be the value for any Profile or User that is not specifically listed in the bottom section.

The second part is creating a record for Profiles and Users. In my example, if you have the System Administrator profile, your “stop stage” will be “Value Proposition.” If you have the Custom: Sales Profile, your stop stage is “Closed Won.” Unless you happen to be Frosty TheSnowMan and which case your stop stage is “Prospecting.” Everything else the Global default is for the Stage “Closed Lost.”

That’s it for our Custom Setting. Let’s see it in our validation rule.

In my scenario, I want people to be able to make updates and move the stage INTO their “Stop Stage” but then not be able to make further edits. I also don’t want users to be able to change the stage. Afterall, if they could change the stage they could then just make whatever edits they want and move the stage back.

So I my Validation Rule will have two steps. First, I’m going to see if the Stage is that user’s stop stage and whether the stage was just changed. Second, I’ll check if the prior stage was their stop stage.


/*Allow user to change stage TO X but */
/*Do not allow edit when stage is X*/
(
Text( StageName )= $Setup.Fancy_Validation__c.Stage_Value__c
&&
IsChanged(StageName) = false
)
/*Do not allow user to change stage when it was X*/
/*Those sneaky buggers*/
||
text(PRIORVALUE(StageName)) = $Setup.Fancy_Validation__c.Stage_Value__c


The end result will mean I can move my Opportunity to be “Value Proposition” but then I will no longer be able to make any edits. This includes editing the stage.

Wrap Up

Custom Settings and Custom Permissions both have their place. For simple “exceptions” I’ll lean towards Custom Permissions. For more complicated scenarios, Custom Settings is a great option.

Another example when you may decide to use Custom Setting over a Custom Permission. Let’s say I had many different Opportunity Validation Rules. I have rules to:

• Prevent Edit on Closed Won
• Prevent User from Setting Closed Won
• Prevent User from “Back Staging
• Prevent User From Editing Closed Lost

And so forth. Each with a different set of exceptions. For example, I may be able to edit Closed Won, but not Closed Lost.

I could use many Custom Permissions for this. Or I could create a single Custom Setting with a checkbox for each validation rule. In the validation rule I just need to check to see if the appropriate box is checked or not. If it is checked, they get an exception.

This way I can manage and see all the users who have special Opportunity exceptions across all my validation rules. To make an update I just need to change checkboxes or add a new Profile or User to the Custom Setting.

What are you thoughts? Are you more likely to use a Custom Setting or a Custom Permission? Let me know in the comments!