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).
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. Let’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
- Availability Outside the Flow:
- 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.
-
- Resource Type: Variable
- API: varPermissionSetGroupDeveloperName (I like starting any variables with “varXXXX”)
- Data Type: Text
- Availability Outside the Flow:
- 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 “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.
-
- Resource Type: Variable
- API: varPermSetGroupAction (I like starting any variables with “varXXXX”)
- Data Type: Text
- Availability Outside the Flow:
- 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 “varPermissionSetGroupId” that will store the permission set group id.
-
- Resource Type: Variable
- API: varPermissionSetGroupId (I like starting any variables with “varXXXX”)
- Data Type: Text
Your completed variable should look like this.
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.
-
- Resource Type: Variable
- API: varUserHasPSG (I like starting any variables with “varXXXX”)
- Data Type: Text
Your completed variable should look like this.
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
Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.
Object: Permission Set Assignment
Filter the Permission Set Assignment Records that meet these conditions:
-
- AssigneeId equals {!varUserId}
- PermissionSetGroupId equals {!varPermissionSetGroupId}
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 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.)
When no records are returned, set specified variables to null: Checked
Your completed Get Records flow element looks like this.
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?
Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.
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
Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.
How to Find Records to Delete: Specify conditions
Object: Permission Set Assignment
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
Best practice tip: Provide a description so you and other/future admins know what this flow element is used for.
How Many Records to Create: One
How to Set the Record Fields: Use separate resources, and literal values
Object: Permission Set Assignment
Set Field Values for the Permission Set Assignment
-
- AssigneeId Equals {!varUserId}
- PermissionSetGroupId Equals {!varPermissionSetGroupId}
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.
Jenwlee's Salesforce Blog 