permission set group assignment object

• App Building
• Be Release Ready – Winter ’25
• Integration
• Salesforce Well-Architected ↗
• See all products ↗
• Career Resources
• Salesforce Admin Skills Kit
• Salesforce Admin Enablement Kit
• Career Paths ↗
• Trailblazer Career Marketplace ↗
• Trailblazer Community Online ↗
• Trailblazer Community Group Meetings ↗

Home » Article » Automate the Assignment and Removal of Permission Set Groups

Automate the Assignment and Removal of Permission Set Groups

In the first episode of Automate This!, a new livestream content series focused on all things automation, I presented a solution for automating the assignment and removal of permission sets . This blog post will cover a related solution, the automation of the assignment and removal of permission set groups. Don’t know what permission set groups are? Check out the Introducing the Next Generation of User Management: Permission Set Groups blog post for an overview.

Automation is for everyone, not just for your customers or end users but also for you as an admin. Let’s make this the year where we #WorkSmartNotHard by automating routine, repetitive tasks for ourselves so we can focus on those more value add 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 only the access they need to get their work done. Use our Security and Visibility Admin Configuration Kit to guide you toward a recommended solution for object-level security, field-level security, and record access.

Stop sticking Post-it notes on your computer to remind you to manually add and remove users from permission set groups. Get Salesforce to do the remembering for you! Use Flow Builder to automagically assign and remove permission set groups to/from a user as long as certain conditions are met.

Let’s walk through how our #AwesomeAdmin, Addison Dogster, completes the process and configuration work needed to automate this task.

Understand the object relationship

First, Addison creates a permission set group called Cloudy’s PSG, assigns a couple of permission sets (Export Reports and Edit Accounts) to the permission set group, and assigns the permission set group to herself. Then, she exports the records from the following objects using Data Loader.

Note: You must check the box for “Show all Salesforce objects” to see these objects.

Permission Set Group (PermissionSetGroup): This is the object that holds the high-level setup of a permission set group. In this object, you can get the Permission Set Group Developer Name (DeveloperName) and Permission Set Group ID (Id).

Permission Set (PermissionSet): Represents a set of permissions that’s used to grant more access to one or more users without changing their profile or reassigning profiles. PermissionSet has a read-only child relationship with PermissionSetGroup. Here, important fields are the permission set name (Label) and the permission set type (“Session” represents permission set group and “Regular” represents a permission set).

Permission Set Group Component (PermissionSetGroupComponent): This is a junction object that relates the PermissionSetGroup and PermissionSet objects via their respective IDs and enables permission set group recalculation to determine the aggregated permissions for the group. In this object, you can see the related permission set group (PermissionSetGroupId) and the permission sets associated to it (PermissionSetId).

Permission Set Assignment (PermissionSetAssignment): Represents the association between a User and a PermissionSet (which can be a permission set or permission set group). Here, the important fields are the assigned user (AssigneeId), the permission set the user is assigned to (PermissionSetId), and the Permission Set Group the user is assigned to (PermissionSetGroupId).

When Addison looks at the permission set assignment data, she sees that Jared Dunn’s user ID (005B0000007N5MQIA0) is assigned to two permission sets, one of which comprises of a permission set group. But when she looks at her user record, she only has the one permission set group and no permission sets assigned. So, what is this mystery permission set?

Addison enters the permission set ID “0PSB0000001HY2aOAG” into the URL after https://servername.salesforce.com/ or https://mydomainname.my.salesforce.com/ to see what this permission set is. She gets the following error:

“Insufficient Privileges

You do not have the level of access necessary to perform the operation you requested. Please contact the owner of the record or your administrator if access is necessary. For more information, see Insufficient Privileges Errors.”

Interesting. This must be a system generated/owned permission set.

Addison noticed that when she went back to Setup Home, there are two Cloudy’s PSG items listed in her Most Recently Used list. One is a permission set group and the other is a permission set:

It appears that when a new permission set group is created, there’s a system generated permission set created with the same permission set group name.

Now that Addison understands the data relationship with permission set group, permission set, and permission set assignment, she can move into automating the assignment/removal of a permission set group using a flow, which will look like this:

Review the overall process in Salesforce

Before Addison logs in to Salesforce and creates a new flow, the first step in creating automation is to understand the overall process. There are two parts to the process: adding a user to a permission set group and removing a user from a permission set group.

First, Addison reviews the steps to manually assign a permission set group to a user:

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

Note: The user interface (UI) allows you to assign a permission set group only if it’s available in the Available Permission Set Groups list.

6. Click Save .

Addison will now review the steps to manually remove a permission set group from a user:

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

Note: The UI only allows you to delete a permission set group if it’s already enabled for the user.

Addison’s automation (aka flow) needs to accommodate for these UI restrictions or else the flow will fail.

• Before Addison assigns a permission set group, she needs to ensure the user is not already assigned to the permission set group.
• Before Addison removes a permission set group, she needs to ensure the user is already assigned to the permission set group.

Document the configuration process

Before Addison logs in to Salesforce and starts building the automation in Flow, she gets out a piece of paper and a pencil. She’s found it helpful especially when she was just learning Flow, or otherwise working on a highly complex process, to think out the steps logically on paper before she gets her hands on a keyboard. It’s easier to make changes on paper than to have to refactor her configuration. No one has time for that! #WorkSmartNotHard

First, she needs to understand the criteria to auto assign or remove a permission set group from a user.

For Addison’s business requirements, as shown in the illustration below, when a new marketing user is added to Salesforce, Cloudy’s PSG permission set group will be assigned. If an existing user leaves the marketing department and moves into the operations division, Cloudy’s PSG permission set will be removed from that user.

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

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

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

But let’s say you can’t find the permission set group by that name. Perhaps you were given the wrong name. Essentially, without that permission set group record, your business process ends. We can’t do much else at this 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 would be able to see in the UI whether the user is already assigned to the permission set group. Behind the scenes, your flow will look to see if there’s a permission set assignment record for the user and the permission set group the user is assigned to.

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

The animated GIF below illustrates the process for assigning a permission set group. It takes it a step further by translating the steps into related Flow elements. This will be handy when we build our flow.

When we find records, we’ll use a Get Records element to find information about the permission set group. To determine whether the Get Records element found a permission set group 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 group, 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 group, 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 group combination with a Create Records element.

Now, let’s take the scenario of removing a permission set group:

