Business process flows

What it does

A business process flow puts a stage bar across the top of a model-driven app form and walks users through a defined set of stages and steps. Each step maps to a column, steps can be made required to gate progress, and the whole thing is stored in Dataverse as its own table.

Key facts

Hard limits: 10 activated business process flows per table, 30 stages per process, and a maximum of five tables spanned by a multi-table process.
Business process flows carry no conditional logic or automation of their own. Branching between stages exists, but anything that has to happen comes from business rules, workflows, cloud flows or form scripts.
Required steps are stage-gating. Users can't move on or save until they're filled, and that includes disabled columns that are empty. A required Two Option step must be Yes — No counts as empty, which differs from how business-required columns behave on a form.
Concurrent processes are supported. A row can have up to 10 process instances, one per definition, and users switch between them with state preserved.
Which process loads by default is decided by security role and process order. Once a user switches, that process becomes their default for that row — pinning one for everybody needs a client API script on form load.
Custom tables need the Business process flow checkbox ticked in the table definition, which creates columns and can't be undone.
You can call on-demand workflows from a stage. A workflow set to trigger on Stage Exit of the final stage never runs, because completing or abandoning a process isn't a stage transition. Use a global workflow with a Process Completed or Process Abandoned trigger instead.
Business process flow tables surface in views, charts and dashboards, so stage duration and drop-off are reportable. Custom forms for them aren't supported, and they have to be added to a solution manually or they won't export.

When to use / skip

They still earn their place where a model-driven app is the user's actual workspace and the process is linear, long-running and needs to be visible — sales pipeline, case handling, onboarding. The stage bar tells someone where they are without training, and stage data is genuinely useful reporting. Skip them if there's no model-driven app, if the process is short, or if what the client actually wants is automation. A business process flow that's carrying four workflows and six business rules to make it behave has stopped being the right tool.

Configuration decisions

Whether the process is single-table or spans up to five, and whether the users think in those terms.
Which steps are genuinely required, given required means blocked rather than nagged.
Security role to process mapping, and the process order that decides the default.
Whether concurrent processes are useful here or just a way for users to lose their place.
Where automation attaches — stage entry and exit workflows, or cloud flows triggered by the underlying data changes.

Gotchas

Enabling business process flows on a custom table is irreversible. Decide before you tick it.
The Stage Exit workflow on a final stage silently does nothing, with no warning in the designer. It's a well-worn trap.
Renaming a process doesn't rename existing instances, and the name never translates. If the creator's language was Spanish when an instance was created, it stays Spanish for everyone.
Business process flow tables have to be added to a solution by hand or they're missing from the export, which shows up as a broken deployment in the target environment.
Offline support needs a single-table process in an offline-enabled Power Apps app, and gives you only Next stage, Previous stage and Set Active stage.

Consultant notes

Position them as user guidance with reportable stages, and be straight that the automation lives elsewhere. Clients who expect a workflow engine end up disappointed.
The stage data is often the strongest selling point — cycle time per stage and where deals or cases stall is exactly what management asks for.
Watch for business process flows being used to enforce controls they can't enforce. Stage gating is a UI behaviour; it isn't security.
Check the deployment checklist covers the process tables. It's a recurring ALM defect and an easy one to prevent.

Worth another look if Microsoft moves business process flows onto the modern designer or changes the stage and table limits