Automating the creation of Office 365 groups via an event triggered process can help business teams use a consistent template across all their groups, especially if there are numerous groups provisioned throughout the year.
For example, in our case we have 500+ custom Office 365 groups that are created and maintained each year. Hence in this case it became obvious we wanted to spin up an Office 365 group from a SharePoint list where users could make the request on their own. Below is a quick overview of the approach and some of the learnings from it. Hopefully this helps.
In this blog – Part 1, we will discuss the approach to the Group creation process and important considerations for provisioning groups. In the upcoming blog – Part 2, we will look at using the Graph App for invoking the graph service and then implementation of the group provisioning process.
Solution overview
The solution uses the below applications.
1. SharePoint List – Data Entry for Groups requests
2. Microsoft Flow – Handles events on the list item create and update
3. Azure AD Apps – Generate App ID and App secret for Graph API calls
4. Azure Function – Automation Code for applying additional rules on the SharePoint sites after the Group is created
High level business logic
The high-level logic flow of the process is as follows. First users make an entry into a SharePoint list. Next step, is to invoke a flow from the SharePoint list item. The flow is based on the defined rules and calls the Azure Function with appropriate parameters. The Azure function then creates the group using the Graph service and assigns owners and members to the group. After the group is created, the Azure Function also applies the later changes to the Group using the SharePoint CSOM.
After the Azure Function has created the group and provisioned the SharePoint artefacts, it will send the success response as the result. In the case of an error, it will reply with an error response.
Important Considerations
For the above process we must make a few important considerations before implementation. There may be slight modifications based on these.
Azure Function Call Sequencing
The most important part of the above process is how we handle parallelism. The Microsoft graph service is not capable of too many subsequent requests from a single tenant, so to make it more robust we can sequence the Azure Function to handle only one request at one time. This can be done by modifying the host.json of the Azure Function as below.
{
"http": {
"routePrefix": "api",
"maxOutstandingRequests": -1,
"maxConcurrentRequests": 1,
"dynamicThrottlesEnabled": false
}
}
Group and SharePoint Site Permission Sync – A LONG wait…
Group creation is managed through an integrated provisioning process handled by Microsoft, so not all artefacts of an Office 365 group are created at the same time. Some components are created instantaneously, such as the Exchange mailbox and SharePoint Site, but others take time to provision such as the AD Office Group security sync. In some cases, the AD Security sync can take as long as 15 min to finish. As such, we must wait to obtain owner level access.
For provisioning the SharePoint artefacts, you can use this blog to set the SharePoint site to allow site scripts.
Error Handling
Since the Group creation process is a long running process, it will be important to make sure that any failure is handled properly, and the process is re-run later.
In our case, we will use the Flow to handle any error case until we have a success as shown below. If you’re using an Azure Queue Storage trigger for the Azure Function, then we can use the Poison queue for handle error runs.
Conclusion
In this blog post we covered the broad level process of the Group Provisioning process, and some important considerations associated with it. Next, we will see how we can implement the remaining processes in the follow up blog.