Azure functions & Dynamics 365 Finance and Operations

This is another post about solving Dynamics 365 problems using external tools. However I’m starting to think as everything Azure-related as not external at all. In this case I’ll show different scenarios using Azure functions with Dynamics 365.

I wrote this almost three weeks ago and it was intended as a two-part post but after seeing this wonderful blog post about Azure Functions from Fabio Filardi I don’t know what else could I add to it and will probably leave it here. Go check it!

In this post we’ll see what Azure Functions are and how to create one locally and deploy it to Azure.

Azure functions

Azure functions are a serverless compute service that allow us to run code without deploying it to any server (because it’s serverless). It’s a wonderful tool that allows us to write code using .NET, JavaScript or Java, deploy it and run it in seconds.

The functions can be triggered by different events like HTTP, queues, Azure Event Hub and Grid or Service Bus, amongst others. These events will make the function run our code. Let me show you how to quickly create, deploy and run an Azure Function triggered by a POST HTTP call.

Note: Azure Functions can also be created from the Azure portal but using Visual Studio is more powerful (and easier in my my opinion) and will allow us to add the code to Azure DevOps.

Create a new Visual Studio project and select Azure Functions:

Azure Functions in Visual Studio 2019
Azure Functions in Visual Studio 2019

Give it a name and in the triggers select the Http trigger:

Azure Functions triggers
Azure Functions triggers

The solution will open with some sample code. We can run this code locally just by pressing F5:

Azure Functions running locally
Azure Functions running locally

You can see that after running the code I get a local URL I can query to trigger it. We can do this using Postman.

A quick trick!

But what if we needed to test this function from an external service that can’t make an HTTP request to our localhost? Let me show a little trick Juanan showed me: use ngrok.

ngrok will create a tunnel and give you a public URL to your machine to call the function. Download it, unzip it and put ngrok.exe where you want it to run. Then open a command prompt and run this:

Where 7071 should be the same port your function is running on. You’ll get this:

Azure functions & Dynamics 365 Finance and Operations 1
Azure Functions and ngrok, the prefect couple

Now you could call your local function from anywhere using the public URL ngrok has generated. You’ll see all the calls made in the prompt. ngrok is just great! I love it!

Calling the function

First, let’s check the code:

This function accepts GET and POST calls, and if you pass a value with the ‘name’ query parameter in the URL you will get a different response than if you pass nothing.

I’ll call the local URL passing a parameter and see what we get:

Azure functions & Dynamics 365 Finance and Operations 2
Azure functions response

Regarding code, we can do exactly the same things we’d do in any other .NET project for example. We can add all sorts of libraries using nuget, create additional classes and use them in the function, etc. Azure functions can help us solve plenty of problems, and its cost is ridiculous! With the free tier we have 1 million executions included, FREE! The only cost you’d incur into would be the storage account that’s created, but we’re talking about cents/month.

Deploy the function

Azure functions & Dynamics 365 Finance and Operations 3
I’m right-clicking publishing!

To deploy the function we need to create it in Azure portal first. Once it’s done go to Visual Studio and right click, publish the function.

I think this is the only time we can right click, publish without anybody wanting to kill us.

Now select a Consumption plan and “Select existing”:

Azure functions & Dynamics 365 Finance and Operations 4

Create the profile and you’ll be asked to select an Azure subscription and resource group. Select the subscription where you’ve created the Function App and its resource group:

Azure functions publish
Azure functions publish

And finally click the Publish button and your function will be deployed to Azure.

Publish the function!
Publish the function!

Go to the Azure portal, select the function you created before and go to “Functions”:

Azure functions & Dynamics 365 Finance and Operations 5

There you’ll see your function, select it and in the new window click on “Get Function Url”:

Azure functions & Dynamics 365 Finance and Operations 6

Copy the function URL and call it from Postman, or a browser as it also accepts GET requests, and pass it the name parameter too:

Azure functions & Dynamics 365 Finance and Operations 7

It works! We’ve created the Azure Function in a local solution in Visual Studio, tested it locally and finally deployed it to Azure and tested it again, now in the cloud. Aren’t Azure functions cool? Azure Functions can also be secured using AAD, Azure Key Vault, you can monitor them using Application Insights and many other options.

One final remark: when we deploy an Azure Function like we’ve done we cannot edit the code on Azure. We need to do the changes in Visual Studio and deploy it again.

Creating (more) community, or trying

I’m sorry for my English-speaking readers because, maybe, this post will be a bit useless for you as all the content I’ll talk about is in Spanish. But it’s always good to know!

In the last few days I’ve taken part in a community event, the 365 Saturday online, and I’ve also started a podcast. I want to talk a bit about this.

Dynamics Power Spain Online 2020

This has been my fourth participation as a speaker in the last three years and as usual I’ve presented a session with Juanan. This time we’ve talked about using Azure DevOps with Microsoft Dynamics 365 for Finance and Operations.

