Are you using profile IDs in your validation rules? It’s a very common practice to circumvent validations under certain circ*mstances. Adding the Admin profile id to a validation lets admins get around validations. It’s a popular way to set your org up.
The Problem
The problem? There are several. First, deployments can be much more difficult. If you’ve ever deployed a change set, only to have a bunch of
FIELD_CUSTOM_VALIDATION_EXCEPTIONerrors, you know the pain it can cause. Another issue is scalability. As more users may need to be included in the exception criteria, the validation rule gets more messy. Especially if the rule already has complex logic. Lastly, unit tests exist for a reason. Having to disable validations in order to pass isn’t a good practice.
So what should you do instead? Use custom permissions!
Custom Permissions in Validation Rules
Custom permissions can be referenced in validation rules. The permissions can be assigned to profiles or permission sets, making it easy to control who can bypass rules. Add the custom permission to the validation rule, then you can modify access without touching the rule again.
Sounds good, right? So how do we set it up? The good news is that it only takes a few simple steps.
- Create a custom permission.
When creating these permissions, you should follow some best practices. Make sure to use a label and description that are descriptive and helpful. You’ll want it clear what it does.
2. Add the custom permission to a validation rule.
In our sample validation rule, we’re checking that an opportunity has been approved before being moved to Closed Won.
AND( ISCHANGED(StageName), ISPICKVAL(StageName, "Closed-Won"), NOT(Approved__c), NOT($Permission.Bypass_Opportunity_Approval))By adding the NOT($Permission….) to the end of the criteria, anyone who possesses the custom permission will be able to get around this validation rule. This logic essentially says “if the user doesn’t have the permission, fire the rule”.
3. Assign the permission to appropriate users.
In profiles or permission sets, you can add the custom permission(s).
I prefer permission sets for controlling this access. I feel that it gives me more control on exactly who can/can’t bypass rules.
Conclusion
Converting your current validation rules from profile ids to custom permissions may take some time. Depending on how widespread the practice is, you’ll need to make a plan. But it is well worth the time to have a cleaner solution.
This method does allow you to create really dynamic permission sets in your org. Does your sales ops team need some specific bypass capabilities? How about finance?
Have you tried this in your org? If you have any tips or questions, please leave them in the comments below.
