permission assignment to user

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 permission set to user in apex

Is it possible? Are there any limitations to consider? I have a use case where if a certain relationship is maybe, we would assign a permission set that grants access to a knowledge base data category.

• permission-sets
• lightning-knowledge

2 Answers 2

Turns out it's very easy:

Apex code to Assign Permission Set to Users Created this . Change the query as per requirement and use it , works always

• 3 Can you add some explanation of why this code answers the question? –  Adrian Larson ♦ Commented Oct 2, 2018 at 22:17

You must log in to answer this question.

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

• The Overflow Blog
• Scaling systems to manage all the metadata ABOUT the data
• Navigating cities of code with Norris Numbers
• 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

• Unstable output C++: running the same thing twice gives different output
• How do I loosen this nut of my toilet lid?
• Word to classify what powers a god is associated with?
• Erase the loops
• can a CPU once removed retain information that poses a security concern?
• Cutting a 27×27 square into incomparable rectangles
• What are those bars in subway train or bus called?
• A post-apocalyptic short story where very sick people from our future save people in our timeline that would be killed in plane crashes
• Someone wants to pay me to be his texting buddy. How am I being scammed?
• Is "the above table" more acceptable than "the below table", and if so, why?
• How much air escapes into space every day, and how long before it makes Earth air pressure too low for humans to breathe?
• What's the polarity of this electrolytic capacitor symbol?
• Many and Many of - a subtle difference in meaning?
• Package with environment that changes according to option
• Is Psalm 107:4-7 ascribing the forty years of wandering in the wilderness to Moses refusing to ask for directions?
• Short story in which in which "aliens" from the future appear at a man's door
• Ai-Voice cloning Scam?
• Short story about a committee planning to eliminate 1 in 10 people
• If there is no free will, doesn't that provide a framework for an ethical model?
• Meaning of 折れ込む here
• To what extent do value sets determine polynomials mod p?
• As a resident of a Schengen country, do I need to list every visit to other Schengen countries in my travel history in visa applications?
• How are USB-C cables so thin?
• Suitable tool bag for vintage centre pull rim brake bike

Using Flow to Assign Permission Set

September 17, 2021 Yumi Ibrahimzade Automation , Flow 19

A permission set can be described as a collection of extra permissions and settings that extends users' existing permissions. Permission sets can be used to give extra permissions to users without modifying their profiles. User can have only one profile but they can have multiple permission sets assigned to them. This way, you can have minimum profiles in the system but give various permissions to specific people.

Permission sets can be assigned only to users. It is not possible to assign a them to a public group, role, or profile. Read this article to learn more about permission sets.

There are two different way to assign a permission set. First one is directly from the user record.

Second way is opening the permission set and clicking on the Manage Assignments button.

You have to go to the setup to perform both of these actions, which means that you need admin permissions.

However, using a flow, it is possible to build a screen that lets the current user select a user and a permission set to assign to him/her. This would be a great admin tool for manual assignments. It is also possible to build a record-triggered flow to automatically assign permission set(s) when a user becomes active. This is a great way to reduce manual work. You can read this post to learn about flow types and their differences.

Building a Screen Flow to Assign Permission Sets

1- Create a new screen flow and add screen element as the first element of the flow. Add the lookup element that will let the you select a user. Then add a picklist element, which will display the permission sets in the system. In order to do so, create a record choice set that will display only the permission sets. If you want the flow to display only a few permission sets and not all of them, add your criteria.

Picklist field should display the label of the permission set but store the Id of the selected record. Optionally, store the label of the selected record, it will be useful when displaying a message to the user.

Optionally, rename the Next/Finish button as "Assign". This will make the user think that he/she doesn't need anything else to do. And yes, actually the user doesn't need to do anything else, flow will do everything.

Your screen should look like this.

Optionally, you can set an expiration date for the permission set assignment. If you do so, assigned users receive access to all aggregate permissions until the expiration date. In order to set the expiration date, add a date/time input field.

2- Add a Get Record element and get the PermissionSetAssignment record to check if the selected user already has this permission set.

3- Add a Decision element to check if the user already has the selected permission set.

4- If it already exists, you cannot assign again. So, you will need to display a message to the user. Add a new Screen element to display a message. Optionally, rename the Previous button as "Assign Another". Since you stored the label of the selected permission set in the first step, use it in the error message. This will make the error more clear.

5- If it doesn't exist, then create a new PermissionSetAssignment record to assign the it to the selected user.

If you want to set an expiration date, don't forget to populate the ExpirationDate field.

6- At the end of the flow, display a success message. Like you did in the 4th step, rename the Previous button as "Assign Another" and use variables in the message.

At the end, your flow should look like this. Optionally, make the flow run in the system context.

Record-Triggered Flow to Automatically Assign a Permission Set

Let's create a record-triggered flow that will automatically assign a permission set called "SSO" when a user becomes active.

1- Create a Record-Triggered flow and choose to run it after create/update. Select User as the object and enter the criteria. So that the flow will run only when a user becomes active.

2- Add a Get Records element to get the "SSO" permission set. To assign it, you need the Id of the permission set. You can use a hardcoded value but if you do so, don't forget to change it after you deploy to other environments.

3- Add another Get Records to check if it is already assigned. In order to do so, you have to get the PermissionSetAssignment record according to the user Id and permission set Id that you got in the previous step.

4- Add a Decision element to check if the permission set is already assigned to the selected user.

5- If it doesn't exist, then add a Create Record element to create a PermissionSetAssignment record. This action will assign the permission set to the user.

Optionally, populate the expiration date field.

At the end, your flow should look like this.

These are some simple flows to assign permission sets. You can improve them and add more logic according to your needs. Don't forget, the idea is to help the users. Try to automate the process to reduce time or give the users more capabilities that they cannot perform using the standard permission set assignment screen.

Permission Assignment Expiration Considerations

If you set the ExpirationDate field on the PermissionSetAssignment record, assigned users receive access to all aggregate permissions until the expiration date. It means that, after the expiration date, user will not have those permissions anymore. However, PermissionSetAssignment record will still exist in the system as inactive.

Assignments that expire are treated as soft-deletes. Moreover, SOQL queries don’t return the expired permission set assignments. You can still retrieve them using the ALL ROWS clause. However, there is no standard option to use ALL ROWS clause in flow. Therefore, your Get Records element will not find the expired permission set assignments. This may cause an issue because if you try to create a PermissionSetAssignment record, the system will say that it is a duplicate value.

Read this post to learn how to use flow to assign a permission set with an expiration date.

17 Comments

But for standard user who without "Assign Permission Sets" AND "View Setup and Configuration", is this approach still available?

If you run the flow in the system context, then any user can run this flow and assign permission sets. I tried now and it is working.

Adding to Wayne's comment, even running in the system context, the 'non admin' user receives this error: "An error occurred while trying to update the record. Please try again. insufficient access rights on cross-reference id" I think they need Modify User permissions for this to actually work? Also tried updating another custom field on the User Object and received the same message. I don't think non-admin users have access, even if the Flow is running as System.

Hi Marcus, I tried it again with a non-admin user and it worked. However, I tried it with another user that has Salesforce Platform license, it didn't work for that user. I thought it was related to the license but then I saw that the user didn't have the Run Flows permission. After giving the permission, it worked for that user as well. So I can say that it is working for non-admin users too.

Thank you for this, it was very helpful.

I have followed the guidance for a Record Triggered Flow but got an error - This error occurred when the flow tried to create records: INVALID_CROSS_REFERENCE_KEY: We can't save this assignment because there's no permission set ID or permission set group ID.. You can look up ExceptionCode values in the SOAP API Developer Guide.

Are you able to advise?

