Skip to content

Why you should use Logic Apps instead of Power Automate

Microsoft offers a few ‘no-code’ automation solutions within Azure/Microsoft 365. If we take a look at the moment popular ones: Logic Apps and Power Automate, it’s often difficult to decide which one you should be using for your automation task.

When we put the two next to each other, you will see that they look mostly alike. The ‘code’ blocks are often the same between Power Automate and Logic Apps. The only main visual difference between the two is the portal were you build them.

Now, the title of the blog post might be somewhat controversial. I am not saying Power Automate doesn’t have it’s use cases and advantages. I have a few running myself to automate some mundane tasks. This blog post will focus on creating flows for the automation of ‘IT administration tasks’. Often, I see organizations using Power Automate, when they should be using Logic Apps. In the conclusion of this blog post, I will share some use cases where I find Power Automate useful and where not.

Introduction

In the past, I have seen a lot of great use cases for Power Automate. It’s a really cool tool to easily automate some tasks. But the goal of this blog post is to make you understand that Power Automate might not be the solutions for all your issues. Often, Logic Apps are the better alternative. Let’s start off first with an introduction of the two products.

Power Automate (formerly known as Flow) is described by Microsoft as follows:

Easily create automated workflows with Microsoft Power Automate, previously Microsoft Flow, to improve productivity with business process automation.

Logic Apps are described as:

Azure Logic Apps is a cloud service that helps you schedule, automate, and orchestrate tasks, business processes, and workflows when you need to integrate apps, data, systems, and services across enterprises or organizations.

So from those definitions, we can see that Power Automate is meant to automate certain workflows for productivity, Logic Apps are meant to automate certain tasks within your organization.

When you want to create a new ‘Flow’ in ‘Power Automate’, you need to navigate to http://flow.microsoft.com. Only users with a Power Automate license can access this portal. A user can create his own flow or use a pre-built template.

Logic Apps are built and maintained through the Azure Portal. In order to create a Logic App, a user needs to have Contributor access to an Azure Subscription.

Next up, let’s look at some advantages of Logic Apps over Flow in a IT administrator context. Let’s use the example where you want to automatically revoke a user sign-in token when he is offboarded.

Logging & Alerting

One of the most important advantages of Logic Apps over Power Automate is logging and alerting IMO. By going to the Diagnostics Settings of a Logic App, you can configure if diagnostic data of a Logic Apps should be sent to:

  • A storage account
  • Log Analytics Workspace
  • Event Hub
Configuring diagnostic settings for a Logic App.

I always send logging information to Log Analytics. With this I can easily troubleshoot Logic Apps and receive alerting when the Logic App fails:

The beauty of Log Analytics Alerts is that I can choose how the alerting should be:

  • Send email to different members
  • Send SMS notifications
  • Send an HTTP trigger (which could create a ticket in your Service Desk tool)
  • Or start an Azure Automation Runbook

Don’t get me wrong, you have the possibility to setup alerting for Power Automate, but they are nowhere as complete as the ones for Logic Apps. For Power Automate, only owners can receive email notifications. But you cannot specify other mailboxes, like a shared support mailbox for example.

RBAC

Because Logic Apps are built and configured in Azure, we have the full RBAC capabilities that we know and love within Azure. This means a couple of things:

  • We can setup a Resource Group with specific permissions for users who need to maintain/build Logic Apps
  • We can integrate with PIM to allow JIT access and require a justification
  • Azure RBAC allows granular control of permissions through a couple of Azure roles:
    • Logic App Contributor
    • Logic App Operator

Power Automate doesn’t support such a rich RBAC possibilities. Flows are always bound to a user. While a Flow can have multiple owners, if the accounts of all the owners are removed, the Flow itself will be removed as well. This can have a big impact if this Flow was business critical.

While Power automate also has two built-in roles (Owners and Run-only), sharing a flow requires a paid Power Automate license and doesn’t provide the rich capabilities that Azure RBAC has.

Connectors

The availability of connectors might be one of the core reasons in your decision process between Logic Apps and Power Automate. Although most the of connectors are shared. Not all connectors that are available within Power Automate are available in Logic Apps and vice versa.

Some connectors, like the Sentinel ones, are only available in Logic Apps. Others are not available in Logic Apps, for example the Teams action ‘Send an adaptive card and wait as a response as a flow bot’. I am using this particular action inside my Intune solution. At the time of creating this solution, this action was not available in Logic Apps, so this is why I chose to build this solution with Power Automate (a couple of weeks after writing that blog post, the action came available in Logic Apps though).

Regions

