query custom permission assignment salesforce

Andy in the Cloud

From bbc basic to force.com and beyond….

query custom permission assignment salesforce

Creating, Assigning and Checking Custom Permissions

January 14, 2015 by Andrew Fawcett 21 Comments

I have been wanting to explore Custom Permissions for a little while now, since they are now GA in Winter’15 i thought its about time i got stuck in. Profiles, Permission Sets have until recently, been focusing on granting permissions to entities only known to the platform, such as objects , fields , Apex classes and Visualforce pages . In most cases these platform entities map to a specific feature in your application you want to provide permission to access.

However there are cases where this is not always that simple. For example consider a Visualforce page you that controls a given process in your application, it has three buttons on it Run , Clear History and Reset . You can control access to the page itself, but how do you control access to the three buttons? What you need is to be able to teach Permission Sets and Profiles about your application functionality , enter Custom Permissions !

NOTE: That you can also define dependencies between your Custom Permissions, for example Clear History and Reset permissions might be dependent on a Manage Important Process custom permission in your package.

Once these have been created, you can reference them in your packaged Permission Sets and since they are packaged themselves, they can also be referenced by admins managing your application in a subscriber org.

The next step is to make your code react to these custom permissions being assigned or not.

New Global Variable $Permission

You can use the $Permission from a Visualforce page or as SFDCWizard points out here from Validation Rules ! Here is the Visualforce page example given by Salesforce in their documentation.

Referencing Custom Permissions from Apex

IMPORTANT UPDATE : Since API 41 (Winter’18) there is now a native way to read Custom Permissions. The following may still be useful if you have requirements not met by the native method. FeatureManagement.checkPermission .

In the case of object and field level permissions, the Apex Describe API can be used to determine if an object or field is available and for what purpose , read or edit for example. This is not going help us here, as custom permissions are not related to any specific object or field. The solution is to leverage the Permission Set Object API to query the SetupEntityAccess and CustomPermission records for Permission Sets or Profiles that are assigned to the current user.

The following SOQL snippets are from the CustomPermissionsReader class i created to help with reading Custom Permissions in Apex (more on this later). As you can see you need to run two SOQL statements to get what you need. The first to get the Id’s the second to query if the user actually has been assigned a Permission Set with them in.

Now personally i don’t find this approach that appealing for general use, firstly the Permission Set object relationships are quite hard to get your head around and secondly we get charged by the platform to determine security through the SOQL governor. As a good member of the Salesforce community I of course turned my dislike into an Idea “Native Apex support for Custom Permissions” and posted it here to recommend Salesforce include a native class for reading these, similar to Custom Labels for example.

Introducing CustomPermissionReader

In the meantime I have set about creating an Apex class to help make querying and using Custom Permissions easier. Such a class might one day be replaced if my Idea becomes a reality or maybe its internal implementation just gets improved. One things for sure, i’d much rather use it for now than seed implicit SOQL’s throughout a code base!

Its pretty straight forward to use, construct it in one of two ways, depending if you want all non-namespaced Custom Permissions or if your developing a AppExchange package, give it any one of your packaged Custom Objects and it will ensure that it only ever reads the Custom Permissions associated with your package.

You can download the code and test for CustomPermissionsReader here.

Like any use of SOQL we must think in a bulkified way, indeed its likely that for average to complex peaces of functionality you may want to check at least two or more custom permissions once you get started with them. As such its not really good practice to make single queries in each case.

For this reason the CustomPermissionsReader was written to load all applicable Custom Permissions and act as kind of cache. In the next example you’ll see how i’ve leveraged the Application class concept from the Apex Enterprise Patterns conventions to make it a singleton for the duration of the Apex execution context.

Here is an example of an Apex test that creates a PermissionSet , adds the Custom Permission and assigns it to the running user to confirm the Custom Permission was granted.

Seperation of Concerns and Custom Permissions

Those of you familiar with using Apex Enterprise Patterns might be wondering where checking Custom Permission fits in terms of separation of concerns and the layers the patterns promote.

The answer is at the very least in or below the Service Layer , enforcing any kind of security is the responsibility of the Service layer and callers of it are within their rights to assume it is checked. Especially if you have chosen to expose your Service layer as your application API.

This doesn’t mean however you cannot improve your user experience by using it from within Apex Controllers, Visualforce pages or @RemoteAction methods to control the visibility of related UI components, no point in teasing the end user!

Integrating CustomerPermissionsReader into your Application class

The following code uses the Application class concept i introduced last year and at Dreamforce 2014 , which is a single place to access your application scope concepts, such as factories for selectors, domain and service class implementations (it also has a big role to play when mocking).

