Business Central OAuth2 for Power Automate 🛂

Generally when writing a post I quickly explain the scenario and get straight to the solution. I need to break that rule here to avoid confusion. As the title suggests this post is about using OAuth2 with Power Automate – applies also to Azure Logic Apps. However, if you have Power Automate flows using the BC connector you are already covered. If you have custom connectors for BC data which use OAuth2 for authentication. You are also covered. So what’s the point of this blog you ask? If you use the HTTP connector in your flows to interact with BC data – you have opened the right blog post 👍🏼. Why does this post matter? Well at the date of writing, 01/03/22, basic authentication for BC web services is being deprecated (https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/deprecated-features-platform). OAuth2 is the replacement. If you can move away from using the HTTP connector then please do. That way you can just natively pickup the correct authentication. I say there are two main reasons you wouldn’t move things to the BC connector. If you have published a codeunit as a web service or you use query objects (which aren’t the API type). Lesser reasons might be that you don’t have development resource or want to avoid cost of refactoring. After all Power BI get to use legacy web services so Power Automate should get to as well right? For PowerApps you need to use a custom connector or the BC connector. You might have Power Automate flows which run from PowerApps. In which case if they use the HTTP connector, same explanation as above. Woah! 😮 that was a wordy intro. If you’re still with me let’s get to the good bit…

I will admit early on I only came across my answer thanks to some brilliant blogs! I highly recommend reviewing Arend Jan’s posts in particular if you have little background on working/setting up OAuth2 for BC. Links:

• https://www.kauffmann.nl/2021/07/06/service-to-service-authentication-in-business-central-18-3-how-to-set-up/
• https://www.kauffmann.nl/2021/07/13/service-to-service-authentication-in-business-central-18-3-how-to-test-rest-client-powershell/

The solution is to have a standalone flow which will retrieve the access token. You will use this flow as a child to you main PA flow. This pattern will work well as you don’t have to alter your existing PA flows using the HTTP connector that much. Let’s get the child flow out the way first as that’s the longer part.

Here is the top level view of the components making up the child flow. We are calling this one “Get Access Token BC”

The trigger for the child flow is receiving a HTTP request. This could be called by a variety of applications, not just a PA flow. I’ve used the GET method here so there is no need to pass a request body 👍

I have 2 variables for my users username and password. This is the account you want to use when calling Azure AD. This is something you could pass from your parent flow if you set a request body in the previous step. I’ve added a note in the image about the “Compose” actio

This is a concatenated text string of the values needed. A sample of the value is below the image gallery. The blogs from Arend Jan explain more about where to get the information from.

This HTTP request then puts things together so we can call the token request URI. The Body here is the output of the compose action from the previous image

Last steps of the child flow is to parse the JSON from the access token HTTP request. Stick the access_token value from there into a final action which sends the result to the initial requester. Like a boomerang 🪃

Here is the text string from the compose action mentioned in the gallery of images. Replace the your_client_ID and your_client_secret parts to form the correct string:

concat('grant_type=',encodeUriComponent('client_credentials'),'&scope=',encodeUriComponent('https://api.businesscentral.dynamics.com/.default'),'&client_id=',encodeUriComponent('your_client_ID'),'&client_secret=',encodeUriComponent('your_client_secret'))

Now we have the child flow up and running let’s plumb it in to a parent flow 🧑‍🔧 I will go through each step with images again.

This is a basic manually triggered flow. It is the two parts in the middle which are the extra steps you will need to add into any flow which meets the criteria I mentioned at the opening of this post

This HTTP request uses the URI from the child flow. Nothing else is needed just that and a method of GET

We know from the explanation of the child flow that we get a simple JSON response back containing just the access token

Last step is to pick a BC web service to call with a HTTP request. I’ve chosen a query object which is not based on an API type. Check the “authentication” section – we use “None”. We actually pass the authorization in the headers with the token response from the parse JSON

Give it a test and things work exactly as we need them to.

Sample of the output from the BC web service 😁

It’s a fairly elegant way to slot in what is needed for the PA flows this might apply to. There are a number of my own previous blog posts which need this solution – like this one: https://joshanglesea.wordpress.com/2020/10/19/business-central-month-end/

To make life easy I’ve created a template of the child flow which you could import into your environment. There are setups that need dealing with before it will work though: https://github.com/JAng13sea/Blogs/tree/master/Template%20Get%20Access%20Token%20PA%20Flow

If you read this because you want to work with web services to get data. You might like this post too: https://joshanglesea.wordpress.com/2023/03/09/business-central-generic-api/