“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)
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|
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>).
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, that’ll always need an HTTP request.
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.