I have developed a solution for storing sensitive client documents in a set of folders in a SharePoint site's Shared Documents library: one folder per client. Individual access is granted to a folder when a user takes on a role in relation to the client, and removed when the user leaves that role. When the client moves to a 'closed' state, I reset all permissions to the default (no individual user access). I also use the individual permissions on a folder to determine who should be notified when a document is placed in the folder.
To do all this I use several Flows containing different HTTP calls to SharePoint:
1) When a user is granted access to a folder I use the action Grant access to an item or a folder
2) When a user's access is revoked I use the action Send an HTTP request to SharePoint with the URI set to:
_api/lists/getByTitle('Documents')/items(<FolderID>)/roleassignments/removeroleassignment(principalid=<UserIDtoRemove>)
3) When the client record is closed I use the action Send an HTTP request to SharePoint with the URI set to:
_api/Web/lists/getByTitle('Documents')/items(<FolderID>)/ResetRoleInheritance()
4) When I want to notify users when a file is added to a folder I user the action Send an HTTP request to SharePoint with the URI set to:
_api/web/lists/getbytitle('Documents')/items(<FolderID>)?$expand=RoleAssignments/Member/Users,RoleAssignments/RoleDefinitionBindings
and then I parse the output to get any PrincipalId values in the ['d']?['SharedWithUserID'] section of the returned body and then find the users' emails from that.
Checking the folders in SharePoint, it all seemed to be working fine and I could see the users' permissions being added and removed successfully as planned. Then I noticed that notifications were being sent to people who no longer had access to certain folders. These seem to be those whose permissions had been reset after the client record was closed. I confirmed that these users' IDs were being returned in the SharedWithUserID list, which I expected to be null. It seems that the ResetRoleInheritance action is removing users' permissions, as seen in SharePoint, but they are still included in the SharedWithUserID list.
Am I missing something here in relation to how SharePoint permissions work?
