Manage Permissions in a Sandbox with a Screen Flow | How I Solved It

Key business problem

Switching users in scratch orgs is cumbersome and time consuming. It took me 53 seconds to navigate to Setup, find my user, deactivate one user, and activate another user in order to test different personas.

I was responsible for creating a user guide and delivering release notes for a Salesforce project. Between the two, I was working with more than 100 pages of documentation. I wanted a more seamless way to update permission set group assignments so I could easily take screenshots.

As a bonus, I found this tool incredibly helpful while developing in scratch org environments (Developer Edition orgs).

How I solved it

Here’s how I created the solution.

In order to easily switch personas, I created a screen flow that users can access from the utility bar that allows them to:

1. See which permission set group assignments are currently assigned to them in a read-only data table
2. Add a permission set group assignment
3. Remove a permission set group assignment 

Note: For a full view of the screen flow, navigate to the bottom of the page.

A few things to consider:

• This solution works best with orgs that are permission set group based, meaning user access primarily comes from permission set groups. A modified version of this solution can be used for orgs that work from permission sets. Note: If you go this route, consider filtering out permission sets by making sure they aren’t owned by the profile (that is, IsOwnedByProfile does not equal true as well as any other filters you need).
• This solution only looks at permission set groups. In order to truly switch personas, I encourage you to look into other areas that affect your users and expand this automation to include those (for example, if your test Sales user is assigned the Sales permission set group, which public groups and queues might you need to add and remove?).
• For those who aren’t familiar with scratch orgs, they are a copy of your sandbox. The benefit of scratch orgs is that there’s only one person making changes to it; once changes are complete, they can easily send their changes into the sandbox. Scratch orgs have a short lifespan. New scratch orgs can easily be created with the latest developments from the team’s sandbox. It’s worth noting that scratch orgs are development edition orgs. I will refer to these as Developer Edition orgs throughout.

Let’s build!

Step 1: Set up the profile and test user

• Profile setup:
  • Clone the standard profile, removing unnecessary permissions. (Note: If using to test in an active environment, use the same profile with no changes that users are assigned to in that environment.)

• Test user configuration:
  • Generate a test user with a Salesforce license and assign the cloned standard profile.

• Permission set group formation:
  • Create four permission sets to give users app access, Lightning Experience access, the ability to manage profiles and permission sets, and the ability to run flows.
  • Add these sets into a permission set group and assign this group to the test user.
  • This permission set group should be assigned to the test user at all times.

Step 2: Create a screen flow

Here’s the completed screen flow that we will walk through.

• Variable setup:
  • Configure essential text collection variables (example below).
    • allPermSetGroupIds
    • assignedPermSetGroupIds
    • removePermSetGroupIds

• Create a single variable and a collection record variable from the Permission Set Assignment object:

• • varPermSetAssignedAddRec (record variable)
  • varPermSetAssignmentAddCollection (collection variable)

• Guardrails implementation:
  • Integrate guardrails to restrict users from modifying their permission set groups in non-sandbox or Developer Edition orgs.
  • Get Organization info: Use a Get Records element to specifically look for IsSandbox and OrganizationType fields from the Organization object.

• Decision element for org type and error screen:
  • Implement a Decision element to determine the org type and use a Screen element to display an error screen for non-sandbox or Developer Edition orgs.

Step 3: Collect permission set group information

• Next, gather details about permission set groups assigned or available to the test user from different Get Records elements.
  • Use a Get Records element named Get All Permission Set Groups (Permission Set Group object) to filter the DeveloperName in a way that it will only get the Permission Set Groups that could be available to your user. In larger orgs, the application programming interfaces (APIs) will likely have the team or the project that the persona is connected to. In my case, HISI is part of the API for all three of my personas. Not shown in the image, I only collected the DeveloperName field.
  • Loop through and use the Assignment element to assign the ID to the record variable then the record variable to the collection.

• • The Get Records element named Get Assigned Permission Set Groups Ids (Permission Set Assignment object) filters out records where the Permission Set Group ID is IN the allPermSetGroupIds collection AND the AssigneeId equals the current user’s ID ($User.Id). Once records are collected, the collection goes through a loop. The permission set IDs are added to the assignedPermSetGroupIds collection in the Assignment element.

• • Get Records element named Perm Set Groups ASSIGNED (Permission Set Group object) where the only field collected from this will be the DeveloperName.

• • Get Records element named Get Permission Set Group AVAILABLE (Permission Set Group object).

Step 4: Configure a Screen element

