permission set group assignment

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

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

• Dreamforce Events
• Courses Login

What’s trending

Agentforce: The Next Evolution in Salesforce’s AI Story

The Future of Salesforce: Is the Cloud Giant Really Losing Its Momentum?

Salesforce Winter ‘25 Release: What to Expect and How to Prepare

Salesforce List Views: 7 Best Practices You Should Implement Right Away

Salesforce Winter ’25 Release Date + Preview Information

UPCOMING EVENTS

How to build a successful salesforce devops process, streamline lead assignment in salesforce, salesforce revops trends & insights (ask me anything), charity hackathon – third edition.

Wrocław, Poland

Unlocking Einstein Copilot: What You Need to Know

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.

Automation Champion

Automating Salesforce One Click at a Time

Profile? So Yesterday! – Auto Assign Permission Set Group to a User

Last Updated on April 3, 2022 by Rakesh Gupta

Big Idea or Enduring Question:

• How can you use Flow to automatically assign the permission set group to new users?

Has it only been five years since I wrote,  ‘ auto-assign Permission Set to new users’? . The article was written using Flow Trigger – now, an obsolete functionality. You can read it  here . Wow! How time flies! Similarly, just two years ago, I wrote another article showing how one can assign a Permission Set to new users using Process Builder and Flow. 

Salesforce continues to transform at a lightning speed – yes, an understatement, I know! Three releases a year are keeping me on my toes! – making it harder and harder to keep my blogs abreast of the new features and functionalities! Whew! Hot out of the oven comes –  Permission Set Group ! Now, this is hot, indeed!

Let us taste it together!

What is a Permission Set Group?

For example, you can compile three permission sets –  CRM User ,  Salesforce Console User , and custom permission set  View and Edit Convert Leads – in a group; a.k.a, the Permission Set Group. You can label the group as ‘Sales Manager Users’ Permission Set Group – see image below.

Then, you can assign the ‘Sales Manager Users’ Permission Set Group, as a single entity , to your users instead of the three different permission sets

Now suppose you assigned the ‘Sales Manager Users’ Permissions Set Group to User A. Then comes User B. In addition to all the permission sets contained in the ‘Sales Manager Users’ Permission Set Group, User B also needs the Manage External Users permission set.

Now what? No worries! Clone the ‘Sales Manager Users’ Permission Set Group and add to it the ‘Manage External Users’ permission set and save it as a new Permission Set Group! You could say, name the new Permission Set Group as ‘External Sales Manager Users’. Simple!

Explore  this article to learn more about the Permission Set Group. 

Business Use case

Martin Jones  is a System Administrator at Gurukul on Cloud (GoC). Today he was going through the release notes and found that Permission Set Group is now generally available (GA). He just created a   permission set group   called ‘Sales Manager Users’. Now, Martin has a requirement to auto-assign the ’ Sales Manager Users’  Permission Set Group to all new users with the Sales Manager Role. 

Automation Champion Approach (I-do):

To solve this requirement, we will use the Custom Metadata Types and   After-save Record-Triggered Flow . Check out this article to understand why we are using after-save record-triggered flow for this scenario.

Before proceeding, ahead,   PermissionSetAssignment   (It represents an association between a User and a PermissionSet)  object in Salesforce.

Before discussing the solution, let me show you a diagram of a Process Flow at a high level. Please spend a few minutes going through the following Flow diagram and understand it.

We will create an automation that will not only work for the current scenario but, it will also work for other Roles as well. This means that, if Martin wants to automate the Permission Set Group assignment for other Roles (Sales Rep, Sales Director, VP of Sales) – it should work without him having to modify automation . 

Guided Practice (We-do):

There are 2 steps to solve Martin’s  business requirement using Record-Triggered Flow . We must:

• Create custom metadata types to store user role and permission group mapping
• Define flow properties for record-triggered flow
• Formula to determine whether the user is created or updated
• Add a Decision element to check whether the user is created and has a user role populated 
• Add a get records element to find the permission set Id for a given role
• Add a decision element to check the record variable (from step 2.3)
• Add a Create Records element to assign a permission set group to a user 

Step 1: Create Custom Metadata Types to store User Role and Permission Set Group Mapping

• Once you are done, click on the Save button.

Step 2.1: Define Flow Properties

• Click Setup .
• In the Quick Find box, type Flows .
• Select Flows then click on the New Flow .
• Object : User
• Trigger the Flow When : A record is created and updated
• Condition Requirements: None
• Optimize the Flow For Action and Related Records
• Click Done .

Step 2.2: Formula to Determine Whether the user is Created or Updated

• Under Toolbox , select Manager , then click New Resource to determine whether the record is created or updated. 
• Resource Type : Formula
• API Name : forB_IsNew
• Data Type : Boolean
• Formula : IsNew()