This approach ensures their is only one instance of the CustomPermissionsReader per Apex Execution context and also through the properties it exposes gives a compiler checked way of referencing the Custom Permissions, making it easier for application developers code to access them.

Finally, as a future possibility, this approach gives a nice injection point for mocking the status of Custom Permissions in your Apex Unit tests , rather than having to go through the trouble of setting up a Permission Set and assigning it in your test code every time as shown above.

Call to Action: Ideas to Upvote

While writing this blog I created one Idea and came across a two others, i’d like to call you the reader to action on! Please take a look and of course only if you agree its a good one, give it the benefit of your much needed up vote!

Idea: Make a “PackageInfo” Apex class available for managed code to call at runtime
Idea: Display the Profiles & Permissions Sets with Custom Permissions on Page
Idea: Native Apex support for Custom Permissions

Biswajeet Samal's Blog

Sharing my it experience, custom permissions in salesforce.

Custom permission is one of the Salesforce features to grant user access to custom processes or apps. In Salesforce, many features require access checks that specify which users can access certain functions. Permission set and profiles settings include built-in access settings for many entities, like objects, fields, tabs, and Visualforce pages. However, permission sets and profiles don’t include access for some custom processes and apps.

Custom permissions will allow to define access checks that can be assigned to users via permission sets or profiles, similar to how you assign user permissions and other access settings.

These are the ways to query Custom Permissions:

To determine which users have access to a specific custom permission, use SOQL with the SetupEntityAccess and CustomPermission sObjects.
To determine what custom permissions users have when they authenticate in a connected app, reference the user’s Identity URL, which Salesforce provides along with the access token for the connected app.

Here is an example to implement “Custom Permissions” in “Custom Button”. In below example I’ve implemented a “Custom Javascript Details Button” to deactivate account record. Some specific Profile Users have permission to deactivate the account record.

For that I have to check all profile in “Custom Button” or I’ve to create a Permission Set to check it (For Permission Set I’ve to write SOQL query).

Instead of doing this, If I’ll create one “Custom Permission” and assign that permission to those profiles, then I can only check the access of “Custom Permission” in “Custom Button”, and if the user has access to the “Custom Permission”, then User can deactivate account records.

Go to Setup, enter Custom Permissions in the Quick Find box, then select Custom Permissions.
Enter the permission information: Label : The permission label that appears in permission sets Name : The unique name that’s used by the API and managed packages Description (Optionally) : A description that explains what functions the permission grants access to. Connected App (Optionally) : The connected app that’s associated with this permission.
Click Save.

Create Custom Permission “Deactivate Account”:

Assigned the above Custom Permission “Deactivate Account” to Profiles: Go to Setup || Profiles || Select Profile || Enabled Custom Permissions || Edit || Add Custom Permissions to the Profile.

JavaScript Code: Here I’m checking $Permission.Deactivate_Account Custom Permission.

Would like to recommend app called Bulk Object Field Creator, it helps to compare & export multiple permission sets in single click ; and share results in excel format (side by side comparison

shut the hell up

App Building
Be Release Ready – Summer ’24
Integration
Salesforce Well-Architected ↗
See all products ↗
Career Resources
Essential Habits
Salesforce Admin Skills Kit
Salesforce Admin Enablement Kit

Home » Video » Automate This! — Automatically Assign and Remove a Permission Set

Jennifer Lee in her first episode of our new "Automate This!" series.

Automate This! — Automatically Assign and Remove a Permission Set

Welcome to “Automate This!” In this new, live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by #AwesomeAdmin Trailblazers like you. Automation allows you to remove manual tasks, drive efficiency, and eliminate friction and redundancy. With the recent announcement of the future retirement of Workflow Rules and Process Builder , we’ll focus heavily on record-triggered flow solutions this year. Watch how I use the power of Flow to assign and remove a permission set from a user, and then read all the details in the post below.

Stay tuned for next month’s Automate This! Live .

When you think about automation, the use cases that come to mind are most likely automation that your customers or users can benefit from. But did you know that you can automate user management tasks to make your life as an admin easier? Let’s #WorkSmartNotHard by automating routine, repetitive tasks for ourselves so we have more time to focus on value-added tasks, like delivering new enhancements to our users!

As an admin, it’s important to be security-minded, ensuring your org is secure and your users have least privilege access. Use our Security & Visibility Admin Configuration Kit to guide you toward a recommended solution for object-level security, field-level security, and record access.

Gone are the days you need Post-It notes to remind you to manually add and remove users from permission sets. Now, you can configure Salesforce to remember for you. With Flow, you can automatically assign and remove permission sets to/from a user as long as certain conditions are met.

Understand the object relationship

First things first. Let’s understand the relationship between user and permission sets.

User and Permission Sets are objects. The User object holds all the records of your users. The Permission Set object holds all the permission sets in your org. Then, you have the Permission Set Assignment object, which is the junction object that holds the record that ties the user to a specific permission set. A permission set assignment record has two important attributes:

AssignedId: This is the user ID.
PermissionSetId: This is the permission set ID.

User, Permission Set, and Permission Set Assignment objects, where the Permission Set Assignment object is a junction object of User and Permission Set objects

A user can have none or many permission sets, which would be reflected in the Permission Set Assignment object.

Let’s review the overall process in Salesforce

Before we log in to Salesforce and create a new flow, the first step in creating automation is to understand the overall process. There are two parts to this process: adding a user to a permission set and removing a user from a permission set.

First, let’s review the steps to manually assign a permission set to a user.

Search for the user.
View the user’s record.
Navigate to the user’s Permission Set Assignments list.
Click Edit Assignments .
Select the permission set from the Available Permission Sets list to add to the Enabled Permission Sets list.
Click Save .

Adding and removing permission sets to/from a user]

