- 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:
- Initialize a string variable that will hold all the email names, e.g. Approval Emails
- 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
- Determine what is the claim format before the second pipe (i.e. |)
- If it's for single users, simply add them and a semicolon before them to the Approval Emails string variable
- 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)
- 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:
- 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.
- 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.
No comments:
Post a Comment