Step 2.3: Using Decision Element to Check W hether the User is Created/Updated and has a User Role Populated 

Now we will use the Decision element to check whether the user is created or updated and has a user role populated. 

• On Flow Designer, below the Run Immediately   node, click on the +icon and select the Decision element.
• Enter a name in the Label field; the API Name will auto-populate.
• Under Outcome Details , enter the Label the API Name will auto-populate.
• Resource : {!forB_IsNew}
• Operator : Equals
• Value : {!$GlobalConstant.True}
• Click Add Condition 
• Resource : {!$Record.UserRoleId}
• Operator : Is Null
• Value : {!$GlobalConstant.False}
• When to Execute Outcome : If the condition requirements are met .

Step 2.4: Adding a Get Record Element to Find Permission Set Group Id for a Given User

The next step is to use the  Get Records  element to find the permission set group id for a given role. 

• On Flow Designer, below the  Created   node, click on the +icon and select the Get Records element.
• Enter a name in the Label  field; the  API Name will auto-populate.
• Select the User Role PS Group Mapping  object from the dropdown list.
• Select All Conditions Are Met (AND) . 
• Field : Label
• Value : {!$Record.UserRole.Name}
• select Only the first record
• Choose the option to Automatically store all fields . 

Step 2.5: Using Decision Element to Check If Permission Set Group Id  was Found or Not  

Now we will use the Decision element to check the Record Variable from step 2.3  to find if the permission set group id was found or not.  

• On Flow Designer, click on the +icon and select the Decision element.
• Resource: {!Find_Permission_Set_Group}
• Operator: Is Null 
• Value: {!$GlobalConstant.False}

Step 2.6: Add Create Records Element to Assign Permission Set Group to a User

Next, we will use the Create Records   element to assign a Permission Set Group to a User.

• On Flow Designer, below the Yes   node, click on the +icon and select the Create Records element.
• 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 fo r the Permission Set Assignment
• Field : AssigneedId
• Value : {!$Record.Id}
• Click Add Field
• Field : PermissionSetGroupId
• Value : {!Find_Permission_Set_Group.PS_Group_Id__c}

In the end, Martin’s  Flow   will look like the following screenshot:

Once everything looks good, perform the steps below: 

• Click Save .
• Enter   Flow   Label  the   API Name  will auto-populate.
• Click Show Advanced .
• API Version for Running the Flow : 54
• Interview Label : Auto Assign Permission Set Group  {!$Flow.CurrentDateTime}

Almost there! Once everything looks good, click the Activate button.  

Proof of Concept

Next time, when a User is created by a System Administrator at Gurukul on Cloud, the process we created (Using a Record-triggered Flow) will fire and assign  Permission Set Group  to the User based on his/her Role (In this scenario, Sales Manager Role). 

Great! You are done!

Now you can streamline your user access/management process by leveraging Permission Set Group! Availability of Permission Set Group will transform a super Admin into a super-duper Admin. No more lugging through multiple individual Permission Sets! What is there not to love?!

Formative Assessment:

I want to hear from you!

What is one thing you learned from this post? How do you envision applying this new knowledge in the real world? Feel free to share in the comments below.

Submit Query!

Similar Posts

Dynamic Highlights Panel: Conditional Field Visibility for Enhanced Focus

Elevate Your Screen Flows with a Customizable Counter Component

Dynamic Progress Bar for Form Completion in Salesforce Flow

12 thoughts on “ profile so yesterday – auto assign permission set group to a user ”.

Hey I was wondering how i will be if i want to add more than one permission group to be assigned the new user?

You can, but you need to add logic to assign another permission set group to users.

For a scalable solution, create a Custom Metadata Type to store the custom permission sets required for a given user role. Then, in the flow, find this Custom Metadata Type and loop through it to add new assignments to a list. Finally, assign these to the user using a single ‘Create Record’ element.

How to use the same logic but for removing the ps-group

• Pingback: Automatically Assign New Leads to a Sales Engagement Cadence - Automation Champion
• Pingback: How to Fix MIXED DML Operation Error | Indian IT Guys
• Pingback: Assign an Expiration Date to Permission Set or Permission Set Group Assignment - Automation Champion
• Pingback: How to Fix MIXED DML Operation Error - Automation Champion

how can we do it based off of Profiles instead of Role?

Check Profile in Process Builder entry criteria.

What happens if a user changes roles? I’m guessing we will have to add steps to the flow to remove the permission set and assign to permission set to the user.

Yes, you are right here.

Hi Rakesh would you please be able to outline the steps to do this? Thanks so much!

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Discover more from Automation Champion

Subscribe now to keep reading and get access to the full archive.

Type your email…

Continue reading

• 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 » Video » Automate This! — Automatically Assign and Remove a Permission Set