• Similar to the process of assigning a permission set group, we need to identify the permission set group to get the permission set group ID.
• Again, if we can’t find the permission set group, our work is done.
• We also 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 group 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 group.
• If the user has the permission set group, then the next step is to remove (or delete the permission set assignment record). If the user does not have the permission set group, no action is needed.

When we find records, we’ll use a Get Records element to find information about the permission set group. To determine whether the Get Records element found a permission set group 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 group, 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 group, 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 group combination with a Delete Records element.

We can design each process as its own process and its own flow, but did you notice what both processes have in common? There are four common steps between the two processes. An even better design would be to consolidate the steps so we’re not building the same steps again and again.

One more thing before we go into Flow Builder.

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

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

These three pieces of information will be stored as text values as 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.

• The variable varUserId will hold the user ID.
• The variable varPermissionSetGroupDeveloperName will hold the API or developer name of the permission set group.
• The variable varPermSetGroupAction 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 group ID, because #AwesomeAdmins do not hard code IDs in their automation. Hard-coding is never a best practice, no matter what you’re doing in Salesforce. Hard-coded references may cause issues when new functionality is released and make it difficult to troubleshoot problems when they arise. So don’t do it!

If we find the permission set group, we’ll store the ID in a variable called varPermissionSetGroupId. Otherwise, the variable will be empty, signifying no permission set group.

Another valuable piece of information we’ll get to within the process is whether the user is already assigned to the permission set group. We’ll hold this in a variable called varDoesUserHasPSG. 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 group.

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.

Now, let’s build our automation!

With that out of the way, let’s build this in Flow. Did you notice how long it took before we even logged in to Salesforce?! There’s a substantial thought process that needs to happen before we build our configuration.

Our process will be broken down into three flows: two record-triggered flows and an autolaunched flow. It 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 two record-triggered flows. One process handles whether the user is a new marketing user. The other process focuses on whether the user was previously part of marketing. Both will use the same process steps to handle the add or remove permission set group action. Remember the consolidated process design?

We’re going to build that consolidated assign/remove permission set group process as an autolaunched flow, which means this is a flow that will fire when something else triggers it. In our case, this will be triggered by one of two record-triggered flows. We will reuse 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 reuse an autolaunch flow in another flow, it’s called a subflow. In this case, we’re building a componentized flow that can be reused anytime there’s a need to assign or remove a permission set group from a user. We build it once, maintain it once, and reuse it over and over again. #WorkSmartNotHard

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

• First, select to create an autolaunched flow.
• Next, 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 varPermissionSetGroupDeveloperName. This will store the permission set group API or developer name passed from the record-triggered flow. Make this available for input.

• Name: varPermissionSetGroupDeveloperName

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

• Name: varPermSetGroupAction

The fourth text variable is varPermissionSetGroupId. This will store the permission set group ID when we query the permission set group object using the value in the varPermissionSetGroupDeveloperName variable.

• Name: varPermissionSetGroupId

Our last and fifth text variable is varUserHasPSG. This will store the assignee ID when we query the permission set assignment object for the user and permission set group and there is a value found.

• Name: varUserHasPSG

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

• Name: Get PSG Id
• Object: Permission Set Group
• Filter: DeveloperName Equals varPermissionSetGroupDeveloperName
• How Many Records to Store: Only the first record
• 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 → varPermissionSetGroupId
• When no records are returned, set specified variables to null: Checked

Next, we’ll use a Decision element to determine whether the Get Records element found a permission set group record. Our Found outcome checks to see if varPermissionSetGroupId has a value (that is, Is Null False—two negatives equal a positive). The default outcome is “Not Found”.

• Name: PSG Found
• Outcome: Found | varPermissionSetGroupId Is Null False
• Default Outcome: Not Found

To see if the user is assigned to the permission set group, 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 group. If a permission set assignment record is found, then we’ll take the assignee ID and store it in the variable varUserHasPSG. If there’s no record found, we’ll set the variable to null by checking the box for “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
• PermissionSetGroupId Equals varPermissionSetGroupId
• Select Variables to Store Permission Set Fields: AssigneeId → varUserHasPSG

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 group using another Decision element. We have two outcomes: “Add to PSG – Not Assigned” and “Remove PSG – Assigned”.

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

In order for a permission set group to be removed, the user must be assigned to the permission set. Here, we check that the varHasPSG variable has a value (that is, Is Null False—two negatives equal a positive) and the varPermSetGroupAction is “Remove”.

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

• Name: Is User Already Assigned?
• Outcome #1: Add to PSG – Not Assigned | varUserHasPSG Is Null True AND varPermSetGroupAction Equals Add
• Outcome #2: Remove PSG – Assigned | varUserHasPSG Is Null False AND varPermSetGroupAction Equals Remove

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

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

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

• Name: Remove PSG from User
• How to Find Records to Delete: Specify Conditions
• Filter Permission Set Assignment Records: AssigneeId Equals varUserId AND PermissionSetGroupId Equals varPermissionSetGroupId

Let’s save the autolaunched flow and name it “Assign or Remove a user from a Permission Set Group”.

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 set groups to/from a user. As mentioned earlier, we’ll use a record-triggered flow to trigger the autolaunched flow.

The first of the two record-triggered flows Addison builds looks like this. This simple, one-step record-triggered flow fires when a new marketing user is created or an existing user’s department is now marketing.

The second record-triggered flow fires when an existing user is no longer part of the marketing department.

Let’s walk through the configuration of the first record-triggered flow.

The record-triggered flow starts when a user record is created or edited and the user’s department is marketing. Since we’re calling our autolaunched flow from this flow, we’ll use the Actions element, so we select Actions and Related Records .

• Object: User
• Trigger the Flow When: A record is created or updated
• Department Equals Marketing
• When to Run the Flow for Updated Records: Only when a record is updated to meet the condition requirements
• Optimize the Flow for: Actions and Related Records

Next, we want to use an Action; specifically, we want to reference a subflow (the autolaunched flow) to add the permission set group to the user if they don’t already have the permission set group assigned.

• Subflow name: Assign or Remove a user from a Permission Set Group
• Set the variables as follows and toggle so the variable is included:
• varPermissionSetGroupDeveloperName: Cloudy_PSG (This is the API name for the permission set group.)
• varPermSetGroupAction: Add (We want to add a permission set group to the user.)
• varUserId: {!$Record.Id} (This is the record ID that fired off the record-triggered flow.)

