Monday, November 26, 2018

Flow Approval Workflows with Office 365 and Azure AD Groups

If you've had a chance to use the Flow approvals, you'll agree that it's very easy to configure them and have users respond to them, even from within their email applications.  Building approval workflows is very simple.  All you need is is a trigger that will cause the approval to kick-off and provide a few key pieces of information:



  • Approval type - whether one person or everyone in the Assigned to field must respond to it before the workflow continues
  • Title - this will be the title of the email sent and the approval item in the assignee's environments
  • Assigned to - who will be approving the workflow
  • Requestor - who is requesting the approval

Workflow Assignees

The list of Assigned to is made up of one or more entries.  Each entry will receive an email with the approval notification.  There are three types of email-enabled entities in Office 365:
  • Individual users
  • Office 365 Groups
  • Azure AD Groups
The case of sending approval requests to individuals is straight-forward.  Simply add the individual email address in the Assigned to field and you're done.  However, it's a bit more complex when dealing with Office 365 or Azure AD groups.  Currently, the Approval workflow does not distinguish between individuals and groups.  If you try to type the name of a group, you will notice that the lookup will not resolve it.  In my case, I have a groups office365group and azureadsecuritygroup.  Here's what happens when I try to add them


So what do you do if you need to send approvals to members of groups?  You need to first identify what type of group you have and then retrieve the individual users.


Claims Encoding

One way to tell what type of group you have is to look at the claim that is associated with it.  Each email type is made up of different parameters in the claim encoding.  A claim is made up of 5-6 components, as defined in the SharePoint 2010/2013: Claims Encoding:

<IdentityClaim>:0<ClaimType><ClaimValueType><AuthMode>|<OriginalIssuer (optional)>|<ClaimValue>


When you look at the claims returned for an individual, Office 365 Group, or Azure AD Group, you'll notice the following patterns:

  • Individual - i:0#.f|membership|<user email>
  • Office 365 Group - c:0o.c|federateddirectoryclaimprovider|<GUID>
  • Azure AD Group - c:0t.c|tenant|<GUID>
Without understanding all the intricate details of each claim type, you can use these formats as fingerprints to the type of email address you're dealing with

Resolving Email Addresses

Now that we know how to distinguish between the various email types, the next step is to provide different instructions for your Flow to deal with each.  Below is a snapshot of how I generate a list of all approval emails



It looks complex, but is fairly straight-forward.  Here's the breakdown:

  1. Initialize a string variable that will hold all the email names, e.g. Approval Emails
  2. Get a list of all the email objects.  In my case, I retrieve it from a SharePoint list item People field.  I then iterate through each of the objects as follows
    1. Determine what is the claim format before the second pipe (i.e. |)
    2. If it's for single users, simply add them and a semicolon before them to the Approval Emails string variable
    3. If it's an Azure AD Group or Office 365, get the appropriate group by looking at the claim GUID following the second pipe (NOTE: make sure you use the correct connector to retrieve the groups)
    4. For each group, iterate through the list of users and add their email and a semicolon before it to the Approval Emails string
Once you finished iterating, you can then assign the Approval Emails string to the Approval Request action.

Caveats

As with many solutions, there are some potential caveats here:

  1. Approvals require at least one email address.  Make that the list of approvers (composed of the individuals and groups) constitute one or more email addresses.
  2. If your Azure AD group includes other groups, you'll need to modify this mechanism to drill down to extract the users as well.  This can be done using loops or recursion.

0 comments:

Post a Comment