Salesforce.com introduced Custom Permissions with the summer’14 release. Custom Permission enables the user to set permissions and access levels just the way he wants, quite helpful when you are developing products using Salesforce. Developers around the world have taken a fancy to Custom Permission as it is a more generic, yet an appropriate approach to fulfil requirements. Let me illustrate how you can take advantage of custom permissions.
Suppose you are developing a Loan-Based product for your client where you need to update the Account status as Closed when the opportunity gets declined for that particular Account. This is quite simple to achieve. All you need to do is to write a trigger to update the Account. However, there’s a slight catch! Client wants that the Opportunity Status should only get updated by users with Loan Manager or Senior Manager roles and the System Administrator should also be restricted to update that field. How do you achieve this?
There are a few possible approaches that you would take:
1. Permission sets – One way to address the issue is to use Permission sets. Users are restricted to edit the permission sets from the package, so if the users wants to add/ modify permission sets, a new version of the package would need to be created.
2. Alternatively, you can also use custom logic to provide restrictions on the field by defining fields label within the custom settings.
3. Custom permissions – The third and arguably the best way to achieve this is through the Custom Permissions. You will need to create a Custom permission, define the permissions sets and then enable your custom permission on that permission sets.
As the next step, you need to use custom permission object to check the access sets on the permission sets. This is shown below:
Here, DeveloperName is the unique name of the custom permission in the API.
If you need to query all permission sets and profiles with custom permissions, you can use the following:
If you need to query for all SetupEntityAccess rows with Custom Permissions, you need to use the following:
You can validate the set permissions for any fields or buttons and can restrict users accordingly.
The biggest advantage of using Custom Permissions is that they can be enabled for any permissions sets, so if the users want to set their own permission sets, all they need to do is to define the permission sets and enable package custom permissions in those permission sets. They do not need to make any code changes afterwards.
Written by Neena Tiwari, Salesforce Developer at Eternus Solutions
Suppose you are developing a Loan-Based product for your client where you need to update the Account status as Closed when the opportunity gets declined for that particular Account. This is quite simple to achieve. All you need to do is to write a trigger to update the Account. However, there’s a slight catch! Client wants that the Opportunity Status should only get updated by users with Loan Manager or Senior Manager roles and the System Administrator should also be restricted to update that field. How do you achieve this?
There are a few possible approaches that you would take:
1. Permission sets – One way to address the issue is to use Permission sets. Users are restricted to edit the permission sets from the package, so if the users wants to add/ modify permission sets, a new version of the package would need to be created.
2. Alternatively, you can also use custom logic to provide restrictions on the field by defining fields label within the custom settings.
3. Custom permissions – The third and arguably the best way to achieve this is through the Custom Permissions. You will need to create a Custom permission, define the permissions sets and then enable your custom permission on that permission sets.
If you need to query all permission sets and profiles with custom permissions, you can use the following:
If you need to query for all SetupEntityAccess rows with Custom Permissions, you need to use the following:
You can validate the set permissions for any fields or buttons and can restrict users accordingly.
The biggest advantage of using Custom Permissions is that they can be enabled for any permissions sets, so if the users want to set their own permission sets, all they need to do is to define the permission sets and enable package custom permissions in those permission sets. They do not need to make any code changes afterwards.
Product Development Simplified!
In a nutshell, whatever permission is defined on any sObject by the User while creating the package, will not stick to the package itself, but on the permissions sets attached by the user to custom permission (coming from the package) in any organization after installing the package. In other words, it will be independent of the package and can vary as per specific requirements of that particular organizations. Therefore, the developer does not need to do any code changes, or create different package links based on different clients’ requirements, but it can directly be handled by the user of that organization himself, thus simplifying product development.Written by Neena Tiwari, Salesforce Developer at Eternus Solutions