Let’s save this record-triggered flow as “New Marketing User or User Updated to Marketing”.

Test both expected outcomes (new marketing user and an existing user who moved to marketing) and one where the user does not meet the entry criteria (that is, new user with a department not marketing) using the Flow debugger. Then, activate the flow.

Now, let’s build the second record-triggered flow.

This record-triggered flow starts when a user record is updated and the user’s department is not marketing and the user’s department has changed. Since we’re calling our autolaunched flow from this flow, we’ll use the Actions element, so we select Actions and Related Records .

• Trigger the Flow When: A record is updated
• Department Does Not Equal Marketing
• Department Is Changed True
• When to Run the Flow for Updated Records: Every time a record is updated and meets the condition requirements

Next, we need a Decision element to determine whether the user was previously part of the marketing department. For our outcome “Part of Marketing”, we need to look at the user record’s department field prior value to see if it was “Marketing”. The default outcome is set to “Not Previously Part of Marketing”.

• Name: Was the User Previously Marketing
• $Record__Prior>Department Equals Marketing
• When to Execute Outcome: If the condition requirements are met
• Default: Not Previously Part of Marketing

For the “Part of Marketing” decision outcome, we want to use an Action; specifically, we need to reference our autolaunched flow as a subflow to remove the permission set group from the user if they already have the permission set group assigned.

• varPermSetGroupAction: Remove (We want to remove a permission set group from the user.)

Let’s save this record-triggered flow as “User No Longer Part of Marketing”.

Test the expected outcome (an existing user who moved out of marketing) and one where the user does not meet the entry criteria (an existing user who was never part of marketing) using Flow debugger, and activate the flow.

As additional scenarios come up for automatically assigning or removing a permission set group, you can create a new record-triggered flow that invokes the autolaunched flow as a subflow. Build once, maintain once, leverage several times. #WorkSmartNotHard.

Now, it’s your turn. Automate the process for assigning/removing permission set groups in your org today!

• Salesforce Help: Permission Set Groups
• Trailhead Module: Flow Testing and Distribution
• Trailhead Module: Record-Triggered Flows
• Salesforce Architects Site: Record-Triggered Automation Guide

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 Winter ’25 Release Features | Be Release Ready
• Jen’s Top Summer ’24 Release Features | Be Release Ready
• Einstein for Formulas | Spring ’24
• Jen’s Top Spring ’24 Release Features

Related Posts

Core Responsibilities of a Salesforce Admin: Your Blueprint for Success

By Eliza Riley | August 21, 2024

As admins, you hold the keys to success for your users and companies to get the most out of Salesforce. You have the unique opportunity to build and manage trusted solutions that drive productivity and innovation through five core admin responsibilities: security, user management, data management, analytics, and a new core responsibility: product management.  The […]

Unleashing Productivity: Master Prompt Templates with Flow Tools

By Raveesh Raina | May 15, 2024

Prompt Builder became generally available on February 29, just over two months ago. Since then, we’ve seen a lot of Salesforce Admins start to experiment and come up with a wide variety of use cases to leverage it. From summarizing records to generating points of view and even creating business-context rich emails, there are a […]

Summer ’24 Feature Deep Dive: Create Richer Screen Flows with Action Buttons (Beta) | Be Release Ready

By Adam White | May 14, 2024

Summer ’24 is just around the corner! Discover Action Buttons, one of the new screen flow capabilities I’m really excited about, and check out Be Release Ready for additional resources to help you prepare for Summer ’24. Screen Actions are a screen flow game changer One of the most important new screen flow capabilities is […]

About 15 mins

Learning Objectives

Get the business requirements, ready to get hands-on with permission set groups, analyze your existing permissions structure, help as you begin using permission set groups, summing it up.

• Challenge +500 points

Create a Permission Set Group

After completing this unit, you’ll be able to:

• Create a permission set group.
• Assign users to a permission set group.
• Analyze existing profiles and permissions and develop a model that includes permission set groups.

Accessibility

This unit requires some additional instructions for screen reader users. To access a detailed screen reader version of this unit, click the link below:

Open Trailhead screen reader instructions .

Before you start creating a permission set group, let’s analyze the business needs. The VP of sales, E.J. Agarwal, needs team members to perform certain tasks as part of the sales orders processing function. E.J. says that some sales staff need permissions to make changes to orders, and other sales staff members need to make changes to both orders and contracts. 

Create a couple of permission sets based on tasks. Then include them in a permission set group that focuses on the job function that E.J.’s users perform. 

“Wait,” you think. “How does this save me time if I’m still creating new permission sets?”

Fair question, but remember: You can reuse permission sets! When you group these permission sets for E.J’s requirements, you retain the ability to assign the individual permission sets to other groups as needed. 

In other words, you avoid creating a unique permission set just for E.J., yet you can tailor the permission set group according to his needs. Create two custom permission sets.

Launch your Trailhead Playground now to follow along and try out the steps in this module. To open your Trailhead Playground, scroll down to the hands-on challenge and click Launch . You also use the playground when it's time to complete the hands-on challenges.

Create Permission Sets

OK, let’s create a permission set for sales orders.  

• From Setup, in Quick Find type Permission Sets and select Permission Sets .
• Click New .
• For Label, enter Sales Orders .
• For License, keep None .
• Save the permission set.

Add permission to activate orders.

• In the Find Settings... box, type Orders and then click Activate Orders .
• On the App Permissions page, click Edit .
• Scroll to the Sales section and enable Activate Orders.
• Save the permission set. A Permission Changes Confirmation box opens. Notice that both Read Order and Edit Order were also enabled. That’s because Order Activation depends on being able to read and edit orders.
• Save your changes.

Add permission to create and delete orders.

• In the Find Settings... box, type Orders and then click Orders .
• On the Object Settings page for Orders, click Edit .
• Enable the Create and Delete object permissions.

Create the permission set for contracts. 

• Navigate to the main Permission Sets Setup page. Click New .
• For Label, enter Sales Contracts .

Add permission to read, create, edit, and delete contracts.

• In the Find Settings... box, type Contracts and then click Contracts .
• On the Object Settings page for Contracts, click Edit .
• Enable the Read, Create, Edit, and Delete object permissions.

Yay! Now you can create a permission set group to contain the two permission sets. 

Create Users

