Re-use in Microsoft Flow

A wise man once told me “Re-use is good for the soul”. As a junior developer anyone who had been developing for a number years was a wise man, although in this case those words have always driven everything that I do. Whilst I don’t develop as much as I used to, I have recently done some work with Microsoft Flow which easily lent itself to the concept of re-use, being able to use a Flow from multiple other flows in the same way a Function would normally work. I would pass something in, and would get something out. Why would I want to do this? The scenario where I have used this recently is where I have interactions with areas which a normal user doesn’t have access to, therefore the business user will never be able to interact with them. I.e. there’s a secure SharePoint site which I don’t want my business users to have direct access to, however I still have a need for them to post data there. Therefore I have an admin/system account user which has access and created the Flow to interact with the secure site, and then the business user (who doesn’t) calling my Flow. Remember that the Flow actions will always run within the context of the user who created the connection, therefore if the business user calls the admin’s Flow, that part will run as an admin. I hope that makes sense!

The key thing to remember here, is that if you have a Flow which calls out to 2 other Flows, then that will count as 3 executions for that one process. If your Flows are particularly heavily used this approach will start to eat up your 2000 executions per month.

I am going to take the Flow which I recently demonstrated in a community presentation, which is where I am going to provide the ability to request a bearer token from Azure AD in order to authenticate a REST call. This is a Flow which I wouldn’t necessarily want everyone to have control over as it contains Azure AD information, but it’s something which my users (given the right skill level) could call to get the correct token back.

Creating the Flow

In order to trigger this Flow from another, I’m going to use the “Request – When a HTTP request is received” trigger. This will create a webhook which can then be called from another Flow to start it.

As you can see from the screenshot the HTTP POST URL will be generated the first time that you hit save on the Flow, and has a handy copy icon to the right to copy it to your clipboard. You can also supply a JSON schema to specify how you want to receive any parameters. One piece of information that you will always need to provide it, is a return URL.

The final step will be to use a HTTP – HTTP action to call back to the return URL in order to tell the parent Flow that this is complete. Whilst waiting for our “function” to run, the parent will pause in a running state until it receives the go-ahead to continue.

Example you can follow

Scenario: I am going to create a Flow which will take in an employee’s name, look up the manage and then pass that back to the calling Flow. Something nice and simple, and I know this could be achieved in a single action, but this is purely for illustration purposes.

Trigger

To start, create a Flow from a blank template and select or search “When a HTTP request is received”. We want to provide it with a basic JSON schema so that we know what we’re going to receive, and I’m going to use the “Use sample payload to generate schema” link to create my schema for me.

I’ve put in a very basic JSON payload which comprises of the employee_upn and the return_url, and then clicked Done.

That will then generate the schema for me.

Action

Now include an action which is going to return some data that I want to send back to the parent. In this example, all I’m going to do is use the “Get manager (V2)” action to get the manager details based on a users UPN. What I can do, however, is use the “employee_upn” from my trigger, to pass into this action.

Return

Once I’ve completed all of my actions, I need to call back to the parent to return some data and to tell it to continue. To do that, I’m going to need a “HTTP – HTTP” action. The action which will be expected by the parent will be a POST call, on the URL that we passed into our “function” as “return_url” and then with some data passed back as the body. This could be either a single piece of data, or you could pass back a JSON payload.

That is it for our Flow, all we need to do is press Save, exit the Flow and then edit again. This will then generate the HTTP POST URL for our trigger.

Calling Our “Function” Flow

Now that we have completed our reusable Flow, it needs to be called from somewhere else. For this I’ve got a basic list which is called Employees with two fields: Employee (User) and Manager (Text).

I’m going to create a very basic Flow on this which is triggered “When an item is created”, and I’m going then add a “HTTP – HTTP Webhook” action to call the Flow we created earlier.

The subscribe method for this is POST, and the Subscribe – URI is the HTTP POST URL which we generated above. The Body is the JSON payload which I’m going to pass to the webhook.

I will then use the data which I get back to update the Manager field and complete the process, using the Body which I get back from HTTP Webhook to populate the Manager field.

All I need to do now is enter something into the list, and your Flows will happily talk to each other!

Any questions or if you encounter any issues within this, please let me know.

Happy Flowing.