In the step that the flow fails, do you see the permission set id? Looks like it is missing, at least it is what I understand from this error message.

If you set an expiration on the permission set and the permission set expires, the permission set assignment record persists. However, when you query the Permission Set Assignment object, you *cannot* retrieve the expired record, so you'll always get a duplicate permission set assignment error when trying to recreate the assignment.

Have you seen the same?

Hi Adam, Yes, that's right. In the official documentation it says "SOQL queries don’t return user assignment information for permission assignments that expire. Assignments that expire are treated as soft-deletes. You can retrieve the expiring assignment information using the ALL ROWS clause." So it is not possible to find this record using standard elements of flow. However, when you try to create a new one, it will say that it is duplicate. I think we may need an Apex action for this. I will try to find a solution.

I found a solution for this issue and wrote a post. Let me know if it answers your question.

https://salesforcetime.com/2023/05/04/using-flow-to-assign-a-permission-set-with-an-expiration-date/

My screen one is all good but for some reason the RTF is getting flagged at the Get permission Assignment Element more specifically the PermissionSetID EQUALS Permission Set From, can you explain what that is supposed to be?

Find all PermissionSetAssignment records where

AssigneeId Equals {!$Record.Id} (005Dn0000075DESIA2) AND PermissionSetId Equals {!Find_AC_Permission_Set.PermissionsViewDeveloperName} (false) Store the values of these fields in Get_Permission_Set_Assignment: Id Result

Info Failed to find records.

Hi, I see a problem here: PermissionSetId Equals {!Find_AC_Permission_Set.PermissionsViewDeveloperName} (false) You have to use the Id of the permission set.

Hi, I am attempting to assign two permissions sets with record triggered Flow, but I am keep getting an error. "This error occurred when the flow tried to create records: INVALID_CROSS_REFERENCE_KEY: We can't save this assignment because there's no permission set ID or permission set group ID.. You can look up ExceptionCode values in the SOAP API Developer Guide."

Hi, From the error message, I understand that the permission set id is missing. Can you check if you mapped that field?

Thank you for the article. Very helpful.

Would there be a way to add more than 1 permission while creating a new user in a flow?

For instance, I usually setup new users similarly to another user. This user may have 3 permission sets. Can I add all 3 at the same time, or would I need to build in the "Assign Additional Permissions" button like you did in the article?

You can get all these 3 permission sets, then use loop and assignment elements in order to prepare a PermissionSetAssignment collection in the flow. Then you can create all of them at once.

How can send email option to the end of the flow, after user assigned to a permission set?

Hi, I didn't understand the question well, but you can send an email using the Send Email core action.

2 Trackbacks / Pingbacks

• What does Group role mean? – Answersglobe
• Using Flow to Assign a Permission Set with an Expiration Date - Salesforce Time

Leave a Reply Cancel reply

Your email address will not be published.

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

Copyright © 2024 | SalesforceTime.com

• 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 Summer ’24 Release Features | Be Release Ready
• Einstein for Formulas | Spring ’24
• Jen’s Top Spring ’24 Release Features
• How to Automatically Deactivate Users Who Haven’t Logged On in 90 Days

Related Posts

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 […]

Flow Enhancements | Summer ’24 Be Release Ready

By Adam White | April 16, 2024

Summer ’24 is almost here! Learn more about new Flow Builder enhancements like the Automation App, Action Button (beta), and more, and check out Be Release Ready to discover more resources to help you prepare for Summer ’24.  Want to see these enhancements in action? Salesforce product manager Sam Reynard and I demoed some of […]

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Assign Azure roles using the Azure portal

• 4 contributors

Azure role-based access control (Azure RBAC) is the authorization system you use to manage access to Azure resources. To grant access, you assign roles to users, groups, service principals, or managed identities at a particular scope. This article describes how to assign roles using the Azure portal.

If you need to assign administrator roles in Microsoft Entra ID, see Assign Microsoft Entra roles to users .

Prerequisites

To assign Azure roles, you must have:

• Microsoft.Authorization/roleAssignments/write permissions, such as Role Based Access Control Administrator or User Access Administrator

Step 1: Identify the needed scope

When you assign roles, you must specify a scope. Scope is the set of resources the access applies to. In Azure, you can specify a scope at four levels from broad to narrow: management group , subscription, resource group , and resource. For more information, see Understand scope .

Sign in to the Azure portal .

In the Search box at the top, search for the scope you want to grant access to. For example, search for Management groups , Subscriptions , Resource groups , or a specific resource.

Click the specific resource for that scope.

The following shows an example resource group.

Step 2: Open the Add role assignment page

Access control (IAM) is the page that you typically use to assign roles to grant access to Azure resources. It's also known as identity and access management (IAM) and appears in several locations in the Azure portal.

Click Access control (IAM) .

The following shows an example of the Access control (IAM) page for a resource group.

Click the Role assignments tab to view the role assignments at this scope.

Click Add > Add role assignment .

If you don't have permissions to assign roles, the Add role assignment option will be disabled.

The Add role assignment page opens.

Step 3: Select the appropriate role

To select a role, follow these steps:

On the Role tab, select a role that you want to use.

You can search for a role by name or by description. You can also filter roles by type and category.

If you want to assign a privileged administrator role, select the Privileged administrator roles tab to select the role.

For best practices when using privileged administrator role assignments, see Best practices for Azure RBAC .

In the Details column, click View to get more details about a role.

Click Next .

Step 4: Select who needs access

To select who needs access, follow these steps:

On the Members tab, select User, group, or service principal to assign the selected role to one or more Microsoft Entra users, groups, or service principals (applications).

Click Select members .

Find and select the users, groups, or service principals.

You can type in the Select box to search the directory for display name or email address.

Click Select to add the users, groups, or service principals to the Members list.

To assign the selected role to one or more managed identities, select Managed identity .

In the Select managed identities pane, select whether the type is user-assigned managed identity or system-assigned managed identity .

Find and select the managed identities.

For system-assigned managed identities, you can select managed identities by Azure service instance.

Click Select to add the managed identities to the Members list.

In the Description box enter an optional description for this role assignment.

Later you can show this description in the role assignments list.

Step 5: (Optional) Add condition

If you selected a role that supports conditions, a Conditions tab will appear and you have the option to add a condition to your role assignment. A condition is an additional check that you can optionally add to your role assignment to provide more fine-grained access control.

The Conditions tab will look different depending on the role you selected.

Delegate condition

If you selected one of the following privileged roles, follow the steps in this section.

• Role Based Access Control Administrator
• User Access Administrator

On the Conditions tab under What user can do , select the Allow user to only assign selected roles to selected principals (fewer privileges) option.

Click Select roles and principals to add a condition that constrains the roles and principals this user can assign roles to.

Follow the steps in Delegate Azure role assignment management to others with conditions .

Storage condition

If you selected one of the following storage roles, follow the steps in this section.

• Storage Blob Data Contributor
• Storage Blob Data Owner
• Storage Blob Data Reader
• Storage Queue Data Contributor
• Storage Queue Data Message Processor
• Storage Queue Data Message Sender
• Storage Queue Data Reader

Click Add condition if you want to further refine the role assignments based on storage attributes.

Follow the steps in Add or edit Azure role assignment conditions .

Step 6: Select assignment type (Preview)

Azure role assignment integration with Privileged Identity Management is currently in PREVIEW. See the Supplemental Terms of Use for Microsoft Azure Previews for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

If you have a Microsoft Entra ID P2 or Microsoft Entra ID Governance license, an Assignment type tab will appear for management group, subscription, and resource group scopes. Use eligible assignments to provide just-in-time access to a role. This capability is being deployed in stages, so it might not be available yet in your tenant or your interface might look different. For more information, see Integration with Privileged Identity Management (Preview) .

