Dataverse Workflows vs. Cloud Flows (FAQ)

Anyone who works in Dataverse eventually stumbles across three similarly named concepts: business process flows, classic workflows, and cloud flows from Power Automate. All three show up in the same menu, all three are called some kind of "process," and all three raise the same question for newcomers: which tool actually automates something, and which one just guides a person through a form?

The answer matters more than it first sounds. Anyone who builds a business process flow where a cloud flow is actually needed ends up with a nice progress indicator but not a single automated action. This FAQ article places the three concepts in context using the official Microsoft documentation and shows you when to use which tool.

What a business process flow really does

A business process flow (called Business Process Flow in Microsoft's own terminology) defines a series of stages and steps that are displayed at the top of the form. Each stage groups a set of steps, and each step corresponds to a column that someone enters data into. According to the Business process flows overview you can mark a step as required, so a user has to fill in the corresponding column before moving on to the next stage. Microsoft calls this "stage-gating."

Important for drawing the line: according to the same documentation, a business process flow offers no conditional business logic or automation, but only an optimized environment for data entry and for controlling the transition between stages. It can span up to five different tables, for example from lead through quote to invoice, and up to ten active business process flows with a maximum of 30 stages each are possible per table. Well-known examples from Dynamics 365 are the "Lead to Opportunity Sales Process" or the "Phone to Case Process." At its core, a business process flow is therefore a guide rail for people, not background automation.

Classic workflows: the phase-out model

Alongside business process flows, Dataverse also has classic background workflows, which technically belong to the same process family but actually automate things. According to the comparison between Power Automate and classic workflow Microsoft explicitly recommends building new automation processes as a cloud flow instead of a classic workflow, and replacing existing classic workflows step by step. One point where classic workflows still have an edge over cloud flows: synchronous, real-time-capable execution, plus access to the pre-image of the data before a change. In the same source, however, Microsoft points out that synchronous workflows are a common cause of performance problems for end users, and recommends moving such logic to asynchronous cloud flows wherever possible.

Cloud flows: where the real automation happens

A cloud flow is the actual automation building block of Power Automate. It starts with a trigger, for example When a row is added, modified, or deleted, and then runs a chain of actions, either within Dataverse or via more than 260 additional connectors to external systems such as SharePoint, Teams, or email. For the Dataverse trigger, according to the documentation on the trigger for row changes you set three key parameters:

• Change type, i.e. whether the flow runs when a row is created, changed, or deleted
• Table name, i.e. which table is monitored
• Scope, i.e. whether only your own rows, rows of the business unit, or rows of the entire organization trigger the flow

You can also define filter columns and an OData filter expression so the flow only runs for genuinely relevant changes, for example only when the first name changes. Using the Run as option, you can also specify whether a Dataverse action runs in the context of the flow owner, the row owner, or the user who triggered the change.

The key differences at a glance

• A business process flow guides a person through stages and steps without automating anything itself.
• A classic workflow automates in the background, but runs synchronously and is considered a phase-out model.
• A cloud flow automates asynchronously, with loops, parallel branches, approvals, schedules, and connections to external systems via connectors.
• According to the documentation, cloud flows run nearly in real time because they use webhooks instead of interval-based polling, with limits of 100,000 actions per five minutes and a maximum throughput of 6 GB in the same period.
• A single flow run ends automatically after 30 days at the latest.

When to use which

If employees need to work through a multi-step process consistently, for example handling a lead through to the opportunity, a business process flow is the right choice. But as soon as something actually needs to happen without anyone clicking a button, such as sending an email, creating a record in another system, or triggering an approval, you need a cloud flow. The two tools aren't mutually exclusive: according to Microsoft documentation, a business process flow can even trigger a workflow, or indirectly a cloud flow, at certain stage transitions, for example via a global workflow step when the process is completed or ended early.

For companies that use their Dataverse environment in production, it's worth taking a deliberate look at how tasks are divided between the two worlds before too many automations get forced into business process flows as a workaround. As part of a Power Automate consulting engagement from NordFlux the existing setup can be reviewed in a targeted way and relieved wherever digital workers can take over automation more reliably than a manually guided process bar. You retain full control over which process step continues to be guided by people and which is handled automatically in the background.

Frequently asked questions

Can a business process flow create data in other systems on its own?

No. According to Microsoft documentation, a business process flow offers no automation or conditional business logic of its own, only a guided data entry interface within Dataverse. For actions in external systems, such as sending an email or creating a record in SharePoint, you need a cloud flow with the appropriate connector.

Should I still build new automations as a classic workflow?

No. Microsoft's official documentation explicitly recommends creating new automation processes as a cloud flow, and reviewing and gradually replacing existing classic workflows. One advantage classic workflows still retain: synchronous real-time execution and access to the pre-image of the data, which cloud flows don't offer in this form.

How quickly does a cloud flow react to a change in Dataverse?

According to the documentation, cloud flows with a Dataverse trigger run nearly in real time because they're notified via webhooks instead of polling at fixed intervals. Within a five-minute window, limits of 100,000 actions per flow and a maximum throughput of 6 GB apply, which can become relevant for very data-intensive automations.

Can a business process flow trigger a cloud flow?

Not directly, but indirectly, yes. A business process flow can trigger a classic workflow at a stage, and that workflow can in turn perform Dataverse actions that are picked up by a cloud flow via the trigger for row changes. The direct route is usually cleaner: the cloud flow reacts immediately to the data change that the business process flow triggers in the form, with no detour through a classic workflow.

How many business process flows can I create per table?

According to the documentation, up to ten active business process flows per table are possible, with a maximum of 30 stages per process and up to five linked tables for a multi-table process. Security roles and a defined order let you control which business process flow is loaded by default for which user group.