Custom Settings: An Admin’s Playground

Last week, I showed you the amazing things you can do with Custom Permission. In my post,
Custom Permissions: The Joy of Flexibility in Validation Rules and Workflow I alluded that this functionality was something I used to use Custom Settings for.

Custom Settings still have their place in the Admin world. Like Custom Permissions, you can refer to them in Workflow and Validation Rules. Developers can also refer to them in Apex and Visualforce.

So why would use use a Custom Setting instead of a Custom Permission? What’s the difference? How much wood could a wood chuck chuck if a wood chuck could chuck wood?

I’ll answer these questions today… starting in reverse: 700 pounds

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.

Custom Setting Metadata

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.”

Manage Custom Setting

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

Validation Rule Custom Setting

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!

Showing 3 comments
  • Debbie Schoeppel
    Reply

    I have a question about the validation rule formula in your example. If the formula evaluates to True, the error message will appear telling the user that they can’t modify the Stage.  When I read the first condition, it seems to me that it will trigger the error message if they haven’t changed the Stage when it is at their Stop Stage:

    I must be missing something, so I hope you can help me understand how this condition catches them editing the Stage when it’s their Stop Stage.

    Thanks for all the valuable information you share in your blog.  I learn something from every post. Regards, Debbie S.

    From: Wizard & Friends News To: ds.dstigard@frontier.com Sent: Thursday, January 15, 2015 8:03 AM Subject: [New post] Custom Settings: An Admin’s Playground #yiv9849148815 a:hover {color:red;}#yiv9849148815 a {text-decoration:none;color:#0088cc;}#yiv9849148815 a.yiv9849148815primaryactionlink:link, #yiv9849148815 a.yiv9849148815primaryactionlink:visited {background-color:#2585B2;color:#fff;}#yiv9849148815 a.yiv9849148815primaryactionlink:hover, #yiv9849148815 a.yiv9849148815primaryactionlink:active {background-color:#11729E;color:#fff;}#yiv9849148815 WordPress.com | Salesforce Wizard posted: “Last week, I showed you the amazing things you can do with Custom Permission. In my post,Custom Permissions: The Joy of Flexibility in Validation Rules and Workflow I alluded that this functionality was something I used to use Custom Settings for.” | |

  • Salesforce Wizard
    Reply

    Hey Debbie,

    Validation rules can be tricky, they basically are the opposite of the logic. So we want the validation rule to be True when:
    1. Record is in the proper stage (or “lock” stage).AND
    2. Stage was not just changed to be that stage OR
    3. The prior value of the Stage is our “lock” stage

    So the validation rule’s goal is to prevent ANY edits once it’s in the “lock” stage. So this first part of the validation rule checks if the Stage has been changed AND if the stage (the new value) is the same as the one we want them to stop.

    So the first part will return TRUE if the Stage == Fancy_Validation__c.Stage_Value__c and the Stage HAS NOT been changed. IsChanged(StageName) will return TRUE when the stage has been edited. We’re telling the validation rule that we want that line to return TRUE only when isChanged(StandName) is false. It’s a bit backwards

    This will let a user move into the stage and then it will give them an error if they try to make any changes. The one exception is if they change the stage to be something other than their “lock” stage. That’s where the second part of the validation rule comes in. That looks to see if the prior value is the user’s lock stage. Basically, we’re creating a one way street. You can enter, but you can’t go back.

    /*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

    Does that help clear things up anymore? Or was I just as confusing?

  • Debbie Schoeppel
    Reply

    Your explanation helped. I was missing the ‘ANY edits’ part of the logic for the first part of the rule.

    I knew I had to be overlooking something.

    Thanks!

Leave a Reply