Recently I’ve presented at Directions ASIA 2018 with my good friend and MVP Tharanga Chandrasekara, and I’ve been exposed to a “new world” – the Business Solutions world! Coming from and enterprise integration background, I usually tend to gravitate around the enterprise integration tools and lately iPaaS offering, so my initial reaction to integration will always be BizTalk Server / Logic Apps. But Microsoft Flow had evolved to be quite a reasonable option – and I would say probably the first option for integration within the Office 365 / Dynamics 365 consultants, since it gives you almost the same level of functionality that Logic Apps would give – no surprises here, since behind the scenes they are actually the same engine.
So I started to have a number of question preparing for my Directions presentation:
How do I choose between the two technologies? What is the tipping point where Flow doesn’t quite cut it anymore and we should adopt Logic Apps instead? What if I didn’t ask those questions before, and already moved towards Logic Apps, do I need to restart from scratch?
This post is my attempt to answer those questions after some research.
Microsoft Flow 101
Microsoft Flow is a cloud-based service that makes it practical and simple for line-of-business users to build workflows that automate time-consuming business tasks and processes across applications and services. It is aimed to “Citizen Integrators” – users that are not developers, but partner with IT to automate repetitive tasks and business tasks alleviating IT to work on more complex problems.
Microsoft Flow is part of the Business Application Platform – which also includes Power BI and Power Apps – having tight integration with those applications. It also has tight integration with both Office and Dynamics family of products, being available for every user with a valid license for each one of those offers.
Microsoft Flow is a streamlined version of Logic App – so much that I usually joke that Flow is Logic Apps younger brother. When you create a flow, behind the scenes a Logic App – but all the provisioning and management of those logic apps are abstracted from the end user.
From a management perspective, you have a dashboard where you can find the flows you own and verify the status of the executions of that flow.
Creation of flows is heavily based on templates, with more and more templates that match common business scenarios being created every day. Users can also submit their own templates to a common repository increasing, even more, the number of available templates.
Design-wise, implementing a flow is quite similar to implementing Logic Apps – after all, they share the same designer – with a crucial difference: you don’t have access to the code view, like in Logic Apps… I will give you a minute to shout “Nooooooo” or “Yesss!”, depending on what side of this fence you are. 
Another crucial difference comes on the pricing model. While on Logic Apps the pricing is quite granular, down to each step executed – and dependent of the type of step it is (action, standard or enterprise connector) – Microsoft Flow is based on the number of flow runs – each execution of a Microsoft Flow count as one run, as opposed of the Logic Apps where each action executed inside a flow counts toward the final bill. Microsoft Flow also follows a tiered subscription model, where each tier increases the benefit levels from the previous tiers. The tiers are:
Free
The free tier comes with 750 flow executions per month and a minimum recurrence interval of 15 minutes for triggers. It also gives you the ability to create a single custom connector
Office365/Dynamics365
Owners of either an Office365 or Dynamics365 subscription have access to flow with an increased 2000 executions per month and a minimum recurrence interval of 5 minutes for triggers. It also brings the benefit of accessing on-premises resources via on-premises data gateway, on top of the benefits of the Free tier.
Flow Plan 1
This is the first paid tier (since the previous tier is a benefit of the associated subscription). This plan increases the number of executions to 4500 per month and lower the minimum recurrence interval to 3 minutes for triggers. On top of the benefits from the previous tier, you will have access to premium connectors, have the ability to create any number of custom connectors.
Flow Plan 2
The premium plan will raise the number of executions to 15000 per month and lower the minimum recurrence interval to 1 minute for triggers. It also adds the ability to create two enviroments (e.g. development and production) and assign users to each environment, as well as the ability to implement policies to restrict the usage of connectors and flows per environment. Within Flow Plan 2 you can also access execution insights of each Microsoft Flow in analytics dashboard.
Subscription Details
One important thing to understand around the number of executions is although each subscription has a cap on the maximum number of executions, those number are aggregated at the organization level. For example, if you have 5 Office365 subscriptions on your organization, that means that the organization can execute 10000 flows a month, instead of each user only being able to execute 2000 instances. This is valid for all plans.
Another important thing to notice is that the Basic and Premium plans are add-ons to the Office365 or Dynamics365 plan that an organization has. So for example, if you have 5 Dynamics365 subscriptions on your organization, and want to leverage from features available on Flow Plan 2 – you will be paying 5 x NZ$ 23.00 (at the current price range). Which seems fair, since the benefits are rounded at the organization level. Notice that this is only required if your organization requires the features available on Flow Plan 1 or Plan 2.
How is Logic Apps different from Microsoft Flow
I will assume that you know what Logic Apps are at this stage, but if not, here is “something I prepared earlier“.
Although Logic Apps and Microsoft Flow use the same engine behind the scenes, and share the same graphical designer, this is where the similarities stop in my opinion. Each one of them have different targets in mind both from an audience and type of solution. While Microsoft Flow targets the Citizen Integrator, Logic Apps targets the Integration Developer which will be usually involved in more complex integration solutions and development practices, being part of a larger solution. Those solutions will also require richer management and monitoring controls would benefit from a more granular and scalable payment format and could need a tighter security mechanism. From my point of view, this is how Logic Apps differs from Microsoft Flow:
Price Granularity
Logic Apps follow the pay-per-usage model of most of the Azure components. And it is REALLY granular. Instead of paying per logic app instance execution, you will pay for each action executed inside a logic app, and only for those actions. That means that simple logic apps workflows can be very cheap to execute, while more complex logic apps can be more expensive. It also means that since you don’t have an execution cap as in Microsoft Flow, you can break down your Logic Apps into smaller reusable components.
Development Experience
Logic Apps supports both a browser-based development experience – using the Logic Apps designer within the Azure Portal – and an IDE based development experience, using Visual Studio. Users can import Logic Apps developed in the portal into Visual Studio and include it into an Azure Resource Group project, opening the possibilities of using source control to keep track of logic apps changes and build and deployment automation both in isolation or within the context of a larger solution. Developers are not restricted to a single environment but can deploy the Logic Apps in any environment that they have permission to.
Notice that subscriptions that have access to Flow Plan 2 have access to two environments, so they can still create a development and a production environment, but the differential of Logic Apps is the ability to source control and create a single ARM template to deploy Logic Apps and other parts of a larger solution that is based on Azure resources.
Full Control over code
Logic Apps design tool allow users to switch between visual design and a code view, based on a workflow definition language that is specific to Logic Apps. This allows developers to have more control over the code being implemented, including more control over build/deployment automation, using environment variables.
Another aspect of control over code and configuration is related to polling intervals. Logic Apps, as a by-product of the pay-per-usage, don’t impose any limits on the polling intervals for triggers that use this method – like Dynamics NAV. But it is important to understand that each polling execution counts as an action or connector execution, even if there is no data to trigger the execution of a logic app. So be careful when designing those triggers, to have the correct balance between being the ability to trigger logic apps executions as close to the triggering event as possible and the cost of operation.
Rich Management/Monitoring Experience
Being created with enterprise clients in mind, Logic Apps have more options for management and monitoring. Using the Azure Portal as its backbone, Logic Apps management allow sys admins and operators to see at a glance the latest executions of an instance of a logic app, providing search capabilities to find executions by date range and status. It also allows a previous execution to be resubmitted directly from the portal and allow the creation of alerts based on a number of monitoring metrics, like the percentage of failed executions in a period of time.
Logic Apps inherits Azure role-based access control (RBAC) to provide granular access to aspects of management (like resubmission, editing, execution details viewing). Those can be inherited from the Resource Group that hosts the logic app or be set up directly to an instance of a logic apps.
Another aspect that differentiates the Logic Apps is the ability to aggregate monitoring data from a group of logic apps into Azure Operation Management Suite (OMS) – by turning on Log Analytics, using OMS as the repository, and deploying the Logic Apps Management solution. Microsoft Docs provide a step by step guide to implement this setup here.
Microsoft Flow vs Logic Apps: Which one to choose
Using Microsoft Flow
The scenarios below are classic scenarios that would fit Microsoft Flow:
- I don’t have access to an Azure subscription but still, need to implement workflows to improve my own or the organization integration
- I need to implement personal workflows that improve my own productivity, with or without access to a Dynamics or Office 365 account.
- I need to implement Power Apps applications – Power Apps and Microsoft Flow have a tight integration and work quite well together.
-
I am working on an organization that have Dynamics or Office 365 active subscription and:
- Have a need to create workflows to integrate first-party applications Office and Dynamic 365 applications, including single button applications, approval applications.
- Have a non-developer background but need to implement organizational workflows to support my activities.
- My workflows are not part of an EAI solution needs to be implemented, deployed and versioned as a single ARM template.
- My management/monitoring requirements are simpler, not requiring data aggregation.
Using Logic Apps
The scenarios below are cases where Logic Apps would be a better fit:
- I am implementing integration workflows that are part of larger solutions which involves multiple Azure resources, needs to be source controlled, versioned and deployed via ARM templates as a single unit within Azure.
- I require more control over my workflow development, either because some of my actions are more complex, which benefit from writing them directly in code, or because I would need parametrization across multiple environments
- I need close to real-time (under a minute) logic app triggering on a connector that uses polling as the firing mechanism.
- I need an aggregated view of my logic apps execution from a monitoring point of view.
- I need more control over access to my workflows across different roles in my organization.
- I am implementing B2B applications that need to leverage from EDI, XML validation and transformations.
Migration Path
What happens if you started down the path of Microsoft Flow and all of a sudden the requirements became so complex or you hit the limits of Flow? This is where the benefits of having both applications running under the same engine start to show – you can “evolve” any of your Microsoft Flows into a Logic App. Kent Weare – Microsoft Flow PM – provided a handy video tutorial on how to do this migration in one of the Middleware Friday episodes.
In Summary…
Microsoft Flow and Logic Apps belongs to the same family of products – I usually joke that Microsoft Flow is the younger brother of Logic Apps (or, since I am surrounded by Pokemon toys and games at home, Logic Apps is the evolved form of Microsoft Flow).
Non-developers, especially those without an Azure subscription or with access to a Dynamics of Office 365 subscription, will benefit from having a workflow engine to implement solutions that can improve productivity both on personal and organization levels at no extra cost.
Both are quite powerful having different sweet spots and audiences. There are cases where Logic Apps might be better suited than Microsoft Flow, but in most of the cases, it is more a business decision about integration strategy. Since they share the same underlying engine Microsoft Flow can be easily transformed into a Logic App, which makes migration/consolidation in cases of change in strategy simpler.