Note: You can assign a permission set in the user interface (UI) only if it’s listed in the Available Permission Sets list.

Let’s now review the steps to manually remove a permission set from a user.

Navigate (hover over) to the user’s Permission Set Assignments list.
Locate the permission set you want to remove and click the Del link.

Note: You can only delete a permission set in the UI if it’s already enabled for the user.

Your automation (aka flow) needs to accommodate for these UI restrictions or else your flow will fail.

Before you assign a permission set, you need to ensure the user isn’t already assigned to the permission set.
Before you remove a permission set, you need to ensure the user is already assigned to the permission set.

Cloudy holds a NO sign, showing you can’t assign a permission set that’s already assigned to the user. Astro holds a YES sign, showing you can remove a permission set if it’s already assigned to the user.

Let’s document the process

Before building automation in Flow Builder, I’ve found it helpful to think out the steps logically before getting my hands on the keyboard. This is especially true if you’re just learning Flow or when working on a highly complex process. It’s easier to make changes on paper than to have to refactor your configuration.

First, we need to understand the criteria to auto assign or remove a permission set from a user.

For our business requirements, when a new Finance user is added to Salesforce, the ABC permission set will be assigned. If an existing user leaves the Finance department and moves to the Sales Division, then the ABC permission set will be removed from the user.

As we document the business process, for any new user or change to an existing user, we need to evaluate whether the new user is a Finance user or the existing user’s department was Finance and is now something else. Then, if it is a new Finance user, we’ll assign a permission set. If the user was formerly part of the Finance department, we’ll remove the permission set.

Let’s take a closer look at the documented steps for assigning a new permission set.

First, we need to identify the permission set. We know it by name, but Flow needs to know the permission set ID. We get the ID by looking at the details of the permission set record. Here, we’ll follow best practice and find the permission set record by its API or developer name, as this is less likely to change than the permission set name/label.

But let’s say you can’t find the permission set by that name. Perhaps you were given the wrong name. Essentially, without that permission set record, your business process ends. You can’t do much else at that point.

When working with Flow, you need to put those safety verifications or guardrails in place to prevent your flow from failing. Visually, in Salesforce Setup, you’d be able to see in the UI whether the user is already assigned to the permission set. Essentially, behind the scenes, your flow will look to see if there’s a permission set assignment record for the user and the permission set.

If the user doesn’t have the permission set, then the next step is to assign the permission set to the user (or create the permission set assignment record). However, if the user already has the permission set, no further action is needed. Your work is done.

When we find records, we’ll use a Get Records Flow element to find information about the permission set. To determine whether the Get Records element found a permission set record, we need to make a decision. Hence, we’ll use a Decision element. Next, to see if the user is assigned to the permission set, we need to query the Permission Set Assignment object, so we’ll once again use the Get Records element. Next, we need to determine whether the Get Records element found a permission set assignment record for that user and permission set, which is done using another Decision element. Lastly, if the permission set assignment record is found, we’ll create a new permission set assignment record for the user permission set combination with a Create Records element.

Now, let’s look at the scenario of removing a permission set.

Again, similar to the process of assigning a permission set, we need to identify the permission set to get the permission set ID. If we can’t find the permission set, our work is done. Again, we need to put those safety verifications in place to prevent our flow from failing. Visually, in Setup, you can see whether the user is assigned to the permission set you wish to remove. Like the first scenario, you’re looking to see if there’s a permission set assignment record for that user and permission set.

If the user has the permission set, the next step is to remove it (or delete the permission set assignment record). If the user doesn’t have the permission set, no action is needed.

