cancel
Showing results for 
Search instead for 
Did you mean: 

SharePoint Groups for Approvals, Reviews, Emails, and Permissions

Today, 95% of our approval processes that are done in SharePoint Designer workflows leverage SharePoint Groups (not AD security Groups, AAD Security Groups, or O365 Groups) that exist inside of the site collection.  These SharePoint Groups are typically maintained directly by business users.  They also don't have an email address associated with them.  Very rarely are approvals and reviews done just to individual people.  Manager is easy enough, but typically roles are defined for solutions and they are managed by Groups.  Permissions are also typically applied by Groups.

 

 

Based on feedback at MS Ignite, Flow will NOT support SharePoint Groups unless there is a large driver to do so.  Recommendation was to use O365 Groups.  O365 Groups however provision a billion other collaboration tools that are, more often than not, not needed for processes like this.  They would be extreme overkill for simple approval processes.   AD and AAD Security Groups usually involve some form of IT involvement and are not so easy for business users to maintain.

 

Also at Ignite, the majority of approval processes currently demoed and planned for involve "hard coding" individual users, or dynamically selecting your manager.  

 

If Flow is going to be the de facto replacement for SharePoint Designer, it needs to be able to handle these SharePoint Groups, instead of individual names.  Otherwise we'll have to continue to use SharePoint Designer to handle these basic needs.

 

Common Scenarios:

  • Send an Email to all members of a SharePoint Group
  • Start an Approval and Assign it to a SharePoint Group
    • If users are added to the Group, they would have permission to do that Approval
    • If users are removed from the Group, they would lose permission to do the Approval
  • Start a Review and Assign it to a SharePoint Group
  • Assign Item Level Permissions to a SharePoint Group
Status: New
Comments
Level: Powered On

@vwyankee 

 

That's a pretty clever workaround, but it's a shame we even have to do that and I'm sure there are security concerns with using SharePoint lists in that way.

 

The SharePoint REST API has exposed methods for getting group members and interacting with them. There are already connectors for interacting with O365 groups, are there not? If so, THOSE connectors probably just interact with some kind of O365 API. That's the entire point of things like user interface, buttons and "connectors": you hide the abstraction (the code) away and present something easy and clean to the user (people making Flows). 

 

Even if there were just a simple connector that returned something like what "get items" returns, but instead of SharePoint items you'd get user info you can interact with, that would at least be SOMETHING.

Level: Powered On

What is the threshold for MS to acknowledge a Flow idea in terms of votes? This thing has 152 upvotes on it but no acknowledgement from MS. What gives?

Level: Powered On

This thread is also 2 years old now so it's probably stale...