Manage SharePoint item permissions without HTTP requests in Power Automate
“It was so easy to manage item permissions in SharePoint 2010 flow, but in Power Automate I’m confused from all the HTTP requests and REST API .”
While you could manage permissions easily in SharePoint 2010 flow, in Power Automate it’s a different situation. Now you’ve got two options how to handle the permissions. A simple one using dedicated Power Automate actions and a complex one with HTTP requests and REST API. This post will be about the dedicated Power Automate actions.
Stop sharing an item or a file
The ‘Stop sharing an item or a file’ action breaks permission inheritance and removes permissions from all users and groups, except the ones with Full Control. That means all the Admins / Owners / Users who had Full Control on the list / library before the action will keep it. All it needs is the ID of an item or a file.
To achieve the same functionality via REST API you’d need at least 4 HTTP requests.
1. break permission inheritance
_api/web/lists/getByTitle('ListName')/items(ID)/breakroleinheritance(true)
2. get all current permissions
_api/web/lists/getByTitle('ListName')/items(ID)/roleassignments
3. remove all current permissions (with "X-HTTP-Method": "DELETE" header, in a loop)
_api/web/lists/getByTitle('ListName')/items(ID)/roleassignments(UserOrGroupID)
4. assign back Full Control to Owners / Admins / Users
_api/lists/getByTitle('ListName')/items(ID)/roleassignments/addroleassignment(PrincipalId=UserOrGroupID,roleDefId=FullControlRoleID)Limitation
I heard a complaint that the action keeps the Full Control permissions. That you don’t have control over it. That you can’t remove access for users with Full Control. But I don’t think it’s a valid complaint. If you need to remove users with Full Control, they probably shouldn’t even have Full Control in the first place.
Grant access to an item or a folder
‘Grant access to an item or a folder’ action is the next step after the ‘Stop sharing an item or a file’ action. You removed all permissions from the item or file, but now you need to give some of them back. This action needs a bit more than just an item ID. You have to enter also recipients (users) and Roles to assign. By default it offers only 2 roles in a dropdown: Can edit (Edit permission level) and Can view (View permission level).
Luckily, you can define also your own ‘Roles’ value for the other permission levels, including your custom ones. For example, to assign Read permission level.
This action doesn’t replace as many REST API HTTP request as the one before, but it’s still a few.
1. get user ID
_api/web/siteusers/getbyemail('userEmail')
2. assign permissions to user
_api/lists/getByTitle('ListName')/items(ID)/roleassignments/addroleassignment(PrincipalId=UserID,roleDefId=RoleID)Permission level IDs
As already mentioned, you don’t have to stay with Edit and View permissions, but you can use all the permission levels available on your SharePoint site. Below you can see a table with the default RoleIDs.
| Default permission level IDs | |
| Full Control | 1073741829 |
| Design | 1073741828 |
| Edit | 1073741830 |
| Contribute | 1073741827 |
| Read | 1073741826 |
| Approve | 1073741927 |
| View | 1073741832 |
You can also find all of the permission level IDs, including your custom levels, using browser, REST API (_api/web/roledefinitions), and search (<d:name>).
Limitation
As already mentioned, you can assign permissions only to users (with email address). That means users and Microsoft 365 group. You can’t assign permission to SharePoint group using this action, which I consider unfortunate.
Summary
In my opinion the ‘Stop sharing an item or a file’ action is a good starting point for all permissions setting flows. It saves a lot of HTTP requests and the other related actions.
Not so is the second dedicated action ‘Grant access to an item or a folder’. It’s not a full replacement for the HTTP requests to assign permissions, you’ll still need those for SP groups. But if you use it, it’ll still do some of the work, just don’t expect miracles.
Hello,
Thanks for sharing this useful article.
I tried provided steps. I am getting 404 – File or directory not found. error at the step to assignment of permission.
Hello Ali,
I’d check if the item with the ID exists in the list/library, if you have the action configured correctly.
Hi Tom,
This is great article, exactly what I looking for!!!
This work great since we would like to restrict the access to limited users. Just one question, when there is new person joining the SharePoint site/ lists, he/ she would be able to see all items created in the past correct? Is there a solution on this?
Thanks in advance for your support!
Hello Soon Keang,
it depends whom you assign the permissions:
– If you assign the permissions directly to users, only the selected users will have access.
– If you assign the permissions to a Microsoft 365 or Mail-enabled security group then every new member of that group will have access (and this is a preferred solution).