When we find records, we’ll use a Get Records element to find information about the permission set. To determine whether the Get Records element found a permission set record, we need to make a decision. So, we’ll use a Decision element. Next, to see if the user is assigned to the permission set, we need to query the Permission Set Assignment object, so we’ll once again use the Get Records element. Next, we need to determine whether the Get Records element found a permission set assignment record for that user and permission set, which is done using another Decision element. Lastly, if the permission set assignment record is found, we’ll remove the permission set assignment record for the user permission set combination with a Delete Records element.

While we can design each process as its own process and its own flow, did you notice what both processes have in common? Yes, there are four common steps between the two processes. So, an even better design would be to consolidate the steps so we don’t build the same steps over and over again.

One more thing before we get into Flow Builder.

We need to determine information we need (or our inputs) so Salesforce can automagically assign permission sets to a user:

Who is the user?
What is the permission set?
What are we looking to do (in this case—assign or remove a permission set)?

These three pieces of information will be stored as text values that are three separate variables.

What’s a variable, you ask? A variable is a container that holds a piece of information for use somewhere later in the flow or to be passed off outside the flow. I think of it as a Tupperware container.

A food container representing a variable that holds a value

The variable varUserId will hold the user ID.
The variable varPermissionSetName will hold the API or developer name of the permission set name.
The variable varPermissionSetAction will hold the value “Add” or “Remove” which reflects what we want to do with the permission set.

We’ll use the permission set developer name to find the permission set ID because #AwesomeAdmins do not hard code IDs in their automation. If we find the permission set, we’ll store the ID in a variable called varPermissionSetId. Otherwise, the variable will be empty, signifying no permission set.

Another valuable piece of information we’ll get to within the process is whether the user is already assigned to the permission set. We’ll hold this in a variable called varDoesUserHavePermissionSet. If it’s true, we’ll store the assignee ID. Otherwise, the variable will be empty, signifying the user does not have a permission set.

We have a total of five variables that will hold important information we’ll use to make informed decisions or to take action within the flow.

Five food containers and a breakdown of the five variables needed

Let’s build our automation!

Now that we have that squared away, let’s look at how to build this in Flow Builder. Did you notice how long it took before we even logged in to Salesforce to configure?! There’s a big thought process that needs to happen before we build.

Our process will be broken into two flows: a record-triggered flow and an autolaunched flow. Our process begins with something that happens to a user record—when a new user is created or an update is made to an existing user record. This translates into a record-triggered flow. Regardless of whether the user is a new Finance user or was previously a Finance user, we didn’t want to create the same process steps to handle the Add or Remove permission set action. This takes us back to the consolidated process design, remember?

We’re going to build that consolidated Assign/Remove permission set process as an autolaunched flow, which means this flow will fire when something else triggers it. In our case, this will be triggered by a record-triggered flow. We’ll re-use the same autolaunched flow twice in our process—for the permission set assignment and permission set removal—and the flow will know what to do based on three input variables our record-triggered flow will pass to the autolaunched flow. When you re-use an autolaunched flow in another flow, it’s called a subflow. We’re essentially building a componentized flow that can be reused anytime there’s a need to assign or remove a permission set from a user. #WorkSmartNotHard. Build it once, maintain it once, and reuse it over and over again.

The parts of the process that will be addressed with an autolaunched flow

In order for our record-triggered flow to call or invoke an autolaunched flow, we need to build the autolaunched flow first.

The configured autolaunched flow to assign or remove a permission set from a user

First, select to create an autolaunched flow. Now, you’ll create five text variables.

The first text variable is varUserId. This will store the user ID passed from the record-triggered flow. Make this available for input.

Resource: Variable
Name: varUserId
Data Type: Text
Available for input: Checked

The second text variable is varPermissionSetName. This will store the permission set API or developer name passed from the record-triggered flow. Make this available for input.

Name: varPermissionSetName

The configured varPermissionSetName text variable

The third text variable is varPermissionSetAction. This will store the value of “Add” or “Remove” passed from the record-triggered flow. Make this available for input.

Name: varPermissionSetAction

The configured varPermissionSetAction text variable

The fourth text variable is varPermissionSetId. This will store the permission set ID when we query the Permission Set object using the value in the varPermissionSetName variable.

Name: varPermissionSetId