Permission sets and permission set groups are worthless without users. So first, add two users to your org. 

• In Setup, open Users.
• Create two users:
• Eric Jackson:
• Title: Sales Contracts Manager
• License: Salesforce
• Profile: Minimum Access - Salesforce
• Email: Enter any email address. The Username and Nickname populate automatically.
• Anuj Singh:
• Title: Sales Coordinator
• License: Force.com - Free
• Profile: Force.com - Free User

Finally, the main event! 

• From Setup, in Quick Find, type Permission Set Groups and then select Permission Set Groups .
• Click New Permission Set Group .
• For Label, enter Sales Processing .
• Save the permission set group.

Add permission sets to the permission set group.

• Under Permission Sets, click Permission Sets in Group .
• Click Add Permission Set .
• Select Sales Orders and Sales Contracts .
• Click Add .
• Click Done .

Ta-da! Your first permission set group, Sales Processing. 

Go to your permission set group, and confirm that the group status is Updated. 

If it is, scroll down to Combined Permissions and click Object Settings . Notice that the settings for both the Contracts and Orders objects reflect the access you gave in the two permission sets in the group. 

Next you add users to the group. 

• Return to the Sales Processing permission set group.
• Click Manage Assignments .
• Click Add Assignments .
• Select Eric Jackson and then click Next .  
• Click Assign . A confirmation message states that the permission set group has been assigned to one user.
• Try to add Anuj Singh. You get an error. Just like with permission sets, you cannot assign a user to a permission set group if their license does not permit the permissions you want to assign. 
• Ignore the message and click Done .

Anuj Singh won’t be added to the group until his license is updated. Licensing requirements remain the same when you work with permission set groups.

Nifty stuff! But there’s more! 

You’ve created a permission set group and experienced some of the power that permission set groups can offer. But what do you do with your existing permission sets and users? You might wonder what to consider as you analyze your org’s assignment structure and prepare to begin using permission set groups. First, remember the principle of least privilege: Users should have the least permissions necessary to do their job. We keep this principle in mind as we work with permission set groups. 

Let’s review the purposes of profiles, permission sets, and permission set groups.

Profiles provide default settings for each user, such as default record type, IP range, and so on. Salesforce recommends using the Minimum Access - Salesforce profile as a best practice for assignment to users. Each user has only one profile . 

Permission Sets are collections of settings and permissions. Profiles allow users to perform some tasks, but permission sets allow additional tasks (tasks not enabled by profiles). For example, you can add permissions to create and customize list views, activate contracts, or any number of other permissions. 

Permission Set Groups bundle permission sets together. Users assigned to a permission set group receive the combined permissions of all the permission sets in the group. Permission set groups correspond to the job functions of users. 

With these definitions in mind, let’s revisit the permission set group you created for E.J. The goal was to give sales staff members the ability to perform the Sales Processing job function. 

• First, we listed the tasks the sales processing job function includes.
• Activate orders
• Read, create, edit, and delete orders
• Read, create, edit, and delete contracts
• Then we asked, “Can we modify existing permission sets, or do we need to create new ones?” We discovered that we needed to create two new permission sets:
• Sales Orders
• Sales Contracts
• Finally, we checked which users perform the sales processing job function and assigned Eric to the permission set group.

TIP : The permissions you include in the permission sets in your permission set group must align with the tasks that the users perform in their job function. If not, review the job function’s goals. For example, if Eric shouldn’t have the Activate Orders permission, ask if the sales processing permission set group needs this permission. If it does, then check if Eric can be assigned to a different permission set group that's better suited to what he needs to do.

By the way, if you find that you must create a new permission set to include in your permission set group, consider how you can use it outside of the group, too. Look at other job functions to see if users need to perform some of the same tasks. You might want to include permission sets in other permission set groups. Use the flexibility of permission sets strategically by modeling your permission sets on the tasks that your users perform. 

If the job function for a permission set group changes, you can update the permission set group. That’s the great thing about permission set groups: they’re easy to adjust. For example, let’s say that you find out people who perform the sales processing job function must also have edit ability on the Opportunities object. Just add a new permission set to the permission set group or add a new permission to an existing permission set in the permission set group.  

Your permission assignment analysis might take some time. The User Access and Permissions Assistant app, available on the AppExchange , can help. The app can help you see what permissions a user has, convert some profiles to permission sets, and more. For example, you might want to grab permissions from an existing profile, then use the app to convert them to a permission set. 

When you complete your analysis, you can begin to migrate your profile-based model to the more flexible permission set and permission set group model. 

Look at that! You’ve already created your first permission set group and learned about a tool that can help you analyze your existing permission sets. We’ve covered a lot of material and hope that you see the value that permission set groups offer. However, we aren’t done yet. In the next unit, you learn about the flexibility that muting permission sets can bring to your permission set groups.

• Salesforce Help : Create a Permission Set Group
• Salesforce Help :  
• AppExchange : User Access and Permissions Assistant App
• Get personalized recommendations for your career goals
• Practice your skills with hands-on challenges and quizzes
• Track and share your progress with employers
• Connect to mentorship and career opportunities

• AppAssessor

Articles by role:

• Consultants
• Business Analysts

By Lucy Mazalon

By Ben McCarthy

• Courses Login

What’s trending

10 Hottest Salesforce Winter ’25 Features For Admins

Salesforce Announce New AI Specialist Certification

10 Salesforce Winter ’25 Features for Developers

10 New Flow Features in Salesforce Winter ’25

Sales Cloud: Top Salesforce Winter ’25 Features

UPCOMING EVENTS

Salesforce commerce masterclass: a beginner’s workshop to retail solutions, key considerations for your salesforce backups, salesforce release readiness for enterprises: expert strategies for success at speed and scale, salesforce devops made simple: essential git insights, everything you need to know before dreamforce 2024, introduction to permission set groups.

By Bill Appleton

Permission Set Groups allow Permission Sets to be grouped together and assigned to Users. This technology promises to reduce the dependence on Profiles and provide greater clarity and agility for all permission assignments, because sometimes, Profiles are too big, and Permission Sets are too small.

Profiles Are Too Big

Permission sets are too small, permission set groups are just right.

Your Permission Architecture

So how do we get there.

 Assignment Complexity

Bill appleton.

More like this:

Measuring team and process performance in salesforce.

By Sayer Martin

Salesforce Blockchain for Dummies