• Screen creation:
  • Develop a screen allowing users to view and select permission set groups.
  • Use a view-only data table to view currently assigned permission set groups using {!getPermSetGroupsAssigned} as your data source (whichever Get element you created from the Permission Set Groups object that renders the names of the currently assigned permission set groups will go here). Next, configure row selection to View Only under the “Configure Rows” section and add the “API Name” in the “Configure Columns” section.
  • Use data tables to allow users to select permission set groups to add/remove permission set groups. 
    • For the “Add” data table, use the {!getPermSetGroupsAvailable} source (whichever Get Records element you created from the Permission Set Groups object that renders the names of the available permission set groups will go here).
    • For the “Remove” data table, use the {!getPermSetGroupsAssigned} source (whichever Get Records element you created from the Permission Set Groups object that renders the names of the currently assigned permission set groups will go here).
    • Both the “Add” and “Remove” data tables rows and columns are configured the same way.
      • Select Use Label as Table Title and add a Title that clearly describes the table (I did this for all three tables).
      • Name data tables in a way that users will understand what they are. I named my data tables:
        • dataTableCurrentPermSetsAssigned
        • dataTablePermSetsAdd
        • dataTablePermSetsRemove
      • Configured row selection to Multiple (depending on your use case, you may want to select Single).
      • Configure column to add the API Name.

Data Table Configurations

Step 5: Handle user selections

• PSG Add Collector loops through the dataTablePermSetsAdd source and assigns the Permission Set Assignment Id and $User.Id to the varPermSetAssignmentAddRec variable. After the record variable is set (assigned), the record variable is added to the collection variable (varPermSetAssignmentAddCollector).

• • PSG Remove Collector loops through the dataTablePermSetsRemove source and assigns the Permission Set Group Id to the removePermSetAssignmentIds collection variable.

Step 6: Create a Decision element

• Create a Decision element to guide users based on their selections.
  • Option 1 (Add/Remove): Create (only) OR create and delete permission set group assignments.
  • Option 2 (Remove): Delete (only) permission set group assignments.
  • Option 3 (Default): Do nothing.

Option 1:

Option 2:

Step 7: Create a an action based off of the Decision element

• Add/Remove path:
  • Create Records element using the varPermSetAssignmentAddCollector variable.

• Decision to see if there are any permission set group assignments that need to be removed (deleted) based off of the removePermSetAssignmentIds variable.

• If yes, then the Delete Records element is used to remove permission set group assignments by checking to see if the Permission Set Group ID is in the removePermSetAssignmentIds collection. If nothing needs to be removed, the flow is finished.

• Remove path:
  • Use a connector to the Delete Records element and to remove the permission set groups assignment based off of the removePermSetAssignmentIds variable. Once the records have been removed, the flow is finished.

Step 8: Test, activate, and ensure accessibility

• Save, test, and activate your flow.
• Add your flow to the utility bar:
  • Navigate to Setup, App Manager in Quick Find box, select Edit from the drop-down menu next to your app, and navigate to Utility Items.
  • Add an easy-to-understand label (Update PSG), select an icon that you think is appropriate for the flow, and select your flow from the flow box (if you don’t see your flow, double-check that you activated it).

• And voila! Venture into your app to test out your new Salesforce magic from the utility bar (*happy dance when testing passes!*).

Business results

By implementing the Add/Remove Permission Set Groups screen flow, I save approximately 47 seconds each time I switch personas from the utility bar in my Developer Edition org. By following these steps, admins and developers can successfully implement an advanced solution for permission set management in Salesforce, providing users with a time-saving, user-friendly experience.

Do try this at home

I can’t wait to hear about the different solutions you create with this Salesforce magic. Connect with me on LinkedIn. I would love to hear about it!

Special shout-out to Jesse Pennington and Tamar Erlich for helping me troubleshoot a couple pieces to this flow. Also to current and former colleagues James Buckelew (Flow genius) and Jonathan Devlin (challenging me to set up guardrails). Last but not least, to Stuart Werner and team from Trailblazer Bootcamp, Atlanta for helping me establish confidence building flows on the Salesforce Platform! 

Resources

• Trailhead: Quick Start: Salesforce DX 
• External Site: Salesforce Ben: Get Started With Salesforce Scratch Orgs
• External Site: Salesforce Ben: Salesforce Permissions & Profiles: The Latest Retirement Updates
• External Site: YouTube: A Profiles to Permission Set Journey
• Salesforce Admins Blog: Automate This! — How to Use Loops in Flow
• External Site: LinkedIn: Military Trailblazer Office Hours
• Salesforce Site: Salesforce Military
• Traiblazer Community Group: Flownatic Slack Group
• External Site: Talent Stacker: Military spouses and veterans score Salesforce careers | Ep 024

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