[Image: image.png][Alt text: The configured varPermissionSetId text variable

The last and fifth text variable is varUserHasPermissionSet. This will store the assignee ID when we query the Permission Set Assignment object for the user and permission set and there is a value found.

Name: varUserHasPermissionSet

The configured varUserHasPermissionSet text variable

Our first Flow element is a Get Records. We’ll use the permission set API or developer name to get the permission set ID. If a record is found, we’ll store the permission set ID in the variable varPermissionSetId. If no record is found, we’ll set the variable to null. This is done by checking the attribute box for “When no records are returned, set specified variables to null.”

Name: Lookup Permission Set Id
Object: Permission Set
Filter: Name Equals varPermissionSetName
How to Store Record Data: Choose fields and assign variables (advanced)
Where to Store Field Values: In separate variables
Select Variables to Store Permission Set Fields: Id → varPermissionSetId
“When no records are returned, set specified variables to null”: Checked

Name: Perm Set ID Found
Outcome: Permission Set ID Found | varPermissionSetId Is Null False
Default Outcome: No Permission Set ID Found

To see if the user is assigned to the permission set, we need to query the Permission Set Assignment object with another Get Records element to find a record with the user and the permission set. If a permission set assignment record is found, then we’ll take the assignee ID and store it in the variable varUserHasPermissionSet. If no record is found, we’ll set the variable to null by enabling the attribute “When no records are returned, set specified variables to null.”

Name: Lookup Permission Set Assignment
Object: Permission Set Assignment
Filter Permission Set Assignment Records:
AssigneeId Equals varUserId
PermissionSetId Equals varPermissionSetId
Select Variables to Store Permission Set Fields: AssigneeId → varUserHasPermissionSet

In our next step, we need to determine whether the Get Records element found a permission set assignment record for that user and permission set using another Decision element. We have two outcomes: “Add Path - No Permission Set” and “Remove Path - Has Permission Set”.

As discussed earlier, before we can add a permission set to a user, we need to ensure the user does not already have the permission set or else the flow will fail. Here, we check that the varHasPermissionSet variable has a null value (that is, Is Null True) and the varPermissionSetAction is “Add”.

And, in order for a permission set to be removed, the user must be assigned to the permission set. Here, we check that the varHasPermissionSet variable has a value (that is, Is Null False—two negatives equals a positive) and the varPermissionSetAction is “Remove”.

This decision puts the guardrails in place in Flow, where these same guardrails are already in the permission set UI.

Name: Check Permission Set Assignment
Outcome #1: Add Path - No Permission Set | varUserHasPermissionSet Is Null True AND varPermissionSetAction Equals Add
Outcome #2: Remove Path - Has Permission Set | varUserHasPermissionSet Is Null False AND varPermissionSetAction Equals Remove

If the permission set assignment record is found and the varPermissionSetAction is “Add”, then we’ll create a new permission set assignment record for the user permission set combination with a Create Records element, where the AssigneeId field is set to the value in the variable varUserId and the PermissionSetId field is set to the value in the variable varPermissionSetId.

Name: Add User to the Permission Set
How Many Records to Create: One
How to Set the Record Fields: Use separate resources, and literal values
AssigneeId: varUserId
PermissionSetId: varPermissionSetId

Lastly, if the decision outcome is to remove a permission set for the user, then we’ll delete the permission set assignment record for the user permission set ID combination using a Delete Records element. We’ll delete the permission set assignment record where the assigneeId equals the variable varUserId and permission set ID equals the variable varPermissionSetId combo matched.

Name: Remove Permission Set
How to Find Records to Delete: Specify Conditions
Filter Permission Set Assignment Records: AssigneeId Equals varUserId AND PermissionSetId Equals varPermissionSetId

Don’t forget to test it using the Flow debugger, and activate the autolaunched flow.

With the modularized flow created, we now need to create our trigger to fire the process of assigning or removing permission sets to/from a user. As mentioned earlier, we’ll use a record-triggered flow to trigger the autolaunched flow.

For our use case, when there’s a new Finance user or a user has left Finance, we want the permission set to either be assigned or removed. The action to be taken with the permission set is done by invoking the autolaunched flow we just created. In the case of the new Finance user, a permission set will be assigned. For the user who is no longer a Finance user, a permission set will be removed.

Overall process diagram for assigning or removing a permission set for a new Finance user or a user no longer part of Finance

The record-triggered flow we build will look like this.

The configured record-triggered flow for assigning or removing a permission set for a new Finance user or a user no longer part of Finance]

The record-triggered flow starts when a user record is created or edited. We don’t have any entry conditions specified, as we want to check for new Finance users or users where the department was Finance but has changed.

Object: User
Trigger the Flow When: A record is created or updated
Department is Changed True
Department Does Not Equal Finance
Department Equals Finance
Optimize the Flow for: Actions and Related Records

Once a user record passes the entry criteria, we have a decision to determine what type of user this is—a new user or an existing user who is no longer part of Finance, and these are reflected in the two outcomes.

To define the new user outcome, we need the record to be new and the department to equal “Finance.”