Best practices for formatting & fixing formulas in salesforce + video.

By Chris Emmett

Leave a Reply Cancel reply

Save my name and email in this browser for the next time I comment.

Jenwlee's Salesforce Blog

Sharing my love for salesforce with my #ohana, permission set group assignment automation.

Salesforce released permission set group assignments as a generally available feature in Spring 20.

What is permission set groups, you ask? You can group permission sets based on user roles using Permission Set Groups for easier user permission management.

Traditionally, you would assign users to individual permission sets. If a group of users should have the same permissions, you would need to assign each permission set to each individual user.

With permission set groups, you can group one or more permission sets together and assign a group of users to a group of permission sets. This allows for easier security permissioning. As you add or remove permission sets from a permission set group, all the users assigned to the permission set group would receive the same set of permission sets.

With defined business rules, you can automate the assignment and removal of a permission set group assignment to your business users.

Here are a few lessons learned from implementing this use case:

• Learn how to automate permission set group assignment or removal using defined business rules.
• Learn how to invoke flow from process builder.
• Provide descriptions, where provided, in Salesforce. This may be tedious step, I know, but your future self will thank you when you are trying to remember what you configured or assist other/future admins when troubleshooting or enhancing what was built. This includes variables, the purpose of a flow, what each flow element does, etc.

Business Use Case:    Addison Dogster is the system administrator at Universal Containers. Security is a big deal and she wants to ensure that users have least privilege access, meaning they only have enough access need to perform their jobs. Also, if a group of users require the same set of permissions above what is granted through their profile, she’d like some assurance that the same set of perm sets are given to everyone in the group. Addison has used process builder and flow builder in the past to build automate the automatically assign and remove a permission set to/from a user. She wondered if she could do the same thing with permission set groups.

Solution: Addison had used process builder and flow builder in the past to build automation that systematically assigns and removes a permission set to/from a user. She wondered if she could do the same thing with permission set groups.

Let’s see if it’s possible. But first, she needs to understand the data structure of permission set groups as it relates to the user and permission sets.

Addison create a permission set group “Jen Test PSG” assigns a couple of permission sets – “Export Reports” and “Edit Accounts” – to the permission set group and then assigns the permission set group to herself. Then she exports the records from the following objects using Data Loader (version 45.0 and higher):

Note: You must check “Show all Salesforce objects” to see these objects.

Permission Set Group (PermissionSetGroup) – This is the object that holds the high level set up of a permission set group. In this object, you can get the Permission Set Group Developer Name (DeveloperName) and Permission Set Group Id (Id).

View image full screen

Permission Set Group Component (PermissionSetGroupComponent) – This is a junction object that relates the PermissionSetGroup and PermissionSet objects via their respective IDs; enables permission set group recalculation to determine the aggregated permissions for the group. In this object, you can see the related permission set group (PermissionSetGroupId) and the permission sets associated to it (PermissionSetId).

Permission Set (PermissionSet) – Represents a set of permissions that’s used to grant more access to one or more users without changing their profile or reassigning profiles. PermissionSet has a read-only child relationship with PermissionSetGroup. Here, important fields are the permission set name (Label), permission set type (Type – “Group” represents permission set group and “Regular” represents a permission set),

Permission Set Assignment (PermissionSetAssignment) – Represents the association between a User and a PermissionSet (which can be a permission set or permission set group). Here, the important fields are the assigned user (AssigneeId), the permission set the user is assigned to (PermissionSetId) and the Permission Set Group the user is assigned to (PermissionSetGroupId).

When Addison looks at the permission set assignment data, she sees that her userId ( 0056g000005J8PgAAK) is assigned to two permission set, one of which comprises of a permission set group. But when she looks at her user record, she only has the one permission set group and no permission sets assigned. So, what is this mystery permission set?

Addison enters the permission set id “0PS6g000003qnrAGAQ” into the URL after https://servername.salesforce.com/ or https://mydomainname.my.salesforce.com/ to see what this permission set is. She gets the following error.

“Insufficient Privileges

You do not have the level of access necessary to perform the operation you requested. Please contact the owner of the record or your administrator if access is necessary. For more information, see  Insufficient Privileges Errors .”

Interesting. This must be some sort of system generated/owned permission set.

She noticed that when she went back to the Setup Home, there are two Jen Test PSG’s listed in her Most Recently Used list:

It appears that when a new permission set group is created, there is a system generated permission set created with the same permission set group name.

Now, that we understand the data relationship with permission set group, permission set and permission set assignment, we can move into automating the assignment/removal of a permission set group, using a flow which will look like this:

Steps: 

1. L et’s create the flow. For those using Salesforce Classic, flow can be found in Create | Workflows & Approvals | Flows . In Lightning Experience, it is found under Process Automation | Flows .

A. Let’s create our flow resources. Go to the Manager tab, click on the New Resource button.

Best practice tip: Provide a description so you and other/future admins know what this flow resource is used for.

Let’s create a text variable called “varUserId” that will store the userId of the user who will either be assigned a permission set group or removed from one.

• Resource Type: Variable
• API: varUserId (I like starting any variables with “varXXXX”)
• Data Type: Text
• Available for input: checked (This will allow a process or flow to send a value into this variable)
• Available for output: unchecked

Your completed variable should look like this.

Create another text variable called “varPermissionSetGroupDeveloperName” that will store the permission set group developer name that a user will be assigned to or removed from. This will be sent into the flow from a process or another flow. We use the developer name or API name of the component rather than hardcoding the id. Why is hardcoding a id bad, you ask? Check out this posting .

• API: varPermissionSetGroupDeveloperName (I like starting any variables with “varXXXX”)

Create another text variable called “varPermSetGroupAction” that will store the action to take on the permission set group – “Add” to add a permission set group or “Remove” to remove the permission set group. This string value is passed from a process or another flow.

• API: varPermSetGroupAction (I like starting any variables with “varXXXX”)

Create another text variable called “varPermissionSetGroupId” that will store the permission set group id.

• API: varPermissionSetGroupId (I like starting any variables with “varXXXX”)

Create another text variable called “varUserHasPSG.” If there is a value, this means the user is already assigned to the permission set group. If the variable is null, this means that the user is not already assigned to the permission set group.

• API: varUserHasPSG (I like starting any variables with “varXXXX”)

