A flow should be able to change the permission of an item in a SharePoint List/document library; this is a very popular pattern in Sharepoint workflows
The following two actions should now be available:
1. Grant access to an item or a folder
2. Stop sharing an item or folder
Please check out these new actions in the SharePoint connector and let us know if you have any feedback!
@NickO the solution controls the user's permissions and can be controled so that they don't have "Full Control". The Full control permission is what will allow an user to update permission for others on the list item. If you don't want them to have it, keep their permissions to Edit, Contribute, Read, or design (Reference: https://docs.microsoft.com/en-us/sharepoint/understanding-permission-levels).
@NickO I updated my post and Flow. Now it includes security actions preventing non-authorizing Flow run.
We need this, too.
Happy to share that we have started implementing flow actions to grant access to items and files in SharePoint. We will share more details as we get closer to the release.
This would be fantastic.
At the moment I'm looking at basic approval system. User creates a record in a list, flow sends it for approval.
What I would like is for the Flow to update a column in the list to say Approved and then change the permission of the list record, so the user can't edit the record after approval. Would this help here?
Is it possible to specifity who gets or doesn't get access though?
If items is updated then remove access from "Group X" but leave "Group Y" permission intact?
I would not consider this complete functionality as requested, it would not bee too usable in the current form.
Grant Action - Breaks Permission and Adds the user if they do not already have access.
Whilst this is OK the following changes would be a good addition
1. Use sharepoint ootb permissions levels
2. add user regardless if they already have access
Often you may add a user and manager to a list item and then remove another group i.e. Intranet Members. In the current functionality this would break as they would of never been added.
Stop sharing - should be renamed to be clearer to match SharePoint interface i.e. Stop Inheriting Permissions. - This action also returns 403 forbidden currently. (so i am assuming that is what the action does)
There also needs to be a 3rd flow action to remove specific permissions. i.e. the opposite of specific grant action.
Plumsail do this in 1 flow action and very easy to use and covers all bases.
Action Type - Grant or Remove
Target - Site, List, Item, Folder, Document
Role Type - Contribute, Full Control, Read, Design, Edit
SharePoint Site URL: URL to the site
User or Group
If List - Title or URL of the List
if Item - Title or URL of the List and the Item ID
if Folder - Folder URL
if Document - Title or URL of the Library and the Item ID
So close and yet so far. It feels like who ever was scoping this has never worked with SharePoint workflows using SharePoint designer and used the built in actions for permissions that already existed. We need at least those same actions if we want to transition existing workflows over to Flow.
The most important action for me was "replace permissions" which broke the inheritance, removed everything existing, and allowed you to specify what the new full set of permissions for that item looked like. It was a single action.
Also, we NEED to be able to work with (add/remove) SharePoint Groups, not just users.
We can already access this functionality via rest-api calls using the send http request sharepoint action, but they're very very time consuming to set up and troubleshoot compared to the SharePoint designer actions we're all coming from.
If you need help figuring out how to move forward with this, please contact me, I'd be happy to work with you to make sure this is going to fit the needs of the people who are transitioning business processes that have already been established. I can provide examples of all the various situations these things are used for.