Ever been in the situation where a user reports s/he is getting an error message when trying to create or edit a record and when you look into the validation rule, you see a mess where we have exceptions for profiles or even specific users? And as you look further into the validation rules, you see the same group of profiles referenced over and over?

It may have started off innocently enough with one request from the business asking for that only certain profiles or users can edit this field or this record type. So, the system administrator creates a validation rule and references the profiles and user(s) in the validation rule. Then, another similar request comes along, and another. Over time, you now have several validation rules with the same exceptions “hardcoded” in the validation rule.

Now, if another system administrator, unbeknownst to him/her, has to rename a profile or deletes a profile no longer in use, s/he has broken the validation rules or has references to old profiles in validation rules. Or, if the another system administrator has to create a new profile that should also be included in the validation rules, the system administrator needs to comb through all the validation rules and modify them all to add the new profile.

Things like this make for a hard-to-maintain Salesforce organization over time.

Where possible, if we see commonalities like the above, we as Awesome Admins should follow best practices and implement this in one place so if changes need to be made, the change is made in one place and reflected everywhere it is referenced, making maintenance easier and quicker.

This can be accomplished either using custom permissions or custom settings.

• Use Custom Permissions when validation rules apply to the same profiles/users
• Use Custom Permissions with a Permission Set validation rule applies to a subset of users
• Use Custom Settings when you have several exception types, different profiles/users

 

Use Custom Permissions When It’s the Same Profiles/Users

While Salesforce provides access to certain features, objects, fields, tabs and visualforce pages with permission sets or profiles, permission sets and profiles do not include access to some custom processes and apps. Custom permissions allows you to define access to custom processes or apps by assigning them to users, permission sets or profiles.

For more information on custom permissions: https://help.salesforce.com/apex/HTViewHelpDoc?id=custom_perms_overview.htm&language=en_US

Here is an example of a validation rule that contains references to several profile names. In this Salesforce org, there are 10 validation rules, like this example, for certain fields across multiple objects, referencing these same profile names. If left this way and with more validation rules added in the future, I do not envy the admin who has to manage changes to these validation rules!

Let’s clean up these validation rules and use a custom permission to do this.

1. Go to Develop | Custom Permissions, click the “New” button and create your custom permission.

Best practice tip: Provide a detailed description with the purpose of this custom permission so it takes the guesswork out for you and other/future admins.

2. Now, let’s go back into the validation rule and clean it up. You can remove the references to the profile names and replace it with $Permission.<Custom Permission API Name>.

Your validation rule looks much cleaner now. Do a “rinse and repeat” with each validation rule that references the same profiles.

Note: You can do this with user references as well.

3. Now, we need to add this custom permission to each profile that was previously referenced in the validation rule.

Go to Manage Users | Profiles, select the Profile, go to Custom Permissions, click the “Edit” button and add the custom permission. Repeat this for each profile referenced in the validation rules.

Note: Additionally, you can add specific users to the Custom Permission. This can be achieved by creating a new permission set and adding the custom permission.

Use Custom Permissions with a Permission Set validation rule applies to a subset of users

1. Follow Steps 1-2 from Use Custom Permissions When It’s the Same Profiles/Users.

2. While you can just assign an individual user to the Custom Permission in his/her user record. To make it easier to administer/manage the users associated to this custom permission, we can manage the users in one place – assigned to a permission set.

Let’s create a new permission set that will reference the custom permission created.

Go to Manage Users | Permission Sets, click on the “New” button to create the new permission set. We’ll call it “Create/Edit Advisor Accounts.”

Best practice tip: Provide a detailed description with a reference to the custom permission so it takes the guesswork out for you and other/future admins.

Click on “Custom Permissions” under the Apps section.

Click on the “Edit” button.

On the following screen, locate the “Create/Edit Advisor Accounts” custom permissions and move it to the “Enabled Custom Permissions” side. Click the “Save” button.

3. Lastly, assign users to the “Create/Edit Advisor Accounts” permission set that you want to be exempt from the validation rule created in Step 2.

Use Custom Settings When You Have Several Exception Types, Different Profiles/Users

Developers know that Custom Settings are variables that they can use in their code, but 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.

For our purpose, we will be using the hierarchy custom settings as this is the only type permitted in validation rules.

1. Let’s create the hierarchy custom setting. Go to Develop | Custom Settings, click on the “New” button.

Best practice tip:

• Provide a detailed description with the purpose of this custom setting so it takes the guesswork out for you and other/future admins.
• Consider whether you want to make this custom setting just for validation rules or any profile/user exception for the org. For example, you can also reference custom settings to apex and allow triggers to be bypassed for certain profiles regularly or during data loads.

2. Now, we need to create a custom field to reference in the validation rule. Click the “New” button.

3. Select Checkbox as the data type, provide the custom field information and save the field.

Best practice tip: Provide a detailed description with the purpose of this custom setting so it takes the guesswork out for you and other/future admins.

4. Click on the “Manage” button to start adding profiles/users that this custom setting applies to.

5. Click on the “New” button that appears in the Setup Owner section.

6. Select “Profile” (or “User”) from the first dropdown and select the profile (or user) via lookup. Then check the box for Validation Rules. Save the change. Repeat this for every profile/user.

Once completed, create a view that shows the custom setting records you created in the custom setting.

Important Note: Because these are considered to be data, these will not migrate via change set. The data will need to be exported and inserted into Production using Data Loader post Production deployment.

7. Lastly, let’s go back into the validation rule and clean it up. You can remove the references to the profile names and replace it with $Setup.<Custom Settings API Name>.<Custom Setting Custom Field API Name>.

Note: The Custom Settings API Name and the Custom Field API Names are highlighted below.

Your validation rule looks much cleaner now. Do a “rinse and repeat” with each validation rule that references the same profiles.

Now, before you deploy the changes to Production, you need to test your configuration changes.

1. Login as a user in the profile who is associated to the custom permission, user assigned to the permission set (with the custom permission) or the profile/user associated to the custom setting.
2. Execute the steps to confirm the validation rule works as expected.
3. Repeat Steps 1-2 for each profile or user associated to the custom permission, permission set or custom setting.

Deployment Notes/Tips:

• Validation rules, custom permission/permission set/custom setting can be deployed to Production in a change set.
• Custom permission should be added to profiles post deployment. I would caution against adding the related profiles in the changeset for deployment as the results of deploying a profile are not reliable. If you have a tool like Snapshot by Dreamfactory, you can use the tool to deploy custom permissions by profile.
• If you are adding users to a custom permission or permission set, this needs to be done as a post production deployment change since users do not migrate from sandbox to Production.
• Export the custom settings data from your sandbox and update the data into Production using data loader post production deployment. Custom settings records are considered data like data held in custom fields.