B. First, drag the Get Records flow element to the canvas so we can get the permission set group id based on the permission set group developer name. Best practice: do not hardcode ids in components – declarative or code. You are going to query the Permission Set Group object using the developer name to get the id.

Label: Get PSG Id

Object: Permission Set Group

Filter the Permission Set Group Records by Id Equals {!varPermissionSetGroupDeveloperName}.

How Many Records to Store: Only the first record

For the “How to Store the Data” option, I chose to use “Choose fields and assign variables (advanced)” because I only care about one field but you can use the first two options as well. It’s just a preference thing in this case.

Where to Store Field Values: In separate variables

Select Variables to Store Permission Set Group Fields: Id to {!varPermissionSetGroupId}

When no records are returned, set specified variables to null: Checked

Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.

Your completed Get Records flow element looks like this.

C. Drag another Get Records flow element to the canvas so we can query the permission set assignment object to see if the user is assigned to the permission set group.

Label: Lookup permission set assignment

Object: Permission Set Assignment

Filter the Permission Set Assignment Records that meet these conditions:

• AssigneeId equals {!varUserId}
• PermissionSetGroupId equals {!varPermissionSetGroupId}

Select Variables to Store Permission Set Assignment Fields: AssigneeId to {!varUserHasPSG} (Note: It doesn’t really matter what field from the record you take as a value to store in the variable. Just choose a text one.)

D. We will a Decision flow element to determine if the user is already assigned to the permission set group and the action (add or remove the permission set group) that needs to happen.

Label: Is User Already Assigned?

For the “Add to PSG – Not Assigned” outcome, we need to check that the the user does not already have a permission set group and the action to take is to “add” the user to the permission set group. We need to do this check because if the user already has the permission set group, we can’t add another one. Otherwise, the flow will fault: Duplicate record.

When to Execute Outcome: All Conditions are Met

{!varUserHasPSG} Is Null {!GlobalConstant.True}

{!varPermSetGroupAction} Equals Add

For the “Remove PSG – Assigned” outcome, we need to check that the the user does  already has a permission set group and the action to take is to “remove the user from the permission set group. We need to do this check because if the user doesn’t have the permission set group, we can’t remove it. If we try, the flow will fault.

{!varUserHasPSG} Is Null {!$GlobalConstant.False} (This is a double negative. Which means, there is a record)

{!varPermSetGroupAction} Equals Remove

E. For the “Remove Permission Set Group” path, our next step is to delete the permission set group assignment for the user. Let’s drag the Delete Records flow element to the canvas. Configure it as follows:

Label: Remove PSG from User

How to Find Records to Delete: Specify conditions

Filter Permission Set Assignment Records when Conditions are Met

• AssigneeId Equals {!varUserId}
• PermissionSetGroupId Equals {!varPermissionSetGroupId}

F. For the “Add Permission Set Group” path, we want to assign the user to the permission set group. This is done by creating a new permission set assignment record with the user as the assignee and the permission set id as the permission set group id. Let’s drag the Create Records flow element to the canvas and configure as follows:

Label: Assign User to PSG

How Many Records to Create: One

How to Set the Record Fields: Use separate resources, and literal values

Set Field Values for the Permission Set Assignment

G. Set your flow starting point . And connect the flow elements, fault connectors and outcome connectors  to match the below…

H. Save/Save As and provide the following properties.

Best practice tip: Provide a description so you and other/future admins know what this flow is used for.

I. Before you activate your flow, test this by using the Debug button. You will provide three inputs: varPermSetGroupAction (Either put the word “Add” to add the permission set group or “Remove” to remove the permission set group), varPermissionSetGroupDeveloperName (the developer or API name for the permission set group) and varUserId (the id of the user you want to assign to or remove the permission set group from).

Note: Only use the Debug feature in a sandbox as it will update records. Because of this, NEVER use the flow debug function in Production.

J. Click the “ Activate ” button.

Next, you can either create a process or flow that based on certain conditions, it invokes the flow and sends the same inputs into the three flow input variables in Step I (Debug step). We will not go through the process for creating the process or flow.

In Process Builder, this is an example of how you would invoke the flow created…

In a flow, you would invoke the flow created as a subflow. Here is an example of that subflow.

Now, before you deploy the changes to Production, don’t forget to test your configuration changes.

Deployment Notes/Tips:

• Flows (and processes) can be deployed to Production in a change set (or can be deployed using a tool such as Metazoa’s Snapshot).
• You will find the flows and/or a process in a change set under the Flow Definition component type.
• Activate the flow and process post deployment as flows deploy inactive in Production, unless you have opted in on the Process Automation Settings screen, to “Deploy processes and flows as active.” NOTE: With this change, in order to successfully deploy a process or flow, your org’s Apex tests must launch at least 75% of the total number of active processes and active autolaunched flows in your org.

Share this:

• Already have a WordPress.com account? Log in now.
• Subscribe Subscribed
• Copy shortlink
• Report this content
• View post in Reader
• Manage subscriptions
• Collapse this bar

• Jun 20, 2023

Getting Hands-on with Permission Sets and Permission Set Groups in Salesforce

Welcome to the second part of our blog series on navigating the end of life of profile permissions with Permission Sets and Permission Set Groups. In the previous article , we delved into the concept of managing permissions using these powerful tools. Now, in this second installment, we will roll up our sleeves and dive into a hands-on exploration of permission sets and permission set groups. Get ready to take your Salesforce permissions to the next level as we delve into practical examples and best practices for effectively utilizing these features. Let's begin our journey towards mastering permission sets and permission set groups.

Configuring Permission Sets

Creating permission sets.

Log in to your Salesforce account and go to the Setup menu by clicking on the gear icon in the upper-right corner of the screen

In the Setup menu, click on the Users option and then select Permission Sets from the dropdown

Click the New button to create a new permission set

Give the permission set a name and a description that clearly describes its purpose

*The importance of this step cannot be overstated.

The naming convention should clearly define what the permission set does

The description should include all permissions assigned to the permission set

*Our recommendation is to use Permission Sets for feature based permissions, and Permission Set Groups to house permission sets by role or job function.

Tips : Use prefixes to display the type of permission

Object Permissions: [Object Name] - [what the permission does]

System Permissions: SYS - [what the permission does]

Tab Permissions: TAB - [which tab the permission applies to]

Apex: APEX - [name of Apex Class]

Visual Force: VF - [name of visualforce page]

Add Permissions to the Permission Set