For the Existing User Previously Finance Department outcome, we need the user ($Record.Id) to be active, the user’s previous department ($Record_Prior> Department) was “Finance,” and the user’s current department ($Record>Department) is changed.

Since this is an after save flow (that is, a record-triggered flow that fires after a record is saved in Salesforce), we need a mechanism to indicate whether a record is new, as we can’t go by the record ID is blank (which is a filter we can use in a before save flow, which fires before the record is saved in Salesforce).

We’ll introduce a new formula resource that will look at whether the record is new and the department is Finance.

Resource Name: NewFinanceUserFormula
Resource Type: Formula
Data Type: Boolean
Formula: ISNEW() && {!$Record.Department}= "Finance"

$Once a user record passes the entry criteria, we have a decision to determine what type of user this is—a new user or an existing user who is no longer part of Finance, and these are reflected in the two outcomes. To define the new user outcome, we need the record to be new and the department to equal “Finance”. For the Existing User Previously Finance Department outcome, we need the user ($Record.Id) to be active, the user’s previous department ($Record_Prior> Department) was “Finance”, and the user’s current department ($Record>Department) is changed. Since this is an after save flow (that is, a record-triggered flow that fires after a record is saved in Salesforce), we need a mechanism to indicate whether a record is new, as we can’t go by the record ID is blank (which is a filter we can use in a before save flow, which fires before the record is saved in Salesforce). We’ll introduce a new formula resource that will look at whether the record is new and the department is Finance. * Resource Name: NewFinanceUserFormula * Resource Type: Formula * Data Type: Boolean * Formula: ISNEW() && {!$Record.Department}= "Finance"$

Here’s how you configure the Decision element:

Name: New or Previously a Finance User
Outcome #1: New Finance User | NewFinanceUserFormula Equals True
$Record.IsActive Equals True
$Record_Prior> Department Equals Finance
$Record>Department is Changed True

For the New Finance User outcome, we’ll add a subflow interaction, which will allow this record-triggered flow to invoke the autolaunched flow. Locate and select the autolaunched flow we created.

Here, we’ll include the three input variables and pass the following information to our subflow:

varPermissionSetAction: Add (This specifies we want to add a permission set.)
varPermissionSetName: ABC_Permission_Set (This is the permission set’s API name.)
varUserid: {!$Record.Id} (We’re using the ID of the user record that triggered the record-triggered flow.)

This will tell the subflow that I want to add the ABC permission set to the user record that triggered the process.

$For the New Finance User outcome, we’ll add a subflow interaction, which will allow this record-triggered flow to invoke the autolaunched flow. Locate and select the autolaunched flow we created. Here, we’ll include the three input variables and pass the following information to our subflow: * varPermissionSetAction: Add (This specifies we want to add a permission set.) * varPermissionSetName: ABC_Permission_Set (This is the permission set’s API name.) * varUserid: {!$Record.Id} (We’re using the ID of the user record that triggered the record-triggered flow.) This will tell the subflow that I want to add the ABC permission set to the user record that triggered the process.$

For the Existing User Previously Finance Department outcome, we’ll add another subflow interaction. Locate and select the autolaunched flow we created.

We’ll include the three input variables and pass the following information to our subflow:

varPermissionSetAction: Remove (This specifies we want to remove a permission set.)

This will tell the subflow that I want to remove the ABC permission set from the user record that triggered the process.

Configured subflow to remove the permission set

Test both expected outcomes (new Finance user and an existing user who used to belong to Finance) and one where the user does not meet the entry criteria (that is, new user with a department that’s not Finance) using Flow debugger. Lastly, activate the flow.

As additional scenarios come up for automatically assigning or removing a permission set, you can create a new record-triggered flow that invokes the autolaunched flow as subflows.

Documentation: Salesforce Security Guide - Permission Sets
Trailhead: Flow Testing and Distribution
Salesforce Architects: Record-Triggered Automation Decision Guide

Want to see more good stuff? Subscribe to our channel!

Jennifer w. lee.

Jennifer is a Lead Admin Evangelist at Salesforce and the host of our live streamed series Automate This! She is Flownatic, 8x certified Application Architect, Trailhead enthusiast, and Golden Hoodie recipient. Prior to joining Salesforce, Jen was a Koa customer, blogger (Jenwlee.com), founding co-host of Automation Hour, and a Salesforce MVP (2016-2021).

Jen’s Top Summer ’24 Release Features | Be Release Ready
Einstein for Formulas | Spring ’24
Jen’s Top Spring ’24 Release Features
How to Automatically Deactivate Users Who Haven’t Logged On in 90 Days

Use a Custom Error Element and Flow to Prevent Record Deletion | Automate This!

By Jeff Susich | April 17, 2024

