Introduction
These days, you can’t go to a Microsoft conference where the question of “What is the difference between Power Automate and Azure Logic Apps?” isn’t asked. For many people, they think the answer is binary; you need to use one or the other. While people have preferences, and perhaps even biases, it is important not to rule the other technology out, as you are likely missing out on opportunities for your organization.
Personas
When Microsoft has answered the Azure Logic Apps vs Power Automate question in the past, personas generally played a role in deriving an answer.
When it comes to “Power users” or even “Citizen Developers”, Power Automate is generally identified as the tool of choice, in part due to it being the targeted audience for why the tool was created.
For this segment of the audience, the debate is less tense.
Where the debate starts to heat up is in the area of more technical people. Generally, this segment of the user population can be categorized as:
- IT Pros who have strong technical backgrounds, perhaps in Office365 (SharePoint), Dynamics365, PowerApps or other related technologies. For some people within this population, Flow is seen as a tool to solve all problems. However, there may be a tendency to overuse flow, when a logic app can solve the problem, out-of-the-box. For example, looking to modify the code behind the workflow, needing a longer workflow run duration, parsing a CSV or flat file to name a few scenarios.
- Pro Devs live in IDEs like Visual Studio and may come from BizTalk, API Management or Message Oriented Middleware backgrounds. For some people within this population, Flow is perceived as a ‘toy’ that should be used for personal productivity. For example, sending a notification when your boss emails you. Since Azure Logic Apps, can perform most of the functions that Power Automate can, Logic Apps may be over-used when some workflow automation can be performed by others within the organization as an opportunity to scale automation efforts.
In the rest of this blog post, I will try to demystify some of these perceptions about both tools.
Power Automate
While Power Automate, runs on top of Azure Logic Apps, there are some differences that exist. In this section, we will focus on some of the major capabilities and draw attention to some areas where a set of features provide Power Automate with clear differentiation.
Power Automate is technically an integration Software as a Service. Abstractions have been created by the Power Automate team that lowers the barrier of entry for users to start building with it. As a result, “makers” do not require an Azure subscription to build flows, even though their flows do run in Azure as a logic app, underneath the hood.
Makers, typically gain access to Power Automate through Dynamics365 or Office365 entitlement. This provides users with a monthly quota and access to specific features. Standalone plans and additional SKUs are also available for purchase.
The Power Automate product group resides within the Business Applications Group, where it is closely aligned to the roadmaps of its organization’s counterparts: PowerApps, PowerBI, and Dynamics365.
There are two types of flows that makers can create:
- Automated Flows, which are free-form workflows, that resemble Azure Logic Apps.
- Business Process flows (BPFs), which have their roots in Dynamics and represent a very structured business process with different stages.
Both of these types of flows can be constructed from the Power Automate maker portal which is available here. For the purposes of this post, we are going to focus on Automated flows as BPFs do not have a logic apps equivalent.
What Is Power Automate Used For?
Power Automate includes Templates which act as common blueprints that allow makers to get started quickly based upon a pattern that has been previously vetted by Microsoft. These templates are provided by the community, Power Automate Product Group (PG), other PGs like Cloud App Security and 3rd parties, such as those that create their own connectors.
Connectors are a big part of the Power Automate offering, there are over 230 connectors available inflow, both from Microsoft and 3rd parties. While many of these connectors are for SaaS or cloud-based systems, there are some on-premises connectors that can be used in conjunction with the On-premises Data Gateway to access local services. Connectors are divided into two categories, Standard and Premium. Standard connectors are available with entitlements that come from other licensing plans, such as Office365. Premium connectors require additional licenses, either through other vehicles like PowerApps or Dynamics or standalone. There are also some connectors that are exclusive to Power Automate including Approvals, Buttons (physical and virtual) and native mobile notifications.
Approvals are a big part of the Power Automate offering, providing an authenticated experience that includes mobile notifications, through the Power Automate mobile app. Approvals can also be responded to from the Power Automate Approval Center found in the maker portal and from the Outlook email client. Approval history is stored within the Common Data Service (CDS) which is a core data store for PowerApps and Power Automate Solutions.
Power Automate includes several 1st party integrations. These integrations align with where flow users typically like to work: SharePoint Online, OneDrive for Business, Dynamics365, Excel and Microsoft Teams to name a few. In addition, there are some 3rd party integrations with hardware vendors like Flic and Bttn.
Application Lifecycle Management (ALM) is an emerging capability for Power Automate. In November 2018, Microsoft announced the ability to include multiple flows and canvas apps within a single “solution” that can be transferred from one environment to another. As of this writing, there are some gaps in the areas of including custom connectors, parameters, connections and Azure DevOps integration. However, Microsoft has plans to further invest in these areas.
Governance is a very hot topic for flow customers. Microsoft continues to invest in this area as well. Core governance capabilities include Admin Management Connectors, Data Loss Prevention (DLP) policies, Office365 Security and Compliance center, and Admin Analytics.
In addition to all of the features we have mentioned in this post already, there is another feature that impacts both Power Automate and Azure Logic Apps. This feature allows you to export your flow, from the Power Automate maker portal and then import it into Azure as Logic App, through the Azure portal. This feature works in most scenarios, except when Azure Logic Apps doesn’t have the relevant feature including button triggers or approvals.
Turbo360’s Power Automate monitoring tool helps by automating the process of resubmitting the failed runs with zero manual intervention.
Azure Logic Apps
Azure Logic Apps is an Integration Platform as a Service (iPaaS). It is a consumption-based billing service, which requires an Azure Subscription in order to build and run logic apps. More recently, the Logic Apps team has also released, in the preview, a dedicated capacity version called Integration Service Environment (ISE). Azure Logic Apps is part of the Azure Integration Services platform, which includes Azure API Management, Service Bus, and Event Grid.
Azure Logic Apps ISE includes VNet connectivity which allows customers to create direct connections to their on-premises assets without the use of an on-premises data gateway. It also includes the ability to have static outbound IP addresses, custom inbound domain names, isolated storage, scale out/in capabilities with a flat cost billing model.
There are many similarities between the connectors available in Power Automate and Azure Logic Apps.
While Power Automate has buttons and approval connectors, Azure Logic Apps has enterprise connectors like SAP, IBM MQ and B2B support for AS2 and EDIFACT.
There is no concept of standard and premium connectors inside of Logic Apps, but customers who have deployed an ISE can take advantage of a specific sub-set of connectors that will connect to resources on their VNet by using an ISE version of the connector. For organizations that do not go the ISE route, they can still connect to on-premises data sources using the on-premises data gateway.
Since Azure Logic Apps focuses on Enterprise Integration, it includes features that pro-developers expect, including support for Visual Studio and Visual Code is in preview with IntelliSense support. Designer support is currently not available.
Enterprise Integration projects typically require data transformation support. To address these requirements, Azure Logic Apps supports typed XML schemas, flat file encoding/decoding, XML transformations, and JSON transformations. Using these capabilities requires an Integration Account which acts as a storage container for these artifacts. Integration Accounts also enable Trading Partner Management scenarios and allow for the management of partners and agreements.
Since Logic Apps is an Azure service, developers are able to take advantage of Azure Monitoring, which will raise alerts when there are failures that occur within Logic Apps or other Azure services. Alerts can be sent to interested stakeholders via email or a Logic App webhook can be called where a business process can be orchestrated which can include logging tickets in IT Service Management tools like ServiceNow. In addition to the support for Azure Monitoring, Turbo360 can also be as a holistic Azure Logic App monitoring tool and also for other Azure services like Service Bus.
The governance features in Azure differ from those provided in Power Automate, in part due to the personas that are typically involved in building solutions and that getting access to Azure is an ‘opt-in’ activity whereas all Office365 licensed users have maker privileges in the default Power Automate environment. Even with access to the Azure Portal, Azure Identity Access Management (IAM) rules exist which can grant, or prevent, access from creating or accessing logic apps. These access rules can be applied at the individual logic app level, or at the Resource Group level.
Data Loss Prevention (DLP) rules do not exist within Azure Logic Apps, as access to the Azure Portal is seen as a barrier in itself. Analytic capabilities are fulfilled through Log Analytics integration that sends logic app technical diagnostic information to the Log Analytics service, and a solution template exists that includes out-of-box charts. Developers can also send custom events to Log Analytics by providing custom tracked properties within their logic app configuration.
Logic Apps also provide a longer execution duration of 90 days and allow developers to control the run history data retention.
What Is the Difference Between Power Automate and Logic Apps?
Choosing the Right Tool
As we have discovered, there are a lot of shared capabilities between Power Automate and Azure Logic Apps. There are also some subtle differences between the two, but they can play a significant role in determining which is the best tool for the job. Ultimately, tooling should be selected based upon Organization design and the complexity of the requirements.
I firmly believe that we have a requirements-complexity spectrum that plays a major role in deciding which tool is more appropriate. Naturally, this spectrum begins with simpler use cases, that likely involve personal productivity and extend to regulatory and compliance use cases.
If we map our requirements complexity to Power Automate and Azure Logic Apps, we will discover that Power Automate is better suited to deal with requirements that exist on the simpler spectrum, whereas Logic Apps better aligns to dealing with requirements that tend to be more complex in nature.
But, by no means does this undermine either tool! Part of the reason why Power Automate was created was to democratize cloud-based workflow and automation. This represents a huge opportunity and I have highlighted this on the following image where I identify an “Organization’s Scaling Opportunity Zone”. In this area, organizations can take advantage of low code/no code configuration and address a broader range of automation problems than if they were depending solely on centralized pro dev integration team to fulfill these requests.
This messaging doesn’t diminish the value that pro developers/integrators bring to the organization either. With the increasing amount of SaaS applications that are available in the market and the growing need for B2B data exchanges, there is no shortage of work for these people. In many circumstances, data may be sensitive and need to be restricted through Azure IAM rules. In addition, organizations may have regulations such as SOX, which require segregation of duties and strict change management requirements which are better addressed through Azure Logic Apps.
What Is the Difference Between Microsoft Flow and Power Automate?
Power App is an interface design tool, that can be used to create simple Business apps that can perform CRUD operations. Whereas Flow’s objective is to create automated workflows with facility to connect to multiple service and applications that are even in on-prem.
What Is the Difference Between Power Automate and Logic Apps?
Logic apps is an integration service that can be used to integrate your application or any application to any other application quickly and effectively. But power apps can be used to create forms or other interactive UI that can perform basic CRUD operations.
Is Power Automate and Flow the Same Thing?
Microsoft has changed the name Microsoft flow to Power Automate and all the capabilities remains the same. Power Automate is a cloud-based software tool that allows employees to create and automate workflows across multiple applications and services without the need for developer help.
Scaling Your Organization
If you were looking for a definitive answer of which tool is “better”, you won’t find it in this post. Ultimately, both tools provide tremendous benefits within an organization. The true winner is an organization that identifies how to use each tool to deliver value to the organization. At the end of the day, people should consider the desired business outcomes first, then figure out what is the best tool that helps achieve those outcomes, while putting their personal biases aside.