On the Assignment type tab, select the Assignment type .

• Eligible - User must perform one or more actions to use the role, such as perform a multifactor authentication check, provide a business justification, or request approval from designated approvers. You can't create eligible role assignments for applications, service principals, or managed identities because they can't perform the activation steps.
• Active - User doesn't have to perform any action to use the role.

Depending on your settings, for Assignment duration , select Permanent or Time bound .

Select permanent if you want member to always be allowed to activate or use role. Select time bound to specify start and end dates. This option might be disabled if permanent assignments creation is not allowed by PIM policy.

If Time bound is selected, set Start date and time and Start date and time to specify when user is allowed to activate or use role.

It's possible to set the start date in the future. The maximum allowed eligible duration depends on your Privileged Identity Management (PIM) policy.

(Optional) Use Configure PIM Policy to configure expiration options, role activation requirements (approval, multifactor authentication, or Conditional Access authentication context), and other settings.

When you select the Update PIM policy link, a PIM page is displayed. Select Settings to configure PIM policy for for roles. For more information, see Configure Azure resource role settings in Privileged Identity Management .

Step 7: Assign role

Follow these steps:

On the Review + assign tab, review the role assignment settings.

Click Review + assign to assign the role.

After a few moments, the security principal is assigned the role at the selected scope.

If you don't see the description for the role assignment, click Edit columns to add the Description column.

Edit assignment (Preview)

If you have a Microsoft Entra ID P2 or Microsoft Entra ID Governance license, you can edit your role assignment type settings. For more information, see Integration with Privileged Identity Management (Preview) .

On the Access control (IAM) page, click the Role assignments tab to view the role assignments at this scope.

Find the role assignment that you want to edit.

In the State column, click the link, such as Eligible time-bound or Active permanent .

The Edit assignment pane appears where you can update the role assignment type settings. The pane might take a few moments to open.

When finished, click Save .

Your updates might take a while to be processed and reflected in the portal.

Related content

• Assign a user as an administrator of an Azure subscription
• Remove Azure role assignments
• Troubleshoot Azure RBAC

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

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

How to change File and Folder permissions in Windows 11/10

How to change file and folder permissions in windows, 1] type of users in windows & permissions, 2] change file and folder permissions which you own in windows 11/10, how to apply the same permission to subfolders and files, 3] manage permission when sharing a file or folder with other users.

4] Change Files and Folders Permissions which you DONT own

Ashishmohta@twc.

SQL Server Database and Server Roles for Security and Permissions

By: Nivritti Suste   |   Updated: 2024-08-13   |   Comments   |   Related: > Security

SQL Server is one of the most used relational database management systems in many organizations. It is mainly used to store, manage, and retrieve data with ease. Apart from this, SQL Server is popular for data security, including encryption, data masking, and role-based access control.

Today, we will discuss role-based access control (RBAC) in SQL Server. Using RBAC, you can assign specific permissions to users according to their roles within the server. There are different types of roles in SQL Server, which can be confusing. Here, we will discuss the distinctions between SQL Server and Database roles, helping us to manage security more effectively.

Let's first understand the roles. There are two types of roles in SQL Server: 1) SQL Server Roles and 2) Database Roles.

What are SQL Server Roles?

SQL Server roles are predefined sets of permissions used to control access to server resources. They are created at the server level and typically assigned to logins or other server roles, which helps administrators manage permissions and security for the entire SQL Server instance. SQL Server roles are like Windows groups, allowing for easy management and assignment of permissions to multiple users.

Types of SQL Server Roles

There are three types of SQL Server roles: fixed server, user-defined server, and application.

Fixed SQL Server Roles -  Fixed server roles are predefined sets of server-level permissions that cannot be modified or deleted. These roles are created during the installation of SQL Server. This includes one of the important ' sysadmin ' roles, which has "God-level control" over the entire SQL Server instance, and other specialized roles like bulkadmin, dbcreator, diskadmin.

User-Defined SQL Server Roles - There are multiple instances when you need custom sets of permissions based on your business needs. Here, user-defined server roles come into the picture; these are not predefined roles. User-defined server roles will allow you to create custom sets of permissions based on your specific needs. These roles granted to logins or only other user-defined server roles provide more control over access to server-wide resources.

SQL Server Application Roles -  The above-mentioned roles are mostly assigned to individual users. This third type of role is like user-defined server roles called Application Roles. These roles are created for applications only and used by applications instead of any individual users. These special roles let applications borrow permissions for a short time to complete the task, keeping regular users and app users separate and safe.

Key Features of SQL Server Roles

• Scope : Server-wide
• Creation : Created at the server level
• Assignment : Assigned to logins or other roles
• Permissions : Control access to server resources (databases, logins, etc.)

Example: SQL Code to Create a SQL Server Role

• Create a SQL Server Role. Replace [role_name] with the desired name for your new server role.
• Assign the User to the Role. Replace [role_name] with the name you chose in Step 1 and [user_name] with the username you want to assign the role to.
• You need to have sufficient permissions (e.g., sysadmin server role) to create server roles and manage user memberships.
• This code snippet only creates the role and assigns the user. You'll need to grant specific permissions to the role itself to control user access within the server.

Example: Granting Permissions to the Role

You can use the GRANT statement.

This grants the "Connect to Server" permission to the newly created role. You can explore other permission options based on your needs.

How to Check Server Roles Using SSMS

• Open SSMS and connect to your SQL Server.
• In the Object Explorer , navigate to Security > Server Roles .
• Expand the Server Roles. You will see all the predefined and user-defined roles listed.

Alternatively, you can use SQL Query:

What are SQL Server Database Roles?

The Database Roles, as the name suggests, are specific to control databases and database objects. Unlike server roles, these roles are created and managed at the database level and can be assigned to database users and other roles within the same database they are created. These roles are a more controlled approach to managing permissions in a SQL Server instance as different users may have different levels of permissions.

Types of SQL Server Database Roles

There are also three types of database roles: fixed database, user-defined database, and application.

Fixed SQL Server Database Roles - Fixed database roles are like fixed server roles in that they cannot be modified or deleted. However, they are limited to the specific database in which they were created. The default fixed database role is ' db_owner' , which has full control over the entire database and other roles like db_accessadmin, db_backupoperator, and db_datareader.

User-Defined SQL Server Database Roles - User-defined database roles allow for the creation of custom sets of permissions within a specific database. These roles can be assigned to users or other user-defined database roles, allowing for more granular control over access to objects within that database.

SQL Server Application Roles - Like SQL Server roles, application roles at the database level are intended for use by applications rather than normal users. They enable applications to temporarily assume permissions and perform actions on behalf of the role, providing an added layer of security.

Key Features

• Scope : Database-specific
• Creation : Created at the database level
• Assignment : Assigned to database users or other roles
• Permissions : Control access to specific database objects (tables, views, etc.)

Example: SQL Code to Create a Database Role

• Create a Database Role
• [role_name]: The desired name for your new database role.
• [user_name]: The username who will own (own as in "be authorized by") the role. This user doesn't necessarily need to be the one assigned to the role.

This statement combines the CREATE ROLE and AUTHORIZATION clauses in a single line. The AUTHORIZATION clause specifies the user who will "own" the database role. This doesn't necessarily restrict who can be assigned to the role, but it determines who can manage the role's permissions later (e.g., adding/removing members and granting/revoking permissions to the role).

• Assigning a User to the Database Role
• [role_name]: The name of the database role you created.
• [user_name]: The username you want to assign to the database role.

This will grant the user the permissions associated with the database role.

• You need to have the db_owner role or equivalent permissions on the database to create database roles and manage user memberships.
• Remember to grant specific permissions to the database role itself to control user access within the database. You can use the GRANT statement for this purpose.

How to Check Database Roles Using SSMS

• In SSMS , navigate to the specific database you want to check.
• Right-click on " Security " and select " Roles ".
• This will show you a list of all the roles defined within that database.

Another way to check database roles with a system view:

• Open a new query window in SSMS.
• Use the below query to check all 'Database_Role.'

Roles Key Differences Brief

When to Use Which Role

• SQL Server Roles: To manage overall user access to the SQL Server instance and its resources.
• Database Roles: To grant granular permissions within specific databases based on user needs.

Best Practices for Using SQL Server and Database Roles

Follow these tips to keep things safe and organized when setting up who can access what in SQL Server:

• Limit Sharing: Only give roles what they need. Don't give extra access.
• Keep Checking: As things change, update roles so access stays right.
• Give Just Enough: Roles and users should only have what they need to do their job.
• Make Your Own Roles: Don't use predefined roles. Create ones that fit your needs.
• Roles for Jobs: Use roles for different jobs to keep things organized.
• Write it Down: Keep track of all the roles, so you don't get confused.
• Double Check: Look at the roles regularly to make sure everything is safe.

Understanding the difference between SQL Server roles and database roles is important to keep your SQL Server secure. SQL Server roles provide server-wide control, while database roles offer more controlled permissions within specific databases. By leveraging these roles appropriately, database administrators and SQL developers can enhance security, streamline permission management, and ensure users have the necessary access without compromising security.

• Check out these MSSQLTips.com Security tips .

About the author

Comments For This Article

Related Content

Understanding SQL Server fixed database roles

SQL Server Database Users to Roles Mapping Report

The Power of the SQL Server Database Owner

Nesting Database Roles in SQL Server

Implicit Permissions Due to SQL Server Database Roles

Retrieving SQL Server Fixed Database Roles for Disaster Recovery

List SQL Server Login and User Permissions with fn_my_permissions

Free Learning Guides

Learn Power BI

What is SQL Server?

Download Links

Become a DBA

What is SSIS?

Related Categories

Auditing and Compliance

SQL Injection

Surface Area Configuration Manager

Development

Date Functions

System Functions

JOIN Tables

SQL Server Management Studio

Database Administration

Performance

Performance Tuning

Locking and Blocking

Data Analytics \ ETL

Microsoft Fabric

Azure Data Factory

Integration Services

Popular Articles

Date and Time Conversions Using SQL Server

Format SQL Server Dates with FORMAT Function

SQL Server CROSS APPLY and OUTER APPLY

SQL Server Cursor Example

SQL CASE Statement in Where Clause to Filter Based on a Condition or Expression

DROP TABLE IF EXISTS Examples for SQL Server

SQL NOT IN Operator

SQL Convert Date to YYYYMMDD

Rolling up multiple rows into a single row and column for SQL Server data

Format numbers in SQL Server

Script to retrieve SQL Server database backup history and no backups

Resolving could not open a connection to SQL Server errors

How to install SQL Server 2022 step by step

SQL Server PIVOT and UNPIVOT Examples

How to monitor backup and restore progress in SQL Server

An Introduction to SQL Triggers

SQL Server Management Studio Dark Mode

Using MERGE in SQL Server to insert, update and delete at the same time

SQL Server Loop through Table Rows without Cursor

• Articles Automation Career Cloud Containers Kubernetes Linux Programming Security

How to manage Linux permissions for users, groups, and others

%t min read | by Damon Garn

Photo by  Tim Mossholder from Pexels

Managing access to resources is a fundamental task for sysadmins. This responsibility consists of three components: identities, resources, and permissions. This article covers several user, group, and file management commands to control access to resources. The article uses a "How do I…?" format, and it assumes you have a few resources to work with. Specifically, I cover the following topics:

• Creating directories and files
• Managing ownership and associated groups
• Setting permissions with absolute and symbolic modes

Setting up a playground

I've been in IT for about 25 years, and most of that time was spent as a technical trainer. That means that the things that I write are usually structured as some sort of lab or other hands-on opportunity. It's just how I cover material. With that in mind, I'll assume you have a couple of identities and resources to experiment with as you read the rest of the article. You can use the following commands to set up a playground. It's best to do this on a virtual machine rather than your personal Linux box, but these tasks are relatively harmless.

Create two new users and two new groups to work with. Note that you do not need to configure passwords for the users in this exercise, as you won't log on with those accounts.

Note : You would use the passwd user01 command to set the user's password.

[ Want to test your sysadmin skills? Take a skills assessment today . ]

In your home directory, create a new directory named playground :

Change into the ~/playground directory by using the cd command. You are ready to work with the commands and concepts below.

When you've completed the article and learned the techniques I've covered, delete the two user accounts, the groups, and the playground directory. Use rm -fR /playground , userdel user01 , and groupdel groupA to remove the resources.

How do I create directories and files?

Use the mkdir command to create directories. The touch command is one of many ways to create files.

How do I create a directory named Resources ?

