When talking about integrations between Dynamics 365 Business Central and external applications, in lots of real-world projects I see that low-code approaches are one of the preferred way of doing that. Although I’m not a very huge fan of doing everything with low-code technologies, I think that in many situations having an integration workflow created with a low-code approach can satisfy the business requirements.
But what’s the best low-code approach to choose when creating an integration workflow between Dynamics 365 Business Central and an external application?
In the Microsoft’s world, there are mainly two low-code technologies that can be usefult to create integration workflows: Power Automate and Azure Logic Apps.
I wrote some posts in the past about the main differences between the two platforms (the most useful article that I wrote on this topic to compare the two platform from a BC perspective I think it’s here) and I’ve also done a full session last year at Directions EMEA in Milan showing the low-code and full-code serverless workflow platforms in action, but I often see that in the community there are discussions about that.
Too often I think that Business Central partners know that there’s a low code technology for creating serverless workflows and that this technology is called Power Automate. They simply don’t know or ignore that there’s also another technology called Azure Logic Apps.
Azure Logic Apps is a super-set of Power Automate (yes, Power Automate is based on that technology) and it’s absolutely better suited for creating integrations tasks that are not bound to a user (no user-centric tasks).
The way of creating workflows (workflow designer) is absolutely the same on both platforms, so if you’re a Power Automate expert you can start creating a workflow with Logic Apps in minutes:
When you need to create an integration task between Dynamics 365 Business Central and an external application, normally the requirements are (or at least they should be):
- the task needs to run with S2S authentication
- the task needs to be scalable
- the task needs to be secure
- the task should support logging and monitoring
Azure Logic Apps is absolutely a better choice for creating low-code integration tasks than Power Automate if you have the above requirements and I think that my previous article on this topic explains why. But here I want to add something more…
With Power Automate, you sign-in to https://powerautomate.microsoft.com/ and then you can start creating your integration workflow in the portal. The created workflow:
- is linked to the user that creates it
- the owner of the workflow need to share it across the organization (recommended to create at least a second owner)
- it runs in your Power Automate plan (you cannot scale it)
- Monitoring is limited
- You cannot have redundancy of the flow
- You cannot use load balancers
- You cannot create advanced security policies for your flows
- To use the Business Central connector, you need a Power Automate Premium license (fixed cost for users)
With Azure Logic Apps you have the following possibilities:
- The workflow is linked to an Azure Resource Group. You can deploy it in the Azure region you want.
- You can have different deployment models (more on this later)
- You can have redundancy and high availability
- Full advantage of Azure Monitor with Application Insights to provide for a rich monitoring, logging, and alerting to exceptions and performance problems
- You can use load balancers
- You can use Azure API Management for advanced security policies for your flows
- Development tools with Visual Studio Code and local deployment/testing
- You can use full SCM and CI/CD capabilities for your workflows
- You can deploy your workflows as ARM templates or Bicep templates
- More connectors, expecially for enterprise integrations (Logic Apps provides some specific connectors like those used for B2B integrations like EDI, X12, and AS2)
Azure Logic Apps deployment models
Azure Logic Apps has two main deployment model: Consumption and Standard.
Logic Apps (Consumption) is essentially a pay-per-use model. With this model a single Logic App resource can have only one workflow. In the Consumption model, you can then have the following two possibilites:
- Fully-managed environment (Multi-tenant Azure Logic Apps): Logic apps across Azure Active Directory tenants share the same processing (compute), storage, network, and so on. It supports geo-redundancy.
- Integration Service environment (ISE): fully isolated and dedicated environment for all enterprise-scale integrations you need. This model has a predictable pricing with included usage and customer-controlled scaling. Logic apps in the same environment share the same processing (compute), storage, network, and so on. With this model you have also ISE-specific connectors that connect directly to virtual networks.
Logic Apps (Standard) is instead a computed-based offer. You can deploy your workflows to an App Service hosting Plan in Azure (hosting plan with a selected pricing tier) or to a Docker Container or also hosting them by yourself. With this new model, Microsoft has reworked the Logic Apps runtime and re-platformed it on top of the Azure Functions runtime allowing you to self-host your workflows (like the Azure Functions runtime, you can ideally run your workflows anywhere). With this model, a single logic app can have multiple stateful and stateless workflows. The Logic App (Standard) resource type and single-tenant Azure Logic Apps runtime provide another significant improvement by making the more popular managed connectors available as built-in operations (connectors for Azure resources are for example built-in in the runtime).
Scalability considerations
If you have integration workflows that are considered business critical, with Logic Apps you can have zone redundancy and high availability (not possible with Power Automate).
Zone redundancy is currently in preview for Consumption logic apps, which run in multi-tenant Azure Logic Apps and it’s generally available for Standard logic apps, which are powered by Azure Functions extensibility.
You can enable zone redundancy during the Logic App creation:
As said before, with Logic Apps you can support business continuity scenarios, like for example deploying your workflow on different locations (region). To do that, you can define your workflow, then export the ARM template and deploy that template on another location (with parameter files for the connected resources):
You can also support load balancing on active-active instances, where N logic app instances actively handle requests or messages from external systems:
Security considerations
One concern many security professionals have related to cloud workflows is about creating and using of service accounts. Often users of Power Automate create a service account with licensing assigned to it and then use it to own and run Power Automate flows. This service account is often also used on different systems. This presents security holes and threats and in many organizations the use of service accounts is frowned upon due to the security risks. Additionally, many use this practice of service type user account to limit the impact and number of licenses requiring a premium level.
Logic Apps can instead be enabled to run as a managed identity. This allows for the Logic App workflow to be authenticated as itself and not as a service principal, service account, or using any passwords. This allows direct authentication into other services such as Azure’s Key Vault where all the secrets can be stored securely to access partner or other systems adding an additional layer of protection against credential theft and unauthorized access to those systems.
A system assigned managed identity is restricted to one per resource and is tied to the lifecycle of this resource. You can grant permissions to the managed identity by using Azure role-based access control (Azure RBAC). The managed identity is authenticated with Azure AD, so you don’t have to store any credentials in code:
What about costs?
I don’t think that cost is the primary reason of choice for a technology when talking about reliable integrations, but it’s something that in a serverless world should be always evaluated.
Power Automate workflows are essentially free if you do not need premium connectors, but you will run into the quota limits quite soon. With Power Automate, lots of functionalities requires Premium connectors and for this you have two choices:
- per-user plan: starting at $15 per user
- per-flow plan: $100 per flow/month with a minimum of 5 flows (so starting from $500).
Logic Apps instead do not have premium connectors but they have some enterprise connectors. Logic Apps provides two types of pricing plans:
- Standard: you pay for allocated resources (fixed price), no extra price for enterprise connectors.
- Consumption: you pay per action execution (about $0.000025 per action for every execution) and per enterprise connector action execution (about $0.001 each execution).
Saying that, if we need to check for costs you should evaluate what is less costing for you. In lots of scenarios Logic Apps is cheaper. An example that always I use: imagine to have a workflow that every week needs to read data and generate a Word document for the company management (so, 4 executions per month). The Word connector is listed as Premium connector, so if you have Power Automate only for this task you pay 15$ for users, if you’re using Logic Apps you pay only 4 * $0.000025 = 0,00001$.
Conclusions
After this second post about a “comparison” between Power Automate and Azure Logic Apps for creating low-code workflows for integration, I hope that you have a clear overview of both platform and you can evaluate prons and cons.
I’m not here to say that “you need to always use Azure Logic Apps for your integrations” because this is not true. There are workflows scenarios where Power Automate is appropriate, other where using Power Automate is an abuse and an architectural error.
My two cents on this topic: if you’re thinking to solve an integration task with a low-code workflow, ask you some questions:
- Is this workflow user-centric and executed by a user? Power Automate could be the choice.
- Is this workflow a silent process that must be reliable and executed without a user context? Logic Apps is a better choice.
- Do you need an integration workflow that is reliable and scalable and secured? Logic Apps is the choice.
- Do you need mission-critical, high-throughput and low latency workflows? Forgot Power Automate. Logic Apps is a good choice but often a full-code approach here is better (Durable Functions are borned for this, do you remember my last year session at Directions EMEA? 😉 ).
Stefano Demiliani 