Hardcoding (directly writing a value or attribute into code, formulas, validation rules, automation, etc) comes in several forms and while many have covered avoiding hardcoding IDs (my favorite being this post by Jen Lee), I’ve seen very little written regarding the hardcoding of Profile and User parameters.
Hardcoding values like $Profile.Name, ‘$User.Department’, $User.email and others, while effective in the short term, often causes headaches and issues in the future such as:
- Attributes like Usernames/Emails can change between environments
- Hardcodes are typically text values, so there is no warning when a hardcoded value changes
- When a values change, have to track down everywhere it was referenced
- Changing hardcodes in all of those places is time consuming and unnecessary
- Every new profile, user, change in business processes, etc require maintenance and updates.
There is an easy way to solve Hardcoding Profile & User parameters though, through the use of Custom Permissions. Custom Permissions can be:
- Created in less than a minute
- Assigned via a profile or permission set
- Referenced in Validation Rules, Formulas, Workflow Rules, Process Builder, Flow, Code, Assignment Rules, AND for Conditionally filtering Lighting Page Components.
While Custom Permissions should be a must have for every Salesforce Admins toolkit, it seems this feature often goes unused. In the last few weeks I’ve run into a handful of circumstances where the users (of all experience levels) should have utilized custom permissions in their Validation Rules but instead were using a combination of Hardcoded Profile & User Attributes.
Here is an example from this week: A consultant had a request where their client wanted to allow users to take leads out of the queue, but then restrict their ability to change owner. This is possible using a validation rule, however their rule looked something like this:
AND(ISCHANGED(OwnerID),
NOT(BEGINS(PRIORVALUE(OWNERID),‘00G’)),
$Profile.Name<>’System Administrator’,
$Profile.Name<>’Some Profile’,
$Profile.Name<>’Some Other Profile’)
While the above would effective, it is not very scalable. Every time a user outside the above group should have the permission or the opposite, you would need to create a new profile or hardcode a user attribute like $User.Email=tom@theaccidentaladmins.com, the latter changes in sandbox environments and would not work.
Creating Custom Permissions is a very simple & fast process. In Setup, type ‘Customer Permission’ in the Quick Find, select the menu item, then click ‘New.’ Give your custom Label a name & a description.
Save your Custom Permission and now you can add that to any Profiles or Permission Sets you need for your requirements!
Our final validation rule would then look like this:
AND(NOT($Permission.ChangeLeadOwner), ISCHANGED(OwnerID), NOT(BEGINS(PRIORVALUE(OWNERID),‘00G’)))
Now in the future, when this client needs to add/remove profiles, they can edit the Custom Permissions or for users, they only need to assign the correct profile or permission set.
Here is another example from last week: An admin wants to restrict access to edit the Title field, however he wants all users to be able to populate that field during record creation. He correctly created a permission set to grant edit access to his targeted group of users, but was not sure how to allow ALL users create permissions.
One approach would be give everyone edit access on the field then write a Validation Rule like:
AND(NOT(ISNEW()), ISCHANGED(TITLE), NOT(User.Username=’Tom@theaccidentaladmins.com’), etc, etc)
However with a custom permission, this is a quick fix:
Create a Custom Permission called ‘EditTitle’
Assign that custom permission to a permission set.
Our validation rule is then:
AND(NOT(ISNEW()), ISCHANGED(TITLE), NOT($Permission.EditTitle)
Custom Permissions can be used in many other places and I’ll explore those use cases in the coming weeks, in the meantime questions, and thoughts are appreciated – drop them in the comments below!