Permissions are segmented between App & System . Click on the hyperlink for the type of permission you are adding. (For the example below, we will be adding Read, Create, and Edit access to Accounts, but the process would be the same for other permissions)

Click Object Settings

Select the object (Accounts)

Click the Edit button to make changes

Use the checkbox fields to select the Object & Field Level permissions

Repeat the above steps for any other permissions needing to be added to the permission set

Cloning Permission Sets

Click the Clone link beside the permission set you want to copy

Update the Label, API Name, and Description for the new Permission Set, and click Save

Add or Remove the permissions needed for the new permission set

Configuring Permission Set Groups

Creating a permission set group.

In the Setup menu, click on the Users option and then select Permission Set Groups from the dropdown

Click the New Permission Set Group button to create a new permission set group

Give the permission set group a name and a description that clearly describes its purpose, and click Save

*Our recommendation is for Permission Set Groups to be Persona or Role based, where Permission Sets should be feature based and user/role agnostic.

Click Permission Sets in Group

Click Add Permission Set to assign permission sets to the Permission Set Group

Use the checkbox fields to select the Permission Sets that need to be added to the Group, and click Add , and then Done

Muting Permission Set in Group

A Muting Permission Set allows administrators to restrict access to functionality within a Permission Set Group.

For example, let’s say we want to ensure that a Permission Set Group never receives access to view encrypted data. Since permission set groups will continue to evolve, adding a Muting Permission provides us the ability to restrict this capability regardless of which permission sets end up being added to the group.

Click on the name of the Permission Set Group

Click the Muting Permission Set in Group button

Enter a detailed label of what is being Muted, and click Save

Click the Muting Permission Set Label

Select the category that needs to be muted (in our case, System Permissions)

Check the Muted box beside the Permission needing to be Muted, and click Save

* Muted Permissions only apply to the Permission Set group they are applied to. If a user was assigned “View Encrypted Data” in a separate permission set or permission set group, they would still have access to this functionality.

Permission Assignments

Users can be assigned to Permission Sets and/or Permission Set Groups. Best practice would be to handle all assignments at the Permission Set Group level where possible.

Adding Permission Assignments

Click the Manage Assignments button

Click Add Assignment

Select the users needing to be added by clicking the checkbox field beside their name(s), and click Next

Choose an Expiration Option for the Assigned Users, and click Assign

Editing/Removing Permission Assignments

Check the box beside the users name needing to be removed from the Permission

Click the Trash icon to remove the user from the Permission Set Group OR

Click the Pencil icon to edit the users Expiration Options on the Permission Set Group

Automating Permission Assignments

Permission Sets and Permission Set Groups by default require manual assignment. However, once the permissions are well defined, Salesforce Flows support automation of permission assignments.

The Permission Set Assignment object in flow supports the assigning of both Permission Sets & Permission Set Groups

Permission sets and permission set groups are powerful tools in Salesforce that can help ensure users have the necessary access to do their jobs while maintaining security and data privacy. By following these best practices, you can create a robust permission management system that meets the needs of your organization while reducing risk.

• Salesforce Admins
• Salesforce Developers
• Salesforce Analysts

Recent Posts

What is a Salesforce Partner and How Can It Help Your Business

Navigating the Salesforce Galaxy: A Guide to Campaigns, Account Engagement, and Marketing Cloud

Embracing Inclusion: A Strategic Imperative for Innovation and Growth

Permission Sets & Permission Set Groups

Permission Set Groups allow you to rethink your whole Profile setup, by utilizing this feature you are able to assign multiple Permission Sets with just once Permission Set Group

For those of you that don’t know or may have forgotten, Permission Set Groups, released in the Winter 20’ release, allow you to combine multiple Permission Sets into a singular Permission Set Group which can then be assigned to a User.

‍ So… why are they useful?

‍ They’re an easier way to assign numerous Permission Sets at once, whether they be grouped by role or specific access to an App and all related Objects. They give you the ability to combine multiple Profiles into just a singular base Profile and you are then able to differentiate the User’s through the newly created Permission Set Groups instead.

How To Create Permission Set Groups

• Ensure you have at least one Permission Set created, you can check this by going to the ‘Permission Sets’ Setup menu section.
• Then navigate to ‘Permission Set Groups’ in the Setup menu and press ‘New Permission Set Group’ in the top right corner.
• Fill in the modal window with the name of the Permission Set Group, and a useful description and hit ‘Save’.
• From here you are presented with a pretty recognizable UI. However, for this example, we’re going to click ‘Permission Sets in Group’ and then ‘Add Permission Set’.

• To assign a User, click the ‘Manage Assignments’ button and then follow it by pressing ‘Add Assignments’.
• Select all the Users to apply the Permission Set Group to, and press ‘Assign’.

Things To Note

• Profiles are still needed for things such as assigning Record Types,
• You can add up to 100 Permission Sets to a Permission Set Group,
• You can ‘Mute’ Permissions through the Permission Set Group, &
• If a Permission Set is part of a group, it can still be assigned individually

Cameron Ofoluwa

Leave a reply cancel reply.

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

2 thoughts on “ Permission Sets & Permission Set Groups ”

Can we delete a single user who is part of the permission set group, will it effect other users in that group

Hey, yes you are able to remove a user or a group of users from a Permission Set Group without affecting any other users that are left assigned to the PS group :).

• Consultants
• Submit A Post

Find Your Account

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

Query Salesforce users and their permission sets (SOQL)

i'm trying to run an SOQL query on salesforce to get all users and their permission set id. it is important the list return will be by user not by permission sets, meaning if i have 1000 users i will get back 1000 records and for each record the user attributes like email etc + permission sets list of Id's assign to him

SELECT+id,PermissionSet.id+FROM+User i tried finding the relationship field name but i'm not so familiar wtih salesforce, please assist

• permissions

https://developer.salesforce.com/docs/atlas.en-us.238.0.object_reference.meta/object_reference/sforce_api_erd_profile_permissions.htm

The table you're looking for is PermissionSetAssignment

or bottom-up

