22

As of the Winter 18 Release, we can now use the FeatureManagement class for this requirement. The above method can be removed entirely and I can simply call: Boolean hasPermission = FeatureManagement.checkPermission('CanPerformSomeOperation'); Thanks to @sfdcfox for pointing this one out.


10

Update Please note that for the running user, you can use the FeatureManagement class: Boolean isEnabled = FeatureManagement.checkPermission('My_Permission_Api_Name'); Surprisingly, I don't think you can do it more simply than the below. Execution public static List<User> getUsersWithCustomPermission(String name) { Set<Id> ...


6

Adrian Larson's answer of using FeatureManagement's static Boolean checkPermission(String customPermissionDeveloperName) will Efficiently Check if the Running User has a Custom Permission. Testing Apex when using FeatureManagement's static Boolean checkPermission(String customPermissionDeveloperName) isn't so simple. Often, using Custom Permissions will ...


5

While I was composing this question I figured it out. Since it took me longer to figure out than I would have liked, I will share what I learned in case it helps someone else down the road. It turns out that the connection between CustomPermission and the PermissionSet is made via the object called SetupEntityAccess. You can look up if a custom ...


5

It might make more sense to use a Hierarchy Custom Setting, which allows you to use the $Setup global variable. Note that you will get the most specific applicable instance, which is either for the whole Organization, a Profile, or a specific User. $Setup.MyHierarchySetting__c.SomeField__c You can also access if the running user has a specific Custom ...


5

If you want to check via Apex which pages the running user can access, you just need to hit up a few configuration objects: Set<Id> assigned = new Map<Id, PermissionSet>([ SELECT Id FROM PermissionSet WHERE Id IN ( SELECT PermissionSetId FROM PermissionSetAssignment WHERE AssigneeId = :UserInfo.getUserId() ) ]).keySet(); ...


5

You can get Object, Field, and SetupEntity permissions with the query outlined below. It gets you a lot of information... static List<PermissionSet> getPermissions(Id userId) { return [ SELECT Name, ( SELECT SObjectType, Field, PermissionsRead, ...


4

You actually can do it via the $Permission global variable. Note the global variable checks if the running user has a Custom Permission, not a PermissionSetAssignment. Create a Visualforce Homepage Component as follows: <apex:page standardStylesheets="false" showHeader="false" sidebar="false"> <apex:outputLink rendered="{!$Permission....


3

Typically, I would just namespace it in from the page using the resource. You could do something like: <apex:page> <script> (function (w) { "use strict"; w.Permissions = w.Permissions || {}; w.Permissions.PermissionName = $Permission.PermissionName; // and so on Object....


3

When you install a package, the actions that occur are as outlined in Installing Packages. In other words, if the system administrator chooses to install for all users, all profiles get all the permissions; you cannot override this behavior. Instead, choose Install for Admins or Install for Specific Profiles, then you can assign the permission set to users ...


3

Unfortunately, you'd have to remove the Manage Public Folders permission, because this permission automatically gives access to all folders created by users. There's no way to hide a public folder from a user with Manage Public Folders, so if you really want to do this, you're going to have to do it the hard way.


2

Interesting... the comments and previous answer were very helpful (so thank you for them), I implemented them but the actual issue turned out to be because of the <apex:outputPanel>. Apparently even without the permissions in play the hyperlink was being removed on rerender because the text was wrapped with an outputPanel. Luckily, I found another ...


2

There is not currently a way to give a user write access exclusively to custom metadata. Write access is via Customize Application, which, as you've noted in a comment, gives access to a lot of other things as well.


2

You can refer custom permission in workflows, ProcessBuilder and Visualworkflow using $Permission. If the name of my custom permission is Enable_Contact_Creation, then to refer it in formula it will be $Permission.Enable_Contact_Creation Src :https://help.salesforce.com/articleView?id=000221057&type=1 https://automationchampion.com/2017/06/29/getting-...


2

You can use the $Permission global variable in all places where a formula can be used, and specifically in relation to Workflow rules, this means criteria-based Workflow Rules cannot be used - you need to switch to use a formula as entry-criteria To be complete the same global formula syntax can be used in: Formulas used in field updates Formula fields ...


1

There's no way to move those assignments via metadata deployments. You can assign permission sets via PermissionSetAssignment records, which can be loaded as regular Data Loader files, or you can use Salesforce DX to assign those users.


1

I'm still not sure I understand what you're asking, but I'll try to answer based on what I believe I understand. I think that you're asking whether you can limit the functionality of an application you've installed from the AppExchange to only access specific data. The answer to that question is generally no. Application code runs in the context of the user ...


1

Per the CustomPermission object documentation's special access rules section, one of these 4 permissions is required after the Spring '20 release. Special Access Rules As of Spring '20 and later, only users who have one of these permissions can access this object: View Setup and Configuration Manage Session Permission Set Activations ...


1

As Avrom points out, you can't control edit access using permissions to a specific MDT SObject. But, if a user has Customize Application privileges and you DON'T want that user to edit an MDT row, you could partially solve this with validation rule(s) on those MDT fields you are trying to protect. This validation rule would test for the presence of a given ...


1

Sort of. You can't use Custom Permissions directly in your Workflow's Entry Criteria. You can, however, reference them in the formulas in your Field Update actions, and you can reference them in formula fields on your object or on the User, which are themselves referenced in the Entry Criteria. Here's an example of a Custom Permission referenced in the ...


1

It turns out that adding the namespace did indeed fix the issue. so $Permission.ns__MySetting (or whatever ones namespace and custom setting name is) is correct, while $Permission.MySetting caused the error when installed into other orgs that use a namespace. My issue was, that a commented out $Permission.MySetting was still trying to be interpreted by ...


1

I just duplicated this. I created the custom permission, assigned to a permission set, and then created a boolean formula field with the syntax: $Permission.Dan_Permission The formula result on the record were false. I assigned the permission set to myself as $ is current user. The formula results to true. So in this use case I think you should ...


1

There are few possibilities: 1. Profile permission to object. 2. Field level security and Field level Accessibility. 3. Object Permission to User. 4. Have you added the field to the standard page Layout? Please look into these if this resolves your issue. Thanks, Vipul


1

I managed to do it using 1 API request: /services/data/v46.0/query/?q=SELECT Id, ParentId, SetupEntityId FROM SetupEntityAccess WHERE SetupEntityId IN (SELECT Id FROM CustomPermission WHERE NamespacePrefix = '{{NAMESPACE_PREFIX}}') AND ParentId IN (SELECT PermissionSetId FROM PermissionSetAssignment WHERE AssigneeId = '{{USER_ID}}')


Only top voted, non community-wiki answers of a minimum length are eligible