Logic App Tips: Build a Git-integration like pipeline for standard SKU logic apps

Intro

So what is this “git integration” like feature that I’m talking about.

If you ever used Azure Data Factory, a similar low-code data movement / data transformation tool, or a Microsoft Fabric, another low-code data & analytics tool, you know that you can connect these tools to Azure DevOps repo or Github repo.

That means every time you make a chance in these tools, these changes are commited back to your repository branch. New pipeline added will become new pipeline JSON file in your repo, new dataset = new json, new config = new json, etc etc.

And this is great. This is great because you use low-code tool, but every change you make can be reviewed by your technical personel, given feedback on, and you retain full version history of your changes. Yes, logic apps have version history, but it’s very poor. But having everything in the repo provides the biggest benefit of them all, which is giving you the ability to create CICD pipelines that will check your code for standard, run things like SonarQube for code quality, and deploy across dev, test, qa, prod environments. This is huge on so many levels.

So, it feels very natural to me that similar low-code tool except in the service integration space should have something similar… and it doesn’t… why? No idea… I think it’s because Microsoft’s direction is pushing Logic Apps into local development paradigm, rather than using Azure Portal. But personally I feel this is a bit flawed in nature. We are losing one of the biggest advantages of low-code for many organizations, which is low entry-point.

Think of it like this. Not every project, or organization has skilled developers/vendors. Sometimes those are internal teams with Power Users, for them using logic apps in the portal is perfect, so setup required (which is problematic in some orgs), no git knowledge required, no overhead.

Let me give you an example. A large data & analytics organization that I work for has a real-estate of 500+ projects. Most projects are build by python engineers directly in Data Factory & Databricks. They need to leverage azure logic apps for simple scenarios like

• Refreshing Power BI Datasets
• Sending notifications to an API after their jobs are done
• Sending Teams messages to users when their report refreshes
• Sending Email messages
• Picking up XLSX/CSV files from Email and processing it
• Grabbing data from SharePoint and putting it into data lake
• and many more…

These are PREFECT, and I really mean perfect scenarios for them to leverage this service and an extension of their data solutions. Now in order to properly develop we will ask them to download Visual Studio Code, Install Logic App Extension, Export their Logic Apps into local repo, or download existing repo, and then develop. That wouldn’t be so bad if it wasn’t just a tip of the iceberg. Very fast these developers will realize that local connectors do not support managed identities… uff. In many organizations this will already be a showstopper because many connectors require high privileged account keys, or generation of service principals, which instead of sitting in the key vault will sit in local json files and developers will share them in teams chat. That’s just a huge governance mess for something that should be a simple email workflow, don’t you think?

History

When I first attended MVP Summit back in 2023, right after it was reinstated due to COVID travel ban, I’ve asked Microsoft Product Team for Azure Logic Apps a simple question “will we get a git integration for azure logic apps”. Back then I was told “yes” but with a asterisk that it was not high on priority.

I’ve asked the same in March 2024, but no news were shared back then.

EDIT (March 2025): Two years later, we have 2025 and the feature is still not here. So when I attended another MVP Summit in March 2025 I had to ask it. The official response was that it’s currently not on roadmap because not many clients ask for it. I guess fair is fair. if you are Microsoft’s client, please feedback them if you need this feature. I truly think it would be game-changer for many areas.

So I’ve implemented a similar feature myself with a simple ADO pipeline.

Development Pattern Change

So what exactly changed?

Consumption SKU Logic Apps

As in my intro section, if you develop in logic app consumption, below diagram represents your workflow

This means that

• Development is happening in Azure Portal
• No setup required from the users
• One Logic App has one workflow - which is a bit bad, but worth noting

Standard SKU Logic Apps

If you move into Logic App Standard workflows you will quickly realize by just reading all guides that while you can develop in Azure Portal, you are almost forced to move into local development with Visual Studio Code

So the main changes are

• Development happens in Visual Studio Code with Azure Account and Logic App Extensions
• Setup required (local tools + git)
• Not all connectors work the same - yea, this one is tricky, I have several blog posts about it, but logic app Consumption connectors are called ‘Azure connectors’ and new Standard SKU connectors are called ‘In-app connectors’
• Works across clouds / on-prem - this is a good thing, because new logic apps are based on Functions SDK you can deploy them in any cloud, or even on-prem!
• Based on functions SDK - Again, because this is functions SDK, you can learn more and control more by reading Functions docs
• One Logic App has many workflows - this one is big, definitely for the better, one logic app holds now many workflows, which is great for deployments and management

Solution

So what is the solution?

Build a pipeline that downloads the current code directly from Logic App Standard and commits it back to your repo (marked red in the diagram). Everything else in the process stays the same, and you can develop in Azure Portal and retain all the benefits of code versioning.

CI Workflow

This pipeline is does the magic.

In order to keep this post shorter I’ve already posted a code for this in February 2024, but I use it to this day and update it frequently whenever I find any changes worth adding.

Git Integration for Azure Logic Apps (Standard) with Azure DevOps

What this pipeline does

1. Is scheduled to run every day at midnight (can be changed to more frequent or triggered adhoc, more on that below)
2. Opens your own repo on “CI/dev” branch
3. Deletes the old code
4. Downloads the current code using PowerShell script (added in the post)
5. Commits the files into ci/dev branch
6. Builds code as a pipeline artifact which can be used to deploy it later across enviromments

What this pipeline doesn’t do

• Doesn’t download ARM templates for API connections, as this is usually managed separately by things like Azure Bicep or Terraform

Triggering the workflow

Technically you can leave this pipeline as is and sync your code one a day/hour, or just run it manually. But there is also a one convulated way to get this done within 5 mins of your code changes.

Azure Monitor + Logic Apps to trigger logic apps

Did you know that when you edit logic app workflow, there is an event fired in Log Analytics which indicates that your workflow changes? Well, there is and you can.

So what does this mean for us

1. Create an alert for log analytics checking for logic app workflow changes row count > 1 based on KQL query (fairly easy to make)
2. Create alert that will call a logic app workflow (it’s easier this way, just make sure it’s a different one from the one you plan to deploy)
3. In the workflow using managed identity use Azure DevOps connector or HTTP connector to start this CI pipeline (just remember to grant this MI permissions to execute workflows)

CD Workflow

If you need CD workflows to deploy logic app artifacts here is my personal one. Feel free to use it. If you find any issues, feel free to collaborate to my repo with fixes!

CICD for Azure Logic Apps (Standard) with Azure DevOps

Next Actions

Here are some recommendations from me on what you can check out next if you want to learn more