Welcome to another “Automate This!” In this live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by Awesome Admin Trailblazers like you. With automation, you can remove manual tasks, drive efficiency, and eliminate friction and redundancy. In this episode, let’s see how Jeff Susich uses a […]

Level Up Your Approvals with Flows and the Custom Error Element | Automate This!

By Jon Chen | April 17, 2024

Use Flows and Experience Cloud to Access Salesforce Scheduler | Automate This!

By Lynn Guyer | March 21, 2024

Product Area

Feature impact.

Get Started With Einstein Relationship Insights
Users Licenses for Einstein Relationship Insights
Location of Hyperforce Instance
Assign Licenses to Users
Enable and Configure Einstein Relationship Insights
Manage Access to the Einstein Relationship Insights App
Add the Einstein Relationship Insights Component to Page Layouts
Add the Einstein Relationship Insights Digest Component to the Home...
Create a Certificate and a Private Key
Create a Connected App

Integration User for Salesforce Files

Create a Salesforce Permission Set

Assign Salesforce Files as a Connected Content Source

Connect With Salesforce Files Connected App
Copy the AWS Region and Account ID
Automatic Re-Encryption of Data
Set Up Einstein Relationship Insights on ARC
How Changed Data Is Captured in Einstein Relationship Insights
Einstein Relationship Insights Objects
Use Keywords to Search for Relationships
Create Records
Open Saved Records
Filter Relationship Type
Dismiss Recommended Relationships
See How Einstein Activity Capture Users Are Connected
View Evidence for Relationships
Use Keywords to Search for Evidence
Delete an Evidence Document
Install the Browser Extension
Access Web Pages in a Browser
Invite Einstein to a Web Page
Interact With Web Page Highlights By Using the Einstein Relationship...
Outcomes of Connecting Slack as a Content Source
Outcomes of Connecting Salesforce Files as a Content Source
Get Notified of Relationship Recommendations
Follow Records and Get Updates on Your Home Page
Understand Relationships in Actionable Relationship Center (ARC)

After you create a user account for the integration user, create a permission set to give the user permissions to query the files in the Salesforce org. Then, in orgs where Salesforce Files is enabled, use the permission set to give the integration user permissions to list and download files. Assign the permission set to the integration user and the connected app.

Required User Permissions

To view the notes captured by interaction summaries, ensure you have SOQL access to the InteractionSummary sObject type. Ensure that the access to InteractionSummary sObject includes access to these fields: ID, IsDeleted,ConfidentialityType, SystemModStamp,CreatedDate, LastModifiedDate, Name, MeetingNotes, NextSteps, and Status.

From Setup, in the Quick Find box, enter Permission Sets , and then select Permission Sets .
Click New .
Enter the name of the permission set, for example, ERISalesforceFilesCrawler .
Save the permission set.
On the Permission Sets page, under Apps, click App Permissions | Edit .
Select Query All Files . Integration users with the Query All Files permission can crawl the public files in the org.
Save your changes.
On the confirmation window, save the permission again.
On the Permission Sets page, click Manage Assignments .
Click Add Assignment , select the user that you created, and then click Assign .
Click Back to: Permission Set .
Under System, click System Permissions | Edit .
Select Modify All Data for private files or View All Data for privately shared files permissions.
From Setup, in the Quick Find box, enter manage connected , and then select Manage Connected Apps .
Click the connected app that you created, and then click Manage Permission Sets .
Select the permission set to assign to the connected app, and then save your changes.

You’ve created a user and assigned the user the permission sets to explore the files in Salesforce Files.

Who Can See My File?

Cookie Consent Manager

General information, required cookies, functional cookies, advertising cookies.

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings. Privacy Statement

Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.

Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.

Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.

Cookie List

IMAGES

How to Use Custom Permission in Salesforce?
How to Use Custom Permission in Salesforce?
How to Use Custom Permission in Salesforce?
How permission sets salesforce
How to enable Configure Messaging Permission in Salesforce for an user
How to create custom permission in salesforce

VIDEO

explain why must use permission QUERY_ALL_PACKAGES
Explanation of the use of the QUERY_ALL_PACKAGES permission
Email to Salesforce
Mission Control: What's New Webinar
Create Picklists and Field Dependencies
SOQL

COMMENTS