This is a small and mainly negligible advantage, but because Logic Apps are created inside of the Azure Portal, you can easily choose in which region they should be running when you are creating the app. The location of flows is determined on the location of the environment, which might not be as transparent to the user building the flow.

Cost/licensing

A pretty big difference between the two is cost. While Logic Apps is billed based on consumption, Power Automate is based on the license assigned to a user.

Power Automate has a free and premium tier license plan. Before a user is able to create a flow, he should have a license assigned. While the free tier offers a lot of capabilities, a lot of connectors require a premium license before they can be used. Some basic connectors, like ‘HTTP’ actions require a premium license.

Logic Apps is based on consumption and you will be billed per executed action. While it also has a different pricing for Enterprise connectors, most of the connectors you need are standard connectors. The main disadvantage of the consumption based model is that it can be a bit tricky to estimate how much your Logic App will cost. With flows, you always know the cost of your license before creating them.

Managed Identity

A feature of Logic Apps which I absolutely love is ‘Managed Identity’. By enabling a Logic App to use a Managed Identity, the Logic App itself authenticates to resources instead of using a password or Service Principal. Enabling it is done with a simple click of the button through the portal:

Managed Identity is a great way to retrieve secrets from a Key Vault without the need to create an extra Service Principal for Authentication.

Workflow Settings

Because Azure is a cloud platform, all trigger based Logic Apps you create are available openly on the internet. Because you might want to restrict who has the ability to trigger a certain Logic App, we can configure Workflow Settings.

Within the Workflow Settings, we can setup which IP’s are allowed to trigger the Logic App, but we can also setup that the Logic App can only be triggered by other Logic Apps. This is not possible in Power Automate.

Automating deployment

The last advantage of Logic Apps I want to touch upon is the ability to automate the deployment. With Power Automate we can download the flow as a ZIP and upload that ZIP to the portal to create it. Because Logic Apps are based on Azure, we can use ARM templates to automate the deployment. Through the Logic App, it’s really easy to export your current Logic App to an ARM Template.

This template can be used to deploy your Logic App again. Because of the power of ARM Templates, we can also use Azure DevOps to deploy our Logic Apps automatically.

Code View

Related to ARM Templates, Logic Apps also have a a ‘Code View’. In Code View, we can create the Logic App through code instead of through a GUI. The difference between the Code View and ARM Templates is that ARM Templates also include the settings and configuration of the Logic App (the name, location, region, workflow settings…)

Inside of Visual Studio Code, there is an extension available which enables you to create Logic Apps through the code view. Although the code view is create, I never program from this view. I do use this to change the name of Logic App steps and do bulk changes.

Thanks Angry Virginian for the tip!

Conclusion

The goal of the blog post is not to say you shouldn’t use Power Automate. The opposite, it’s an awesome tool to automate some easy tasks. But it’s important to know that you should try to only use flows when you are trying to automate tasks that only affect you (for example, get a notification when you receive an email from your boss).

If you are automating some general, IT administration tasks, Logic Apps are really the way to go.

This article is entirely based on my opinion. Please reach out on social media or in the comments if you want to discuss this further. It will be awesome to add advantages/disadvantages of Logic Apps in the following weeks based on feedback.

10 thoughts on “Why you should use Logic Apps instead of Power Automate Leave a comment

  1. I would add another one. The ability to work with the underlying json declaration directly in Logic Apps. This comes in pretty handy when trying to do a complex formula or when trying to figure out CI/CD of the workflow.

    Like

  2. Very Good point! Thanks for sharing! Today i use the power automate, because of the volume of executions. But i’ll try logic apps after this post.

    Like

  3. A question …how to use Logic Apps in a SAAS platform to be configuring workflows and business rules for each client using the same master workflow?

    Like

    • You mean where every client much have some different variables? I would recommend deploying the Logic Apps from a central ARM template but use a CI/CD pipeline to customize it through parameters

      Like

  4. For example you have a workflow for accounts payable but it is custom for each client that uses the platform. We don’t want to have multiple accounts payable workflow just a master but then each instance trigger and determines the flow based on parameters passed and the workflow gets executed.

    Secondly how to build custom UI for this in a web app for such a logic app workflow and give admin and business user more capabilities rather then to use Azure Portal?

    Like

    • This really depends on the use case of your product and I don’t have enough information now to make enough decisions.

      Or you need to deploy multiple Logic Apps through CI/CD, or you should use parameters that come from the trigger to define certain actions (through conditions).

      There isn’t a way in Logic Apps to ‘build around’ the Azure Portal. I think Logic Apps might not be the solution for you.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: