Remove Specific User Access to a SharePoint List Item

[Gottijay2000]

I have item level permissions set up on SharePoint List, but i would like the ability to remove specific user access to some items. i'm seeing alot of information around adding users but nothing on removing users.

Any one have an idea on how to achieve this please?

[sudharsan1985]

Hi @Gottijay2000 

You can try using 'Send Http request to SharePoint' using the REST API to change the permission of an item.

[Gottijay2000]

 @sudharsan1985 do you know what endpoint would do the trick?

[sudharsan1985]

Hi @Gottijay2000 

Please refer the below links.

https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/set-custom-permissions-on-a-list-by-using...

https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/get-to-know-the-sharepoint-rest-service?t...

[Gottijay2000]

@sudharsan1985 none of the links have what i'm looking for which is the ability to remove a user from an item that has item level permissions

[sudharsan1985 · Accepted solution]

Hi @Gottijay2000 

To modify the item permission,

1. You have to break the inheritance from the parent which can be done using the below endpoint

_api/web/lists/getByTitle(<List Title>)/items/getById(<Item id>)/breakroleinheritance(copyRoleAssignments=false,clearSubscopes=true)

2. Find the permission level ID.

_api/web/roledefinitions/getByName('contribute')

3. Get the user id

4. You have to assign the user the above roledef id

_api/web/lists/getByTitle(<List Title>)/items(<Item ID>)/roleassignments/addroleassignment(principalid=<user id>,roledefid=<roledef id>)

[MattWeston365]

Hi @Gottijay2000 I'm delving back into my memory to when I used to do more SharePoint development, and if I remember correctly then there wasn't an explicit "remove" endpoint. The way that we did it was to reset and reapply the permissions without the user that you wanted to remove.

Is it too late to consider using SharePoint groups for your permissions instead? They are much more manageable through code.

[Gottijay2000]

@sudharsan1985 this was helpful thanks. 

[sudharsan1985]

Hi @Gottijay2000 

Please mark the correct response as a solution to help others in the community.

[Anonymous]

https://siteURL/_api/web/lists/getbytitle('listName')/items(itemID)/roleassignments/removeroleassign...)

[OliverR-82]

Anonymous' reply is a better answer to the initial question than the one that is currently marked as a solution. The question was if there was a way to remove a specific user's permissions on an item, which is what Anonymous' answer does. Whereas the suggestion that is currently marked as solution really only adds permissions for a user after breaking permission inheritance. A workaround could be to remove all permissions for all users and then reassign permissions for all users that still need them, as suggested by MattWeston365. While that is a way to achieve the desired endgoal, it's a workaround that, depending on your list and number of users, may result in a lot of unnecessary action requests from your flow.

So, to confirm Anonymous' answer, the below action removes one specific permission from one specific user, on one specific item. Do note, though, that you do need to break permission inheritance first. If you're going to need to assign unique permissions for all items in your list, it's best to break inheritance on your entire list. If you only need unique permissions on a single item, then you can break inheritance using the HTTP request described in step 1 of sudharsa1985's solution.

The following action works for me.

The URI is:

_api/web/lists/getbytitle('Meeting Notes')/items(90)/roleassignments/removeroleassignment(principalid=<userId>,roleDefId=<permissionID>) 

To get the user's principal ID, you need to make an HTTP request to the following URI:

_api/web/siteusers/getbyemail('jsmith@mysite.com') 

The URI to get the roledefID was already mentioned above, but I'll repeat it here for completeness sake:

_api/web/roledefinitions/getByName('contribute')

[Rampriyar2022]

This solution is not removing users, its only assigning different role. not sure why this is marked as accepted solution. Totally misleading!

[OliverR-82]

@Rampriyar2022  You're right, the marked solution does not really address the original question. But read the entire thread, there is a proper solution posted by Anonymous user. I also elaborated on it to further clarify. Hope it helps you.

[automateayoshii]

very good answer... thanks you and Anonymous!!

[shavora]

I will make use of your solution. Just one question, if the inheritance is already broken, I do not need to apply the steps to re-break the inheritance right? @OliverR-82 

[shavora]

Seems I have yet another question, which I don't know if you can answer. Is there a way to see in Power Automate which users have been given permission. Our scenario is that when a new distinct user is added, the old distinct user gets removed (but we keep all the other users that has permission so resetting won't work).

[OliverR-82]

Hi @shavora 

1. Correct, once permission inherritance is broken on an item, you don't need to break it again; permission inherritance will remain broken until you explicitly restore it again.

2. Yes, querying the SharePoint API via the HTTP action it is possible to check existing item-level permissions for a given user. To do that, you'll need to make 2 separate calls to the SharePoint API: one to get the principal ID of the user on the site (this can differ between site collections), and one to check the user's permissions on a given item.

Get the principal ID of a user by their e-mail address

Use the following Uri to get the user's principal ID:

_api/web/siteusers/getbyemail('user@yourdomain.com')?$select=Id

Specifying the "?$select=Id" at the end will make it so that you only get back the Id, which is what you need. It's always good practice to limit as much as possible the amount of data that is exchanged when making API calls. The less data is transferred, the quicker your flow will run. The output will look like this:

To use this output in following actions, you would use the expression (noting that I renamed my action to "Get user ID" and any spaces should be replaced by underscores when used in expressions):

body('Get_user_ID')['Id']

Checking the user's permissions for an item

Use the following Uri to get the permissions:

_api/web/lists/getbytitle('<list displayname>')/items(<item id>)/roleassignments/getbyprincipalid(<Id returned by previous action>)/RoleDefinitionBindings?$select=Name

Again I'm appending "?$select=Name" to the end to get just the info I need and nothing else. The output wil look like the following:

In the above example, the user has "Read" permissions on the item. Depending on the permissions of the user, the output can be something else, eg. "Contribute" or "Full control".

To reference that value, you would use the following expression (again noting that I renamed my action to a meaningful name, replacing any spaces with underscores):

body('Check_permissions')['value']['Name']

If the user in question does not have any permissions on the item at all, the "Check permissions" action will fail with a status of 404 and a message saying "Can not find the principal with id: xx".

I hope this helps you solve your problem.

[OliverR-82]

I experimented a bit further with these API calls and, if you wanted to, you could also get an overview of all the users and their permissions for a specific list item by querying the following Uri:

_api/web/lists/getbytitle('<list displayname>')/items(<item id>)/roleassignments?$select=RoleDefinitionBindings/Name,Member/Title&$expand=RoleDefinitionBindings,Member

This would give you an output like the following:

You could also get the users' e-mail addresses instead of their display names by replacing Member/Title with Member/Email in the Uri. Just thought I'd share this here in case it was of interest to anyone.

[SteveCochrane]

The main problem with this solution is that you need to reset everyone else's permissions on the item. The "Anonymous" and Oliver's responses worked for me. Imagine if you have 3-10 different users or groups who have access to this specific item. In your solution, the flow will need to 1.) read all the other existing permissions, then, 2.) add them back again.