• thanks this is exactly what i was looking for and it works perfect. i will use the Top-Down. –  Yaniv Rozenzweig Commented Nov 1, 2022 at 3:57
• what about permission set groups and public groups, how can i add those to the Top-Down –  Yaniv Rozenzweig Commented Nov 1, 2022 at 3:57
• perm sets assigned as part of the group will be something like select id, (select permissionsetid, permissionsetgroupid from permissionsetassignments) from user . Groups are pain to query, you can't get group assignments top-down, the "relationship name" is not present. You'll need some recursive mess on Group and GroupMember table. Easy when user is added directly as human, painful when he's added indirectly, based on his user role or the fact he's a member of another group... salesforce.stackexchange.com/a/13511/799 may be a start but you won't do it in 1 query –  eyescream Commented Nov 1, 2022 at 8:51
• what if i need only the direct assignments not indirect, will that help making the query possible for public groups adding to same query? –  Yaniv Rozenzweig Commented Nov 7, 2022 at 7:54
• Nope, sorry. If you run "describe" (for example in workbench.developerforce.com go to Standard & Custom Objects -> User and view "Child relationships" you'll see that data for GroupMember is incomplete. If the "relationshipName" field isn't present we can't do it as top-down query. compare with what same screen returns for PermissionSetAssignment.AssigneeId child relationship. You'll need multiple requests or ask SF dev to make for you a piece of Apex that would generate simple flat view. Have it exposed as REST service with "@httpget" annotation for example.... –  eyescream Commented Nov 7, 2022 at 11:57

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged permissions salesforce soql or ask your own question .

• The Overflow Blog
• Battling ticket bots and untangling taxes at the frontiers of e-commerce
• Ryan Dahl explains why Deno had to evolve with version 2.0
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites
• Feedback requested: How do you use tag hover descriptions for curating and do...

Hot Network Questions

• Population impacts on temperature
• Having one math symbol be in a different font from the others
• Why are swimming goggles typically made from a different material than diving masks?
• How to stop Windows from changing date modified when copying files from network?
• How old were Phineas and Ferb? What year was it?
• What might cause these striations in this solder joint?
• What do all branches of Mathematics have in common to be considered "Mathematics", or parts of the same field?
• Cannot compile code against latest stable GeoTools/GeoServer version
• Can data be preprocessed when using EdDSA with SHAKE?
• Momentary solo circuit
• Is the Garmin Edge 530 still a good choice for a beginner in 2024?
• Why do computers use binary numbers in IEEE754 fraction instead of BCD or DPD?
• How can flyby missions work?
• Can mending be used to attach the unbroken ends of a pole together?
• How common is it for external contractors to manage internal teams, and how can we navigate this situation?
• Did the French janitor at the University of Hanoi receive a higher base pay than a Vietnamese professor?
• What other goals could a space project with the primary goal of experience building with heavy lift rockets preform?
• How do I encourage my baby lemon tree to grow up/strengthen instead of growing out?
• Which BASIC dialect first featured a single-character comment introducer?
• Arranging people in a jeep.
• How do I delete a systemd transient service like one created by systemd-run?
• Seven different digits are placed in a row. The products of the first 3, middle 3 and last 3 are all equal. What is the middle digit?
• Home Psi higher than city psi?
• Reference of "she"

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Assigning and Removing Permission Set via Apex

I'm trying to use apex to assign and remove a permission set in a trigger, but I keep running into issues. Here's my code:

In my Trigger, I call the class at the beginning and end of the After Update portion.

I have been getting differing errors, like DELETE_FAILED, delete failed for this entity, future method can't be invoked, or DUPLICATE_VALUE, duplicate value found. I thought I was doing enough checking to see if the record already existed, but clearly I'm missing some steps.

• permission-sets

2 Answers 2

Your checks definitely are not robust enough. First, you need to be a lot more explicit about the future methods:

Secondly, this can cause a query exception:

The exception would be "no rows for assignment". Instead, query for a list, and use the first result:

Third, you can use Database.insert(psa, false); to ignore the duplicate value error.

For delete errors, make sure you use "without sharing":

• Thank you sfdcfox, that definitely makes sense. I will give it a try! –  KB123 Commented Oct 13, 2017 at 19:54

I don't understand your fundamental need here. Apex runs in the system context, so you should not need to set permission set assignments in triggers. See documentation

Apex generally runs in system context; that is, the current user's permissions ... aren’t taken into account during code execution

If sharing rules are preventing access for code operations, than you need to look at without sharing keyword as sfdcfox mentions.

And even if you needed to assign a permission set for a specific set of actions in a trigger, it wouldn't work because the asynch execution means that the permission set will be assigned after the trigger's execution is complete, so the user wouldn't have those permissions while the trigger is executing anyway.

• David Cheng we need to be able to assign the Permission Set using Apex so that we can utilize the Custom Permission, which we reference in Validation Rules. Would it make more sense to run them in the handler instead of the trigger? –  KB123 Commented Oct 14, 2017 at 0:02
• No, because future methods aren't executed until all the synchronous operations in the transaction are complete. See discussion here –  David Cheng Commented Oct 14, 2017 at 1:33

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged trigger future permission-sets ..

• The Overflow Blog
• Battling ticket bots and untangling taxes at the frontiers of e-commerce
• Ryan Dahl explains why Deno had to evolve with version 2.0
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites

Hot Network Questions

• How to add content security headers in Next.js which are configurable from cms side? where to add?
• Does "any computer(s) you have" refer to one or all the computers?
• Inequality between archimedean and non-archimedean height function on number fields
• Are "lie low" and "keep a low profile" interchangeable?
• What do all branches of Mathematics have in common to be considered "Mathematics", or parts of the same field?
• What is the operator-sum representation of the two-qubit depolarizing channel?
• Why are swimming goggles typically made from a different material than diving masks?
• Homotopy groups of the space of diffeomorphisms
• How do I encourage my baby lemon tree to grow up/strengthen instead of growing out?
• How does DS18B20 temperature sensor get the temperature?
• How did this zucchini plant cling to the zip tie?
• Passport - small damage on passport
• I can't select a certain record with like %value%
• Rearrange these numbers and symbols to make a true equation
• Is this misleading "convenience fee" legal?
• Should I be worried about this giant crack?
• Constructing a specific 2-variable function taking integer arguments whose value is odd/even only when arguments are equal
• How can flyby missions work?
• How soon to fire rude and chaotic PhD student?
• Is "UN law" a thing?
• Did anyone ever ask Neil Armstrong whether he said "for man" or "for a man?"
• Why does the size of a struct change depending on whether an initial value is used?
• White to play and mate in 3 moves..what are the moves?
• Old UK novel with travel through soap films