If you enjoy this content and would like to take a deeper dive, Kent has published a 5.5 hr course on Udemy and we have a special discount code for Serverless360 readers.
These days, you can’t go to a Microsoft conference where the question of “What is the difference between Microsoft Flow 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.
When Microsoft has answered the Azure Logic Apps vs Microsoft Flow question in the past, personas generally played a role in deriving an answer.
When it comes to “Power users” or even “Citizen Developers”, Microsoft Flow 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 Microsoft Flow 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.
Free download this blog as a PDF document for offline read.
While Microsoft Flow, 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 Microsoft Flow with clear differentiation.
Microsoft Flow is technically an integration Software as a Service. Abstractions have been created by the Microsoft Flow 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 Microsoft Flow 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 Microsoft Flow 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 Microsoft Flow maker portal which is available at https://flow.microsoft.com. For the purposes of this post, we are going to focus on Automated flows as BPFs do not have a logic apps equivalent.
Microsoft Flow 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, Microsoft Flow 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 Microsoft Flow 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 Microsoft Flow including Approvals, Buttons (physical and virtual) and native mobile notifications.
Approvals are a big part of the Microsoft Flow offering, providing an authenticated experience that includes mobile notifications, through the Microsoft Flow mobile app. Approvals can also be responded to from the Microsoft Flow 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 Microsoft Flow Solutions.
Microsoft Flow 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 Microsoft Flow. 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 Microsoft Flow and Azure Logic Apps. This feature allows you to export your flow, from the Microsoft Flow 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.
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 Microsoft Flow and Azure Logic Apps.
While Microsoft Flow 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, Serverless360 can also be used to provide holistic monitoring across Logic Apps and other Azure services like Service Bus.
The governance features in Azure differ from those provided in Microsoft Flow, 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 Microsoft Flow 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.
Choosing the Right Tool
As we have discovered, there are a lot of shared capabilities between Microsoft Flow 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 Microsoft Flow and Azure Logic Apps, we will discover that Microsoft Flow 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 Microsoft Flow 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.
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.