Allow Certain Users to Edit Data Using Custom Permissions in Validation Rules

In a previously published blog post, Why You Should Add Custom Permissions to Your #AwesomeAdmin Tool Belt, I introduced you to custom permissions. This feature has been around since Winter ’15 but remains fairly unknown and underutilized by the admin community. Admins can use this superpower to lock or unlock user access to apps or processes.

In this blog post, we’ll focus on how admins can use custom permissions in validation rules to either permit or deny a user from bypassing the validation rule.

Business problem

Amanda Merkle, Operations Manager, approached admin Addison Dogster and noted that all users are currently able to edit accounts categorized as advisor accounts, which should not be the case. Only selected Operations and Customer Service Rep (CSR) users should have the ability to edit advisor accounts — they should be off limits to everyone else.

The solution

Addison immediately thought of using a validation rule to prevent people from updating these advisor accounts, but she didn’t want to hard code users as the exception. Hard coding references will cause maintenance issues down the road as users change over time. Addison would have to modify the validation rule each time a user is removed or added. (Check out the Why You Should Avoid Hard Coding and Three Alternative Solutions blog post for more information.)

A better design is to use a custom permission to grant selected users access to edit the advisor accounts. As noted in the Why You Should Add Custom Permissions to Your #AwesomeAdmin Tool Belt blog post, in order to grant a custom permission to a user, it must be associated at the profile or permission set level. In this case, since Addison needs to grant access to selected users in the Operations and CSR profile, she needs to associate the custom permission in a permission set which she will then assign to the selected users.

In summary, Addison’s solution comprises of:

• A custom permission
• A permission set
• A validation rule

Addison first creates the custom permission. In Setup, search for ‘Custom Permissions’ in the Quick Find box. Create a new custom permission. Provide the label, name (API name), and description. The description should further describe the purpose of the custom permission and possibly where it’s used.

Addison creates the custom permission with these attributes:

• Label: Edit Advisor Accounts
• Name: Edit_Advisor_Accounts
• Description: Gives the ability to edit advisor accounts.

Next, she associates the custom permission to the permission set. In Setup, search for ‘permission sets’ in the Quick Find box.

Addison creates a new permission set with these attributes:

• Label: Ability to Edit Advisor Accounts
• API Name: Ability_to_Edit_Advisor_Accounts
• Description: This contains the custom permission that allows users to edit advisor accounts
• License (optional): You can select the specific license to use.

Then, Addison enables the custom permission by adding it to the permission set.

Now, any user she assigns to the permission set will automatically get the custom permission.

Lastly, Addison creates the validation rule that will only permit users with the custom permission to edit advisor accounts. The advisor accounts in Addison’s org are accounts with the Advisor record type. In Setup, navigate to Object Manager | Account | Validation Rule.

She creates the validation rule with these attributes:

• Rule Name: Selected_Users_Can_Edit_Advisor_Accounts
• Active: Checked
• Description: Only users with the Edit Advisor Accounts custom permission can edit Advisor accounts.
• Error Condition Formula:

/*The account record type is ‘Advisor’*/
RecordType.DeveloperName =”Advisor” &&
/*User does not have the custom permission ‘Edit Advisor Accounts’*/
NOT ( $Permission.Edit_Advisor_Accounts )

This error condition checks whether the account record type developer name is Advisor AND that the user does not have the custom permission with the API name Edit_Advisor_Accounts. If this is true, it will display the validation rule error. However, for any user with the custom permission, no validation rule error will be displayed.

Pro-tip: Awesome admins reference the developer name or API names when possible as opposed to the field label, as the field label is more subject to change than the API name. You can also add comments in your formula to describe it by using “/*<description>*/.”

• Error Message: You do not have the ability to edit advisor accounts
• Error Location: Top of Page

The below animated gif shows the quick configuration of enabling the custom permission in the permission set and referencing the custom permission in the validation rule.

Business results

With the implementation of this solution, Addison was able to enforce cleaner data by only allowing selected individuals the ability to update the advisor accounts. By referencing the custom permission in the validation rule, Addison implemented a better design that avoided hard-coded permission management in the validation rule. Rather, permission management to edit advisor accounts is done via permission sets, which can be delegated to non-system administrators to manage.

Addison assigned the Edit Advisor Accounts permission set to Jared Dunn. Jared is able to edit the advisor account without issues as he has the Edit Advisor Accounts custom permission, so the validation rule does not fail when it executes. However, when Addison tries to edit the advisor account herself (Note: She is not assigned to the Edit Advisor Accounts permission set), the validation rule error is shown, prohibiting her from modifying the account record.

Now, it’s YOUR TURN!

Now that you know how to configure a custom permission in a validation rule, I want you to try this yourself. I’m sure you have use cases where this admin superpower can come in handy. Share with us how you use custom permissions in a validation rule to grant or deny access to your users on Twitter using #AwesomeAdmin.

Resources

• Salesforce Security Guide: Custom Permissions
• Salesforce Admins Blog: Why You Should Add Custom Permissions to Your #AwesomeAdmin Tool Belt
• Salesforce Admins Blog: Why You Should Avoid Hard Coding and Three Alternative Solutions