It’s a topic I write about a lot, but we really think there’s still many people using it in a wrong way or just using the source control part. And that’s bad!

You can watch our session below, and as I said before, it’s only in Spanish and I think there’s no subtitles from Youtube.

There’s more sessions from other Axazure colleagues, again in Spanish:

Many Axazure sessions as you can see. That’s what happens when you promote sharing with the community! You can see the other sessions in 365 Saturday Madrid‘s Youtube channel, some are in English!, the podcast!

Yes! Juan Antonio Tomás and myself have started a podcast in 2020! Why? Each time there’s a new feature for MSDyn365FO, an announcement, a preview, whatever we spend some time talking about it and what could we do with it. So we thought “Why don’t we record this?”. And now we have a podcast which you can listen, even though it’s also in Spanish…

You can listen the first episode here!

Visit us at!

There’s another reason to do this: the Finance and Operations technical community in Spain. It makes me terribly jealous to see the strength of Dynamics 365 CD/Power Platform, .NET, Azure and other technical communities. We don’t have this for AX and that’s what we want!

We would like to have a bigger technical community! This is how we’ll try to encourage other people, sharing what’s coming for FnO. We of course accept collaborations, and if anybody wants to be interviewed or participate we’re totally open!


The idea of community we have is something really simple and I think it’s something we’ve learnt from Antonio and the essence of El Rincón Dynamics. A free and collaborative place where anybody can learn and share and connect. It’s very easy, right?

There might even be people that doesn’t fully understand why do we share what we know freely, instead of keeping everything to us, because that decreases our personal value, we’re sharing our secrets. And this way of thinking is so, so, so much wrong! I might share what I know, but I also have over 10 years’ experience behind me, the mix of these two things is what my value is.

I can only see positive things in sharing.

How do we do branching in Dynamics 365?

I’ve written this post after Mötz Jensen asked to in a long and really interesting Twitter discussion on branching and version control in Dynamics 365 for Finance and Operations. This is Denis Trunin‘s tweet that initiated it all:

Just go and read all the replies, there’s some of the most interesting content I’ve read on Twitter in months.

Branching in MSDyn365FO
Branching in MSDyn365FO

You can also check my MSDyn365FO & Azure DevOps ALM guide too!


When deciding which branching strategy to use, you have to think what will suit your team and follow the KISS principle. Keep your branching strategy as simple as you can! You don’t want to spend most of your day managing the code instead of coding, right? Or trying to fix bad merges…

Also keep in mind that your strategy might not be the same if you’re working on a a customer implementation project or developing an ISV.

Main – Release

This one of the most simple strategies. You start your work on the Main branch, all developers working with it. You keep working only with Main until Go-live.

When the project is going live branch Main and create a Release branch. This new branch will be the one you’ll use to promote code to the production environment. Development of new features and bug fixes is done on the Main branch.

When a development is done, or a bug fixed we will merge the changeset (or changesets) to the Release branch. Yes, we will be doing cherry picking. I know it has bad reputation, but we depend on the customer validating the changes…

On our projects we have at least 2 Tier 2+ environments. We use one for testing and validation to which we deploy the DP created from the Main branch. The other Tier 2+ environment is the one we use for user testing and deploy to production. This second environment will be updated with the DP from the Release branch.

Dev – Main – Release

This is something we’ve been doing lately trying to emulate Git branches for development. We’re using a Dev branch for every developer. We work on our Dev branch, we do all the check-ins we want to do during a development and when it’s done we merge all the changesets or all the branch in a single changeset to Main. Finally we Forward Reverse Integrate Main into our Dev branch to get the changes from other developers.

Yes, it does involve a bit more of merging on the Dev – Main part. But the idea behind this strategy is having a clean list of single changesets in our Main branch for each development. Why? Because… cherry picking…

We will work with Dev and Main until Go Live, when we’ll branch the Main branch and create the Release one. The Tier 2+ environments will be serviced in the same manner as with the Main – Release strategy.

As I said the idea is having a clean list of changesets to move developments from Main to Release and solve all merging conflicts in the Dev branches. Each developer is responsible of his branch and resolving conflicts there.

We’ve been working for some months with this strategy and the results are OK and we’re not having issues regarding too many management. In the future we’ll try with Git, but Juanan will explain that part!

General advice

First of all: train yourself and your team. Remember, using a VCS is mandatory, this is part of your job now. Find somebody that can help even if he/she is outside the AX world. The problems of software development are more or less the same regardless of the language we use.

Don’t keep pending changesets to be merged forever. The amount of merge conflicts that will appear is directly proportional to the time the changeset has been waiting to be merged.

Remember to Keep it simple, stupid (or Keep it stupid simple), KISS. Don’t follow blindly what a guy on the Internet is telling you because he might have different needs in his projects than you.

So this is how we do branching at Axazure. Are there better ways of doing it? Sure! Can this be improved? I have no doubts about it. But this works for us, which is the important thing.