Automate This! — Automatically Assign and Remove a Permission Set

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

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

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

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

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

Understand the object relationship

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

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

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

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

Let’s review the overall process in Salesforce

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

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

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

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

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

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

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

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

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

Let’s document the process

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

One more thing before we get into Flow Builder.

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

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

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

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

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

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

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

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

Let’s build our automation!

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

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

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

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

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

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

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

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

• Name: varPermissionSetName

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

• Name: varPermissionSetAction

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

• Name: varPermissionSetId

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

• Name: varUserHasPermissionSet

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Here’s how you configure the Decision element:

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

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

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

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

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

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

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

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

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

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

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

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

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

Jennifer w. lee.

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

• Jen’s Top 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

Leverage Prompt Builder and Flow Builder to Automate Data Creation | Automate This!

By Erick Mahle | August 16, 2024

Welcome to another “Automate This!” In this live-streamed video series, we cover all things automation, from use cases and best practices to showcasing solutions built by Awesome Admin Trailblazers like you. With automation, you can remove manual tasks, drive efficiency, and eliminate friction and redundancy. In this episode, learn how Erick Mahle leverages Prompt Builder […]

Increase Productivity by Creating Starter Flows Fast Using Einstein for Flow | Automate This!

By Eduardo Guzman | July 11, 2024

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

How I Created a Solution to Test Scheduled Flows Easier During UAT | Automate This!

By Nancy Brown | June 27, 2024

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

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.

Can you access PermissionSetNames from PermissionSetGroup using APEX?

this one should be a quick one. We had a request from our Admins to use PermissionSetGroups rather than merely using the PermissionSets.

I'm messing around with it a bit and noticed that the PermissionSetGroup does not add the PermissionSets to the user. Does not appear that you can access these permissionSets 'names' from the PermissionSetGroup. Is this accurate?

I would have expected a List field on the PermissionSetGroups, but couldn't find anything online or in the docs on how to access.

Anyone else struggling with this? Anyone have any solutions?

IMG_Explaination:

TestGroup is the PermissionSetGroup and contains Test1 and Test2. Manually Added the PermissionSets to get them into the query results

• permission-sets
• permission-set-groups

2 Answers 2

A handy resource for understanding this is the schema doc in Salesforce Object Reference. You can see Profile and Permission Objects and note that there is a junction record called PermissionSetGroupComponent between PermissionSetGroup and PermissionSet

So, to get a list of the component PermissionSets in a PermisisonSetGroup

• cropredy, I'm not sure this query works. Its saying that there is no column When I run the query in Apex... –  thinker Commented Feb 4, 2022 at 16:30
• List<PermissionSetGroup> psg = [SELECT Developername, (SELECT PermissionSet FROM PermissionSetGroupComponents) FROM PermissionSetGroup]; System.debug(psg.size()); –  thinker Commented Feb 4, 2022 at 16:30
• 1 you subquery is missing the .Name –  cropredy Commented Feb 4, 2022 at 20:13

THanks to @cropredy for getting the schema. That's helpful, this code snippet should provide more clarity for people on the forums that are looking for the recipe to access these things.

You must log in to answer this question.

Not the answer you're looking for browse other questions tagged apex permission-sets permission-set-groups ..

• The Overflow Blog
• Mobile Observability: monitoring performance through cracked screens, old...
• Featured on Meta
• Announcing a change to the data-dump process
• Bringing clarity to status tag usage on meta sites

Hot Network Questions

• Reference to formal approach to homotopy analysis method
• When to use negative binomial and Poisson regression
• Word for a collection of awards, such as an Olympic athlete’s earned medals
• Bash script that takes multiple path arguments and checks if files can be successfully created there
• What does this translated phrase convey "The heart refuses to obey."?
• Why does my shifter say the wrong gear?
• We are travelling to Phu Quoc from Perth Australia and have a 9 hour stop over in kuala lumpur do we need a visa to go out the airport?
• Flight delayed, risk of missing connection, can I cancel and get refund?
• What does ציר"ו stand for?
• Lore reasons for being faithless
• Generate vectors with a certain property
• A SF novel where a very poor girl finds a "talking book" meant for daughters of extremely rich people
• Could an alien pathogen actually have an effect on us?
• Is a company liable for "potential" harms?
• What would happen if the voltage dropped below one volt and the button was not hit?
• How can I retain only the lines in code fences?
• Compare Saber and Kyber, about their techniques of message bit layout in encryption
• Overstayed Schengen but can I switch to US passport?
• A coordinate free interpretation of the "lowering the indices" operation
• World Building Knowledgebase - How to write good Military World Building
• What does "if you ever get up this way" mean?
• Making a battery power supply for a portable Raspberry Pi computer
• Should you refactor when there are no tests?
• How to prepare a superposed state?