How do I create a directory path (a series of directories that don't yet exist)?

Note : The goal here is to create the 2020data directory, but the given path's data directory does not yet exist. The -p option creates parent directories as needed to complete the path.

How do I create a file named file1 ?

How do I create several files at once?

How do I manage ownership and groups?

In the playground directory, display the current owner and group associated with the Resources directory and the files.

How do I display permission, owners, and groups?

The ls -l command displays directory contents in long format. The long format contains both permissions and ownership. You can see that the user account that created the resources also owns those resources. The group association is also that user's primary group.

[ Free download: Advanced Linux commands cheat sheet . ]

How do I change the user/owner associated with file1 ?

How do I change the group associated with file1 ?

How do I change the owner and group at the same time for file2 ?

There is a specific chgrp command, but I prefer only to memorize one command ( chown ) and apply it to both functions (user and group associations) rather than chown for the user and then have to recall chgrp for the group.

So how do I use chgrp ?

How do I change the user/group for a directory and all of its contents?

The above task provides a recursive configuration. Technically, recursive commands are repeated on each specified object. Effectively, recursive means "this and everything in it." In the above example, you are configuring the related user/group for the Resources directory and everything in it. Without the -R option, you would only affect the Resources directory itself, but not its contents.

[ Readers also liked:  An introduction to Linux Access Control Lists (ACLs) ]

How do I manage permissions?

The change mode or chmod command sets permissions. The syntax is straight-forward:

Here are two examples of manipulating permissions for file2 :

But wait! Those appear to be radically different examples (they're not, actually). What are all those letters and numbers?

We need to discuss absolute mode and symbolic mode .

How do I use absolute mode?

Absolute mode is one of two ways of specifying permissions. I've seen this mode referred to as octal or numeric mode, but the term I learned was absolute . That term also makes the most sense to me because it's an absolute statement of the desired permissions. I always told my students that this seemed like the most complex of the two modes but is actually the simplest. Usually, they agreed.

Each access level (read, write, execute) has an octal value:

Each identity (user, group, others) has a position:

The absolute mode syntax states the desired permissions from left to right.

How do I grant the user (owner) read, write, and execute, the group read-only, and all others no access to file2 by using absolute mode?

The three permissions values are associated with identities:     ugo     740

• The 7 is assigned to the user and is the sum of 4+2+1 or read+write+execute (full access)
• The 4 is assigned to the group and is the sum of 4+0+0 (read-only)
• The 0 is assigned to others and is the sum of 0+0+0 (no access)

In this example, the user has rwx , the group has r only, and all others have no access to file2 .

Let's look at one more example.

How do I grant the user (owner) read and write, the group read-only, and all others read-only to file2 ?

• The user has 6 (read and write)
• The group has 4 (read-only)
• All others have 4 (read-only)

I find this easier because there are no calculations involved. I'm not concerned with adding or subtracting specific permissions based on the current settings. Instead, I say, "set the permissions to be this," and that's the end result I get. It's an absolute statement.

[ Free cheat sheet: Get a list of Linux utilities and commands for managing servers and networks . ]

How do I set permissions for the Resources directory and all of its contents by using absolute mode?

How do I use symbolic mode?

Symbolic mode uses more symbols, but the symbols are simpler to understand. That's attractive to sysadmins that are new to standard Linux permissions.

Each access level has a symbol:

Each identity has a symbol:

There are also operators to manipulate the permissions:

The general chmod command syntax is the same:

Here is an example:

How do I remove the read permissions from others for file2 by using symbolic mode?

This example removes ( - ) the read ( r ) permission from others ( o ) for file2 .

Here's another simple example:

How do I grant the read and write permissions to the group for file2 ?

This one gives ( + ) read and write ( rw ) to the group ( g ) for file2 .

How do I set permissions for a directory and all of its contents by using symbolic mode?

Special permissions and Access Control Lists

The above discussion covers standard Linux permissions—applying rwx to the user, group, and all others. Linux has far more flexibility, however. Special permissions permit users to run applications with other credentials, control the inheritance of group associations, and keep files from being changed accidentally. Check out this great article on special permissions .

Linux also has a way of enforcing different permissions for different users and groups. Access Control Lists (ACLs) permit sysadmins to define permissions for more than just one user and one group, which adds a great deal more flexibility to standard permissions. For example, user01 can be granted rw- to file1 , while user02 can be granted r-- to file1 . Here is a great article on ACLs .

[ Free course: Red Hat Satellite Technical Overview. ] 

Creating resources, managing users, and setting permissions are fundamental tasks for Linux users. My goal was to provide a quick and easy guide based on common questions or tasks that we must all accomplish regularly. If you're new to Linux, having a solid grasp of the eight commands discussed above will make your sysadmin life much easier.

Damon Garn owns Cogspinner Coaction, LLC, a technical writing, editing, and IT project company based in Colorado Springs, CO. Damon authored many CompTIA Official Instructor and Student Guides (Linux+, Cloud+, Cloud Essentials+, Server+) and developed a broad library of interactive, scored labs. He regularly contributes to Enable Sysadmin, SearchNetworking, and CompTIA article repositories. Damon has 20 years of experience as a technical trainer covering Linux, Windows Server, and security content. He is a former sysadmin for US Figure Skating. He lives in Colorado Springs with his family and is a writer, musician, and amateur genealogist. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the red hat developer program., related content.

How to implement customized role permissions in ASP.NET Core

You often need to add authentication and authorization when developing an application for a user base. But what are they? Why are they so important? This blog post will define these terms and discuss how to implement custom role permissions in an ASP.NET Core API.

What is Authentication?

Authentication secures the application from users unauthorized parties who can access it. It enables an application to give user rights to only those who are registered to the application. 

What is Authorization?

Authorization restricts authentic users from performing only allowed actions based on their permission. With authorization, users are permitted to take only those actions they are allowed to do. It can be considered one step above authentication, categorizing legitimate users on permission levels.

Even though the front end does not allow users to use without login, the backend APIs must be secured only to allow legitimate users to call only allowed APIs. That's why we need authentication and authorization for our ASP.NET Core APIs. In many cases, authorization is more customized to our business logic. Our application contains specific roles, and each has a set of permissions for the actions. Notably, assigning and unassigning those permissions should be dynamic so the admins can change any permission with any role. 

Suppose we have an inventory management application where we are going to apply role permissions.

Step 1: Install the required packages

Step 2: Add configurations in appsettings.json

Step 3: add JWT authentication in Program.cs and Swagger

Adding JWT will show Authorization options in Swagger UI:

Step 4: Create Necessary tables using EFCore migration

All the permissions are hierarchically designed. Permission is organized into Categories such as User, material, etc. Each of them has an action specifying permission for individual API actions. For example, UserCreate, UserRead, MaterialCreate, MaterialStockUpdate, etc. The complete database design for the tables is:

Let’s define enums for each Permission Category and Action. It also helps to compare when checking if a user has the required permission.

The loginUser table will save login logs and return a response when a user logs in.

Step 5: Prepare the Login method  

In the auth service, the following is the login method:

Step 6: Create custom Controller attributes for role permission

To implement permission actions with the roles, we need to define our Attribute similar to [Authorize] provided by .NET Core. It involves defining a policy requirement by implementing the IAuthorizationRquirement from Microsoft.AspNetCore.Authorization . Then add a handler that checks for permission in the claims. Finally, Auth Attribute by implementing and setting the value to policy:

Attribute code lies below:

Step 7: Applying permissions to the API endpoint actions

Similarly,  Add in the RoleController :

Step 8: Insert categories and actions into the database tables

Here, we can utilize either seeding or manual querying. As in the RolePermission table, each role is referenced with many permissionActions. That's why we need to have all the data in their respective table. Just to mention, insert the data into PermissionCategory and PermissionAction tables with Value on each representing Enum value.

Would your users appreciate fewer errors?

Step 9: Coding part for RolePermission, Roles, Actions and Categories.

Here, we have to code to create and get the above entities in repos and controllers. I will mention only the logical parts for working methods, skipping interface, and file structure. 

In repo, the following method assigns actions to a role:

Similarly, a method for unassigning role permission:

Now, creating a method to assign a role to a user:

In contrast, we have UnassignUserRole:

Get methods:

To return role permissions, we can provide two types of methods. One will return permissions in a hierarchy that is usable in claims and login responses. The other is plain data from the RolePermission table. This is usable to show all the permissions seemingly:

Step 10: Create a role

With the role endpoints, I have created two roles. After fetching from the GetRoles, we have:

Step 11: Assign PermissionActions to a role

As we inserted all the permission data in their tables, We exposed endpoints to get those data. 

GetPermissionActions returns the following:

Add permissions to the manager role:

Similarly, Assing permissions to the other role:

Step 12: Assign roles to the users

To be concise, we already have 2 users created:

User 1 - id: 130, email: [email protected]

User 2 - id: 114, email: [email protected]

We have successfully assigned roles to those users. Those roles already have a set of permissions. 

Step 13: Try login

So, we are getting permissions while logging in. The token also encrypts role permissions, which we will use to check the authorization of the logged-in user:

Step 14: Calling the authorized endpoints

After so many long steps, we are going to test them by calling authorized endpoints. The currently logged-in user has only two permissions: reading the roles and material. Just to mention, without logging in, the API returns a 401 error:

After logging in, we can successfully call the authorized endpoint:

Let's try an endpoint not included in the current users’ permission:

It threw Error 403 forbidden as expected. Now, let's assign this permission to our role:

After logging in again, we got a response from the API:

Hurray! We have successfully implemented customized role permission based on our business logic. 

Authentication and Authorization are some of the most critical parts of any application. While AUthenitcation secures sensitive information from external access, authorization ensures the restriction of internal members from accessing any resource which is not allowed to them. In this article, we implemented a customized role permission using .NET Core controller attribute and Identity claims. This blog provides an easy solution to applying personalized permissions to user roles following the application’s business logic.

elmah.io : Error logging and Uptime Monitoring for your web apps

This blog post is brought to you by elmah.io. elmah.io is error logging, uptime monitoring, deployment tracking, and service heartbeats for your .NET and JavaScript applications. Stop relying on your users to notify you when something is wrong or dig through hundreds of megabytes of log files spread across servers. With elmah.io, we store all of your log messages, notify you through popular channels like email, Slack, and Microsoft Teams, and help you fix errors fast.

See how we can help you monitor your website for crashes Monitor your website

Guest posts

Methods to assume a role

Before a user, application, or service can use a role that you created, you must grant permissions to switch to the role. You can use any policy attached to groups or users to grant the necessary permissions. This section describes how to grant users permission to use a role. It also explains how the user can switch to a role from the AWS Management Console, the Tools for Windows PowerShell, the AWS Command Line Interface (AWS CLI) and the AssumeRole API.

When you create a role programmatically instead of in the IAM console, you have an option to add a Path of up to 512 characters in addition to the RoleName , which can be up to 64 characters long. However, if you intend to use a role with the Switch Role feature in the AWS Management Console, then the combined Path and RoleName cannot exceed 64 characters.

You can switch roles from the AWS Management Console. You can assume a role by calling an AWS CLI or API operation or by using a custom URL. The method that you use determines who can assume the role and how long the role session can last. When using AssumeRole* API operations, the IAM role that you assume is the resource. The user or role that calls AssumeRole* API operations is the principal.

The following table compares methods for using roles.

¹ Using the credentials for one role to assume a different role is called role chaining . When you use role chaining, your new credentials are limited to a maximum duration of one hour. When you use roles to grant permissions to applications that run on EC2 instances , those applications are not subject to this limitation.

² This setting can have a value from 1 hour to 12 hours. For details about modifying the maximum session duration setting, see IAM role management . This setting determines the maximum session duration that you can request when you get the role credentials. For example, when you use the AssumeRole* API operations to assume a role, you can specify a session length using the DurationSeconds parameter. Use this parameter to specify the length of the role session from 900 seconds (15 minutes) up to the maximum session duration setting for the role. IAM users who switch roles in the console are granted the maximum session duration, or the remaining time in their user session, whichever is less. Assume that you set a maximum duration of 5 hours on a role. An IAM user that has been signed into the console for 10 hours (out of the default maximum of 12) switches to the role. The available role session duration is 2 hours. To learn how to view the maximum value for your role, see Update the maximum session duration for a role later in this page.

The maximum session duration setting does not limit sessions that are assumed by AWS services.

Amazon EC2 IAM role credentials are not subject to maximum session durations configured in the role.

To allow users to assume the current role again within a role session, specify the role ARN or AWS account ARN as a principal in the role trust policy. AWS services that provide compute resources such as Amazon EC2, Amazon ECS, Amazon EKS, and Lambda provide temporary credentials and automatically update these credentials. This ensures that you always have a valid set of credentials. For these services, it's not necessary to assume the current role again to obtain temporary credentials. However, if you intend to pass session tags or a session policy , you need to assume the current role again. To learn how to modify a role trust policy to add the principal role ARN or AWS account ARN, see Update a role trust policy .

• Switch to a role (console)
• Switch to an IAM role (AWS CLI)
• Switch to an IAM role (Tools for Windows PowerShell)
• Switch to an IAM role (AWS API)
• Use an IAM role to grant permissions to applications running on Amazon EC2 instances
• Use instance profiles

To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Thanks for letting us know we're doing a good job!

If you've got a moment, please tell us what we did right so we can do more of it.

Thanks for letting us know this page needs work. We're sorry we let you down.

If you've got a moment, please tell us how we can make the documentation better.

Jama Connect® Roles & Permissions

• Updated August 14, 2024 16:29

Author: David Duarte

Date: May 23, 2024

Audience: Everyone

Permissions and roles control how users experience Jama Connect®. They restrict users' actions or the content users can see.

Roles provide access to Jama Connect's administrative features. Administrators assign roles to individual users or groups.

Permissions control read and write access to your project. You can be granted permission to an entire project, a project’s folders, or a collection of items in a project. Permissions are assigned to individual users or groups.

Permissions are inherited from higher levels in the organization structure and can be set at different levels:

- Organization

Once permissions are set on a project, they can be adjusted based on the organization of the project Explorer Tree.

To access the project, admins must set the permissions before adjusting a set or component.

- Set permissions at the highest level possible. This helps you track existing permissions for a user or group when many one-off changes are made.

- Use groups instead of individual users. Groups reduce the volume of entries and ensure a consistent setup of users who require similar access.

Please feel free to leave feedback in the comments below.

• Jama Connect®

Was this article helpful?

Have more questions? Submit a request

Article is closed for comments.

To learn more about Smartsheet Regions,  click here .

For more information about plan types and included capabilities, see the Smartsheet Plans page.

Sharing permissions on sheets, reports, or workspaces

When you share an item with someone, the permission level you assign to them determines what they can do. 

✓  = included

x    = not included

Sharing permission levels on sheets

Sheet management.

Any collaborator with Admin access to a workspace can delete and rename the sheets it contains. If a sheet is deleted from a workspace, it's recoverable for 30 days from the sheet owner's Deleted Items folder . Admins can see the item in their folder, but don’t have permission to recover the item.

*Available only to licensed users (Legacy Collaborator Model) or Members (User Subscription Model)

**For User Subscription Model plans, available only to Members  

Collaboration

Project management

*Available only to licensed Enterprise users (Legacy Collaborator Model) or Enterprise Members (User Subscription Model)

Sharing permission levels on reports

**For User Subscription Model plans, available only to Members 

Related Content

Help article, overview: share sheets and reports.

Add collaborators to your sheet or report....

• 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.

How to view the roles and permissions granted to any database user in Azure SQL server instance?

Could you guide me on how to view the current roles/permissions granted to any database user in Azure SQL Database or in general for a MSSQL Server instance?

I have this below query:

I further need to know what are the permissions granted to these roles "loginmanager" and "dbmanager"?

Could you help me on this?

• azure-sql-database

• Not really a full answer but check out this article for details about those roles: msdn.microsoft.com/en-us/library/azure/ee336235.aspx –  cbattlegear Commented Jun 29, 2015 at 16:36

5 Answers 5

Per the MSDN documentation for sys.database_permissions , this query lists all permissions explicitly granted or denied to principals in the database you're connected to:

Per Managing Databases and Logins in Azure SQL Database , the loginmanager and dbmanager roles are the two server-level security roles available in Azure SQL Database. The loginmanager role has permission to create logins, and the dbmanager role has permission to create databases. You can view which users belong to these roles by using the query you have above against the master database. You can also determine the role memberships of users on each of your user databases by using the same query (minus the filter predicate) while connected to them.

To view database roles assigned to users, you can use sys.database_role_members

The following query returns the members of the database roles.

• 1 Gold. Saved me. THank you –  romanzdk Commented Nov 4, 2021 at 13:26

Building on @tmullaney 's answer, you can also left join in the sys.objects view to get insight when explicit permissions have been granted on objects. Make sure to use the LEFT join:

• 3 This does not work as intended when the object to which permission is granted is a SCHEMA. You must also LEFT JOIN to sys.schemas when class_desc = "SCHEMA" –  Pittsburgh DBA Commented Aug 18, 2020 at 18:47

Further building on @brentlightsey 's answer, you can add left join to sys.schemas to also see permissions on a schema level:

if you want to find about object name e.g. table name and stored procedure on which particular user has permission, use the following query:

• Based on the post you've made, I would recommend spending some time reading documentation in the Help Center so that you have the best chance at getting your question answered. –  Brien Foss Commented Mar 8, 2018 at 4:21

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 sql-server azure azure-sql-database azure-sql or ask your own question .

• The Overflow Blog
• Scaling systems to manage all the metadata ABOUT the data
• Navigating cities of code with Norris Numbers
• 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
• Tag hover experiment wrap-up and next steps

Hot Network Questions

• A burning devil shape rises into the sky like a sun
• Density of perfect numbers
• Is there an integer that serves as the short leg of a primitive Pythagorean triple, the long leg of another, and the hypotenuse of a third?
• Erase the loops
• I need to better understand this clause in an independent contract agreement for Waiverability:
• Prove that there's a consecutive sequence of days during which I took exactly 11 pills
• What are those bars in subway train or bus called?
• Does the US Congress have to authorize non-combat deployments (e.g. of advisers and trainers) from the US armed forces to a foreign country?
• Writing a Puzzle Book: Enigmatic Puzzles
• How to understand the use of "used to"?
• Why do individuals with revoked master’s/PhD degrees due to plagiarism or misconduct not return to retake them?
• Does the First Amendment protect deliberately publicizing the incorrect date for an election?
• Why would Space Colonies even want to secede?
• The minimal Anti-Sudoku
• Short story about a committee planning to eliminate 1 in 10 people
• When is internal use internal (considering licenses and their obligations)?
• A study on the speed of gravity
• If there is no free will, doesn't that provide a framework for an ethical model?
• Is it normal to be able to tear off PCB components with bare hands?
• Union of lists with original order
• Can you bring a cohort back to life?
• Returning to France with a Récépissé de Demande de Carte de Séjour stopping at Zurich first
• As a resident of a Schengen country, do I need to list every visit to other Schengen countries in my travel history in visa applications?
• What's the polarity of this electrolytic capacitor symbol?

Secret Service busted into a salon to let people use the bathroom during a Kamala Harris fundraiser, business owner says

• Secret Service taped over a Berkshire business's security camera while Kamala Harris was in Mass.
• Soon after, strangers came into the salon — which was closed and locked — to use the bathroom.
• The business owner said she felt "violated."

It was worse than a bad hair day.

Secret Service agents taped over a security camera and broke into a Massachusetts hair salon while securing the area for a Kamala Harris campaign event, according to the salon's owner.

The intrusion happened on July 27, ahead of Vice President Harris's first in-person fundraiser since becoming the presumptive Democratic nominee.

The owner of the Four One Three Salon, Alicia Powers, told Business Insider that she closed her Pittsfield, Massachusetts, business that day at the request of the Secret Service, which examined the area earlier in the week. The salon is located behind the Colonial Theatre, a performing arts space in the Berkshires, where Harris spoke.

"They had a bunch of people in and out of here doing a couple of bomb sweeps again — totally understand what they have to do, due to the nature of the situation," Powers told Business Insider. "And at that point, my team felt like it was a little bit chaotic, and we just made the decision to close for Saturday."

A Secret Service spokesperson told Business Insider that the agency's employees "would not enter" without the permission of the business owner, but acknowledged an agent taped over the security camera lens.

At 8:10 that Saturday morning, a Secret Service agent — wearing a dark suit and open-collared white shirt, but no pin on her lapel — walked up to the salon's front entrance while swinging a roll of masking tape in her left hand. She looked at the door. Then she looked at the security camera on the porch. Then she looked at the door again.

She walked away. When she returned two minutes later, she grabbed a chair from the porch, stood on it, and taped over the Ring security camera that had been watching her.

(Business Insider blurred the face of a Secret Service agent in the video below.)

The door was locked. But later that afternoon, another security camera, pointing at the door from the inside of the building, spotted four other people over the course of nearly two hours.

Two people wearing emergency medical services uniforms and one person in a camouflage law enforcement uniform walked in. The fourth person, wearing a dark suit and white shirt like a Secret Service officer, stood by the door.

The salon's security alarm rang the whole time. The security footage from the two cameras, which Powers shared with BI, doesn't show anyone allowing the people in.

"There were several people in and out for about an hour-and-a-half — just using my bathroom, the alarms going off, using my counter, with no permission," Powers said.

"And then when they were done using the bathroom for two hours, they left, and left my building completely unlocked, and did not take the tape off the camera," she continued.

Related stories

Powers told BI that an EMS worker later told her the Secret Service agent in charge of security that day "was telling people to come in and use the bathroom."

BI asked Secret Service spokesperson Melissa McKenzie whether the agency invited other people to use the bathroom. She told BI that agency employees "would not" tell someone to enter the salon without the owner's permission.

When Powers returned to the property later that day, she found the door's lock looked like it had been picked, she told BI.

The people who entered the Four One Three Salon didn't do much damage aside from leaving an untidy bathroom behind, Powers said.

But what bothered her was what she saw as sheer disregard for her business, by entering without permission and leaving the place unlocked when they left, she said.

Powers said she felt "violated."

"Whoever was visiting, whether it was a celebrity or not, I probably would've opened the door and made them coffee and brought in donuts to make it a great afternoon for them," she told BI. "But they didn't even have the audacity to ask for permission. They just helped themselves."

Brian Smith, the building's landlord, said he didn't give the Secret Service permission to use the property either.

"Me and my dad own the building, and I have a crazy eccentric guy that lives upstairs," Smith told BI. "And he didn't tell the Secret Service they could use it, and I didn't tell them, and my father didn't tell them, and they had no permission to go in there whatsoever."

The Secret Service apologized after BI reached out

The day after BI initially reached out to the Secret Service for comment for this story — more than a week after it entered the business — an agency spokesperson said it had "since communicated" with Powers.

"The U.S. Secret Service works closely with our partners in the business community to carry out our protective and investigative missions," McKenzie wrote in an email to BI. "The Secret Service has since communicated with the affected business owner."

"We hold these relationships in the highest regard and our personnel would not enter, or instruct our partners to enter, a business without the owner's permission," she added.

Bill Pickle, a former Secret Service special agent, who previously oversaw training for the agency, told Business Insider that it's conceivable why a member of the Secret Service would tape over the security camera lens.

Pickle speculated that someone from the agency's technical services division — which handles explosives, bugging, wiring, and other physical security risks — may have wanted to limit visibility of Harris's whereabouts if the vice president were to walk into the camera's view.

But invading the property to use the bathroom "sounds weird," Pickle told BI.

"We just don't go in and take place or seize it," Pickle said. "The only time you do that is if it's a crime scene or if there's a real threat."

Powers said she contacted a local Secret Service field office after the incident, and that a person there told her to ask the local police, who said they knew nothing about it.

"I know for certain none of our members were involved in this," Pittsfield Police Captain Matthew Hill told BI.

On Thursday morning — the day after BI reached out to the agency for comment — the head of the Secret Service's Boston-based field office called Powers to apologize, she said.

"He said to me everything that was done was done very wrong," Powers said. "They were not supposed to tape my camera without permission. They were not supposed to enter the building without permission."

Powers said the Secret Service representative she spoke to offered to have the salon cleaned and pay her alarm company bill for the day. Powers said he also offered to visit and apologize in person over a cup of coffee.

Powers said she'd take him up on it.

"I want him to see the salon, and I want him to see what I do for the community, and be in this space, and have an understanding as to how this could have been ruined with the slightest wrong move," she said.

Watch: How the Secret Service protected Trump after 'screwing up'

• Main content

• Send us a story

Stay Updated

• PARIS 2024 OLYMPIC APPS ASK FOR DANGEROUS PERMISSIONS

Paris 2024 Olympic apps ask for dangerous permissions

The Paris 2024 Olympic apps are under scrutiny for tracking sports tourists and sharing private data with advertisers and big tech. A report from Cybernews reveals that many apps require excessive permissions, collect detailed user data, and potentially compromise users' privacy and security.

As Paris city attracted a large number of sports tourists, the apps for the Olympic Games 2024 are tracking them, extracting private data, and peddling it to advertisers and big tech.

According to a report from the Cybernews research team, which selected 12 Android apps relevant to the Olympic Games attendees in Paris and tested their permissions, the apps designed to help users during the Olympics are underreporting their data collection scope on Google Play Store , require excessive dangerous permissions, and share sensitive user data with advertisers.

Paris 2024 Olympic apps ask for dangerous permissions: There is no privacy during the Olympics

Bonjour RATP app, a travel app for navigating Paris, buying transportation tickets, and finding routes, is the most data-hungry app in the selection. The Data Safety section reveals that it collects 18 data points from 38 possible and shares most of them with third parties.

Not only does Bonjour RATP collect precise location data for its functionality, but it also shares the user’s location for the declared purposes of advertising, fraud prevention, security, and compliance. The app has more than 10 million downloads on Android.

TheFork app, Europe’s leading restaurant booking platform, collects 15 data points and zaps almost all of them to third parties. Even email addresses and phone numbers are shared for advertising or marketing purposes, the app developer declares.

Citymapper app, another city transport app with more than 10 million downloads, collects 14 data points, but advertising is not mentioned among the declared purposes for sharing.

The Paris 2024 Olympics and The Paris 2024 Public Transport apps require 9-11 data points each.

The Paris 2024 Olympics app, already downloaded more than 10 million times, collects user data, such as web browsing history, email addresses, devices, and other IDs, and beams it to advertisers. It also asks for multiple dangerous permissions that allow it to tap into the deepest secrets you may hide on your Android phone.

The International Olympic Committee (IOC) openly admits that it collects personal data, builds user profiles, and shares data with advertisers, including Facebook, Google, Apple, or X.

“When required, prompts are presented to users to allow them to consent to specific features to enhance their app experience. When first interacting with the app, users may agree to or reject cookies. At any time, users have control over the permission they granted via the device and app settings,” IOC said to Cybernews.

The Paris 2024 Public Transport app, made by a government agency, will share names, emails, and app activity. Security and compliance, fraud prevention, functionality, advertising, and analytics are all among the declared purposes.

Stakeholder Experience & Access Tool (S.E.A.T.) and PinQuest require some of the most dangerous permissions.

S.E.A.T. is designed to support specific accredited stakeholders at the Games. Although it says it collects no data, it asks users for dangerous permissions to read and write to external storage, read and write contacts, check and update calendars, and access media files on the device.

Even PinQuest, a fun game to discover and test Olympic knowledge, will ask permission to access the camera and files, even if it says it does not collect any user data.

Most data-hungry apps for the Olympic Games Paris 2024

Some apps hide they want dangerous permissions

Three out of 12 analyzed apps declare they will collect precise location data. However, the researchers found that three more apps will ask for permission to know your exact latitude and longitude: Paris 2024 Olympics, Paris 2024 Public Transport, and Paris 2024 Transport Accred.

“Location data is required for providing services like venue navigation, event location information, and personalized recommendations based on user location. It may be that the data will stay on the device. However, if the service gets compromised, the users may be exposed to both digital and physical threats,” said security researcher Mantas Kasiliauskis.

Number of apps requiring dangerous permissions

Half of the apps want to peek through camera, access storage

The most widely used dangerous permission, asked by seven out of 12 tested apps, was storage access, meaning that apps want to read and write files on the device. Allowing this may be dangerous, as it enables apps to check and modify files, including those on external media, such as SD cards.

“Usually, apps require storage access to cache data, such as maps, downloaded transport schedules, user preferences, and others,” Kasiliauskis explains.

Half of the analyzed apps also want access to your camera, meaning they could potentially take photos and record videos without additional permission.

“Cameras have many legitimate uses, such as scanning ticket QR codes or credit cards, verification, taking selfies, reporting issues, and capturing moments. It is important to remain vigilant and ensure that cameras are only used for stated useful purposes, and not something malicious,” Cybernews researchers said.

Three apps want permission to communicate with NFC tags and two apps ask permission to record audio, which might help users interact with an app via commands. However, if exploited, this permission can be used for unauthorized surveillance or unconsented marketing.

None of the app developers declared to Google that they collect video and audio recordings, and three apps declared that they collect photos.

“The app should help you enjoy the Olympics, but it shouldn't need to know your whole life story or what websites you visit to do that. This appears as a textbook example of privacy overreach. It’s concerning, given the stated intentions to build detailed user profiles and share data with tech giants. Unfortunately, invasive data collection is a longstanding industry trend, and lots of apps try to grab more data than they need,” Kasiliauskis said.

Improperly handled permissions and data can leave users vulnerable to unauthorized access, identity theft, data breaches, and other cyber threats.

Research Methodology

The Cybernews research team examined 12 Android apps relevant to the Olympic Games attendees in Paris, which can be downloaded on the Google Play Store, to determine what data they access and might collect.

First, Cybernews researchers analyzed app developers' self-declared “Data Safety” claims on the Google Play Store. These do not show the full picture but already reveal redundant data collection practices.

What data will Olympic apps collect about you

MEMBERS GET ACCESS TO

Subscribe here, featured stories.

SuccessFull SignUp

Get More App News

macOS Sequoia

Macos sequoia will now prompt you monthly (not weekly) for screen recording permissions.

Apple has changed its screen recording privacy prompt in the latest beta of macOS Sequoia. As we  reported last week , Apple’s initial plan was to prompt users to grant screen recording permissions weekly .

In macOS Sequoia beta 6 , however, Apple has adjusted this policy and will now prompt users on a monthly basis instead. macOS Sequoia will also no longer prompt you to approve screen recording permissions every time you reboot your Mac.

Apple’s initial plan to require authorization weekly prompted a lot of blowback from Mac users, including  Jason Snell at Six Colors  and  John Gruber at Daring Fireball . Apple seemingly heard all of this feedback and determined that a one-month approval window is a fair compromise.

In macOS Sequoia beta 6, you’ll see a new prompt that reads:

“[App name] is requesting to bypass the system private window picker and directly access your screen and audio. This will allow [app name] to record your screen and system audio, including personal or sensitive information that may be visible or audible.”

You can then choose to “Allow For One Month” or click “Open System Settings” and immediately be taken to the preferences pane for screen recording permissions.

One thing to note: this change is currently only in macOS Sequoia 15.0 beta 6 and the latest public beta. It has not yet been implemented in the macOS Sequoia 15.1 beta.

Apple still hasn’t elaborated on whether there’s an API or entitlement that developers can use to prevent their app from showing this prompt every month. According to multiple developers who spoke to 9to5Mac , this prompt even applies to apps that use ScreenCaptureKit , a new framework introduced with macOS 12 meant to improve screen recording features for third-party apps.

Following my initial report, Craig Hockenberry pointed to a potential solution: the Persistent Content Capture entitlement . But as he eloquently described it: “The issue here is that Apple has provided no documentation or any other guidance on how to get this entitlement.”

As I explained last week, this change has wide-ranging impacts. It will affect third-party screenshot utilities, such as CleanShotX , as well as sharing your screen in apps like WebEx, Discord, Zoom, and Slack. Apps that use screen recording permissions for other purposes, like the menu bar tool Bartender, will also be affected.

9to5Mac’s Take

A permission request on a monthly basis is certainly better than one on a weekly basis, but I still think there needs to be a way to permanently grant an app screen recording permissions.

Additionally, Apple’s lack of communication with developers about this change has only made things more confusing and frustrating. Likewise, I’ve reached out to Apple multiple times for clarification and have not received a response.

Follow Chance :  Threads ,  Twitter ,  Instagram , and  Mastodon .

FTC: We use income earning auto affiliate links. More.

Check out 9to5Mac on YouTube for more Apple news:

Chance is an editor for the entire 9to5 network and covers the latest Apple news for 9to5Mac.

Tips, questions, typos to [email protected]

Manage push notifications