Microsoft Flow Provisioning Office 365 Groups, SharePoint sites, applying PnP templates, queuing...

[sergeluca]

Last month in my spare time, I created a Flow that:

• Provisions a SharePoint site
• Applies a PnP Template
• Waits for the site to be completed

or

• Provisions an Office 365 group

I'm working to extend this Flow, with:

• Azure VM creation
• Microsoft Teams creation
• Bot interaction
• several level of Approvals (already done in another project before)

Provisioning SharePoint sites and applying PnP templates was a little bit more complex than provisioning Office 365 groups from Microsoft Flow and you will see why in a couple of minutes.

The scenario is the following : a user wants to have a new Office 365 group, or a new Azure virtual machine or a new SharePoint site; he will use a PowerApps application to submit the request into a SharePoint list, or he can directly make the request in the SharePoint list; there are several content types for each type of object (VM, Site, O365 group) in the SharePoint list and the flow checks which content type has been used.

The high level view of the flow looks like this : 

In part 1 I will show you how I implemented the site provisioning and in part 2 I will describe how I implemented the Office 365 group creation.

  Part 1.Provisioning sites

Here is the user input form :

Then a (work)flow is automatically triggered (action when an item is created) and will proceed to the site creation.

The flow will just notified the user (it will update the SharePoint list item status) that the site is being provisioned. This is the goal of the first action Update Workflow status in SharePoint.

And when everything is completed (site provisioned and template applied), the flow updates the request status again ("Update workflow status in SharePoint")

Easy so far 🙂

However provisioning the site/ site collection cannot be done directly in Flow. That's why I had to rely to an external REST Service (a "custom connector" as we call it in Flow), more  specifically to an Azure function to make it simple.

Here is what I did in a first place :

since I'm a big fan of the SharePoint & Office 365 PnP Powershell library, I decided to implement my Azure function with Powershell. Having an Azure function creating a SharePoint site/ site collection from Flow was super easy : creating the Azure function in the Portal gives you an Url , just provide the parameters (the information filled in by the user in the SharePoint list) and pass these parameters from Flow to the Azure function via the very convenient out of the box HTTP  action, as illustrated in the next picture:

Also creating the Azure function in Powershell and importing the PnP dll in order to use the PnP Powershell cmdlets was very easy (you have to go to the Platform features menu in Azure, Advanced Tool- Kudu and add the PnP dll to the correct location).

But the problem was that creating the site  and Applying the template sometimes took a while : more than 7 minutes; and my Flow moved to a failed state because of a timeout in the flow execution.

So instead of working synchronously with Flow, I had to work asynchronously (as my teachers in computer science told me 35 years ago in the University 🙂  but I know I know... I digress ...).

So I created a first Azure function (ProvisionSharePointSiteProxy, written in C#) taking my parameters from Flow and storing these parameters on an Azure Queue. This function is invoked synchronously from Flow and is a kind of fire and forget.

Basically the Azure function retrieves the Get parameters sent by the Flow:

You have to reference  Newtonsoft.Json if you want to serialize your parameters into an object (JsonConvert.Serialize(...)) and put it in the queue.

I will explain later the goal of the variable workflowid.

In order to have a queue, the Azure function needs an output queue, and this can easily be created in the "integrate menu" of the function. The output queue (in Azure storage) is called outputqueuesharepointprov and the parameter linked to the queue is called siteInfoQueueItem as described in the next picture

I've created another one (DoSPSiteProvisioning written in Powershell) , automatically triggered when a new object was created in the queue outpuqueuesharepointprov.

Here is the integrate property of this function:

As you an see the outputqueue of ProvisionSharePointSiteProxy function  is used to trigger the DoSPSiteProvisioning that does the real job.

When it is triggered, DoSPSiteProvisioning will:

• fetch the parameters stored in the queue object
• create the new site
• apply the PnP template
• return a message by posting something in a queue that is monitored by the Flow (more on this later)

Here is the Powershell code of my Azure function :

Of course your azure function has to behave as an App (App Permission) so you need to define an App id and App secret (I did it in SharePoint, you have to do it in AzureAD if you want to create Office 365 groups); you have to define the values in the Azure function  (I've created variables in the Application settings) and your Connect-PnPOnline cmdlet should use them.

Also as you can see I store a status information ($operationStatus) in an Azure queue ($outputqueueitem) defined as an output object in the function :

Indeed when the message bubbles-up in the queue the flow will catch it,  but the Flow still needs to make sure he owns the object : indeed several Flows can run in parallel because several users can make a site request, so this must be handled. And that is the reason why anytime I call an Azure function I pass the FlowID along (this is a good practice in the world of workflows, for instance in the .Net Workflow Foundation we had to deal with the correlation id).

To get the workflowID, just intitialize a Flow variable and use the expression Workflow() :

Now how did I called the Azure function from Flow ? I've used the out of the box HTTP action with the Get  method   ("output" is the content of my variable FindWorkflowID as discussed above)

My Flow was not just a fire and forget : my users want to be notified when the site is provisioned and when the template has been applied. That is the reason why my Flow check the status of the queue outputqueueitem. (I know this is a very bad name).

So I've used an Azure Queue - Get Messages action to check the status of my azure queue and I check the queue every 10 seconds in a loop until I get a message containing my workflowId.

Here is a high level overview of this loop :

The condition code is interesting : basically the logic here is: if I find the workflow ID information in a queue message, that means the operation is completed.

I had to rely on the Logic Apps Worflow Definition Language to do it :

So the whole site provisioning part of the flow looks like this:

Part 2.Office 365 groups provisioning

This was very easy : here again you cannot directly provision an Office 365 group from Microsoft Flow, so I decided to implement an Azure function written in Powershell and using the New-PnPUnifiedGroup cmdlet. That internally uses the Microsoft Graph in order to create groups. And to connect to the graph you need to use the PnP Cmdlet Connect-PnPMicrosoftGraph.

To use these cmdlet, you need to to connect to the Microsoft Graph using Application Permissions. Read the following tutorial.

Once your application id and secret id have been defined, you can use them in your Azure function code; here is fragment of my code:

Provisioning an Office 365 group is quite fast, you don't need to work asynchronously as I did before with the SharePoint site provisioning.

I also just discovered that there is an Azure Flow action for creating Office 365 groups without having to write code. 

So happy coding & flowing; let me know what you think of this