query
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) {.
Query to find Permission sets assigned to users
Or retrieve all users associated with a specific PermissionSet like: SELECT Id, PermissionSetId, PermissionSet.Name, PermissionSet.ProfileId, PermissionSet.Profile.Name, AssigneeId, Assignee.Name FROM PermissionSetAssignment WHERE PermissionSet.Name = 'Custom PermissionSet Name'. Note: The above code is an example and may vary depending on the ...
Custom Permissions
Custom permissions let you define access checks that can be assigned to users via permission sets or profiles, similar to how you assign user permissions and other access settings. For example, you can define access checks in Apex that make a button on a Visualforce page available only if a user has the appropriate custom permission.
Custom Permissions in Salesforce: Fine-Tuning User Access
Custom Permissions in Salesforce represent a control mechanism for custom functionality, which is not readily available within permission sets or profiles. However, once the custom permission is created, it can be enabled in a permission set or a profile to allow access to a certain item or process - such as a button on a custom page or limit ...
Custom Permissions
Custom permissions let you define access checks that can be assigned to users via permission sets or profiles, similar to how you assign user permissions and other access settings. For example, you can define access checks in Apex that make a button on a Visualforce page available only if a user has the appropriate custom permission.
Selectively Show Components to Users Using Custom Permissions
Click + Add Filter under the Set Field Visibility section. Select Advanced as the Filter Type. Select Permissions > Custom Permission > Access_Exclusive_Cupcake_Order_Components as the Field [Note: This is the API name of the custom permission.] Leave the Operator as 'Equal' and 'True' as the Value.
Limit Access Within Your Flow Using Custom Permissions
A custom permission can be assigned to a user either through a permission set or their profile. She also learned that custom permissions can be referenced in Flow. Addison can have her flow check to see if the user who updated the record has this custom permission and, if so, assign a task to the shift manager to review their order. Problem solved!
Allow Certain Users to Edit Data Using Custom ...
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.
Creating, Assigning and Checking Custom Permissions
Custom permissions are a powerful way to control access to features and data in Salesforce. In this blog post, you will learn how to create, assign and check custom permissions using Apex code, permission sets and custom settings. You will also see some use cases and best practices for using custom permissions in your applications.
Using SOQL to Determine Your Force.com User's Permissions
This field determines whether a permission set is a custom one or if it is parented by a profile. This is made possible because for every profile, there is one underlying permission set. That way, permissions layer equally across permission sets without having to treat a profile differently. In the setup user interface, you only see the profile ...
How can I Efficiently Check if the Running User has a Custom Permission?
Is there any way to check in Apex if the running user has a specific Custom Permission?The best I know of using available methods involves two separate SOQL queries: public static Boolean doesRunningUserHavePermission(String apiName) { Set<Id> accessiblePermissionIds = new Set<Id>(); for (SetupEntityAccess access : [ SELECT SetupEntityId FROM SetupEntityAccess WHERE SetupEntityType ...
Assign Permission Sets to a Query Workspace User
Assign Permission Sets to a Query Workspace User. As an admin, you can help your organization succeed by staying up to date with the latest Salesforce releases and getting familiar with product enhancements. Check out the Summer '24 release notes for a list of new features and available updates.
Create Custom Permissions
To create custom permissions: Manage Custom Permissions. From Setup, enter Custom Permissions in the Quick Find box, then select Custom Permissions. Click New. Enter the permission information: Label —the permission label that appears in permission sets. Name —the unique name that's used by the API and managed packages.
Custom Permissions in Salesforce
Custom permission is one of the Salesforce features to grant user access to custom processes or apps. In Salesforce, many features require access checks that specify which users can access certain functions. Permission set and profiles settings include built-in access settings for many entities, like objects, fields, tabs, and Visualforce pages.
Why You Should Add Custom Permissions to Your # ...
The custom permissions feature lets you define access checks to your apps or processes. Custom permissions can be assigned to users via permission sets or profiles, similar to how you assign user permissions and other access settings. Custom permissions are commonly used by developers in Apex. For example, if there's a button on a Visualforce ...
Enable Custom Permissions in Permission Sets
Set Up and Maintain Your Salesforce Organization. Custom permissions give you a way to provide access to custom processes or apps. After you've created a custom permission and associated it with a process...
Automatically Assign and Remove a Permission Set
Next, to see if the user is assigned to the permission set, we need to query the Permission Set Assignment object, so we'll once again use the Get Records element. Next, we need to determine whether the Get Records element found a permission set assignment record for that user and permission set, which is done using another Decision element.
Create a Salesforce Permission Set
To create a permission set: From Setup, in the Quick Find box, enter Permission Sets, and then select Permission Sets. Click New. Enter the name of the permission set, for example, ERISalesforceFilesCrawler. Save the permission set. On the Permission Sets page, under Apps, click App Permissions | Edit. Select Query All Files.
CustomPermission
Represents a permission created to control access to a custom process or app, such as sending email. This object is available in API version 31.0 and later. ... Join in-person and online events across the Salesforce ecosystem. Videos. Explore new features, tools, tips, tutorials, and more with on-demand and live stream videos ...