10 Things in Microsoft Flow that isn’t in Azure Logic Apps

Reshared blog, here is the original one.

Sorry about the catchy headline.  I will start by saying I am perfectly ready to see a response post containing 20 things in Azure Logic Apps that we wish are in Microsoft Flow.  The point of this post isn’t about whether one product is better than another product, it is simply to highlight the very-intentional design differences and how as users we have access to both and should make our choice accordingly.

If a comparison must be made, then I think in reality, they are better seen as two siblings – LogicApps is the big sibling with more features, Flow piggybacks LogicApps, but itself has several unique tricks and sometimes, features do move between them.  I love both teams & products.

To best describe Flow to an Azure / Logic Apps person, Flow is Logic Apps + power-user / human workflow-focused workloads, combined with a mobile experience and better in-product integration.  As a result, it caters to a whole different set of scenarios that Logic Apps isn’t focused on.

1. Resource-Owned Flows

Flows can have multiple owners, but it can also have a Resource as a owner.  The best example of this is in SharePoint connector.  A Flow can be ‘owned’ by the List or Library resource – so if we grant a user library owner permissions – that user automatically can see and modify the Flows owned by the resource.  This is awesome because we don’t need to manage two sets of user ownership sets.


2. Run-as user

Several Flow connectors has a concept of the Run-As user, that is, the user can select a resource like a document or a library, and run the Flow as the current user.

LogicApps connectors can only run as the maker.

3. Approvals

Flow implements a simple set of approvals API with both one-must-approve as well as everyone-must-approve, this is setup with Office 365’s Actionable Messages, so tasks can be completed directly from email.  These are also available within the Flow Mobile app.  These approval tasks can be reassigned, and there is a history trail of them in Flow.

In LogicApps – human approvals can be built Outlook’s Send Approval Email.


4. Notifications

Flow can send Mobile Notifications to the accompanying Flow mobile app.


5. Flow Buttons

Flow has digital buttons called “Flow Buttons” these appear as quick triggers on the Flow Mobile App, but is also a really easy way to set up a run-now test trigger.


6. PowerApps Trigger

Flow has a PowerApps trigger (and response) that can send structured JSON data to and from PowerApps.  This makes it much easier to use Flow as server-side middleware to extend PowerApps (which is client-side).

LogicApps has to publish custom connector (which can then be used in Flow and PowerApps).

7. Environments

Flows are created and grouped within Environments – an environment can have unique assets grouped, as well as shared custom connectors, and data leak prevention policies.

Logic Apps are grouped within subscriptions – you either have access to the subscription or you don’t.

8. Selected-Row Trigger

Selected Row is part of the product integration feature of Flow – in which, Flow can be created and ran from within other products as part of an integrated experience.

Two examples we have right now are in SharePoint and (soon) in Excel.
On the roadmap there is also Outlook integration.

This trigger is specific in that in each of these integrated experiences, you can select an existing item (in SharePoint list, in Excel row, or in an email) and start a Flow with that item as the source trigger.  Additionally, Flow can run as the current user (see #2) as part of this integration.


9. Analytics

Flow has several builtin analytics charts out of box with PowerBI.

Logic Apps has Log Analytics integration and users can build their analytics via Insights.

10. Flow Management Connector

In Flow, the Flow Management Connector is a meta-level connector that lets you perform reflection-like actions on the Flows within your current environment.  You can even use Flow to make other Flows.

Somewhere, there is an insane Flow engineer that says wouldn’t it be ultra-meta to deploy Flows with Flow.

Logic App’s Logic Apps connector only lets you list other Logic Apps in the current subscription and run them.  To deploy LogicApps – talk to Azure Management API to deploy ARM templates.

I use this connector quite often to move Flows around:



Think about this.  Flow can read itself.  Flow can call Azure Machine Learning.  Flow can update itself.


11. Business Process Flows

Business Process Flows replace the old Business Process workflow in Dynamic 365,  and is a way to build a “state machine” that triggers and transitions between different business process stages in Dynamics.


This integration with Dynamics platform isn’t available in LogicApps.

(I included an 11th because some may be picky and say well #9 analytics isn’t a special power…)

Example of a powerful Flow feature that made it’s way back to LogicApps

12. Data Gateway

Flow as part of the Business Application Platform had on-premises integration through the Data Gatewayfunctionality first – including calling on-premises SharePoint, SQL, File System and REST endpoints.

This feature was integrated back to LogicApps later as well.


I connect SharePoint to my Minecraft via the Data Gateway with a custom REST API.



Flow, Logic Apps, Azure Integration – these are a multi-headed effort to move expand in multiple directions, each under a specific product offering.

Specifically, Flow’s special powers fall under these categories, some are easy – others not so easy to replicate back in Logic Apps.

  • Flow Mobile app
  • Approvals
  • App-Integrated Flow (SharePoint, Dynamics, Teams, Excel, Outlook)
  • BAP-Integration  (Environments, Data Gateway, PowerApps, PowerBI)

In Dynamics and Office 365, because we get a generous pool of free Flow runs as part of the license, Microsoft Flow can be cheaper.  Flows cost per run.  So it encourages building long-running, multi-step Flows, suitable for human workflows.

But in my own experience – some of the Flows that I call a lot (but doesn’t have too many actions), it’s actually cheaper to switch those to Logic Apps.  I consider these Flows more like Middleware calls – HTTP Request, do a few actions, finish.

Also, in building Flow Studio that works across tenants – I’ve opted to use Logic Apps rather than use the Flow runs of a single Office 365 Tenant.

Different scenarios, for different needs.

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