Business process flows in Dynamics 365

Business process flows (BPFs) are the staged, top-of-form progress bars you see on opportunities, cases, leads, and other Dynamics 365 model-driven app records. They guide users through a multi-step process with required fields, conditional branching, and stage transitions enforced by the platform. Used well, BPFs encode operational discipline; misused, they create rigid bottlenecks that users route around.

The basic shape. A BPF defines an ordered list of stages. Each stage has a list of steps — fields the user should fill in before moving on. Required steps must be completed; optional ones are surfaced but don't block. Users move from stage to stage with a Next stage button; admins can also configure automatic stage transitions on field changes.

Multi-entity flows. A BPF can span multiple Dataverse tables — for example, a sales process that starts on a Lead, qualifies into an Opportunity, and ends on a Quote. As the process moves between entities, the progress bar stays with the user.

Branching. A BPF can branch based on field values — different stages for different deal sizes, regions, or product types. Branching keeps the process honest without forking the schema.

Multiple flows per entity. A single table can have several BPFs (e.g. small-deal vs enterprise-deal sales processes). Users see the flow that matches the record's qualifying conditions and can switch between active flows.

Security. BPFs are themselves Dataverse tables. Security roles control who can run which flows. A flow's data is stored as a record in a hidden table named for the flow, with relationships to the underlying business records.

Automation. Stage transitions can trigger Power Automate flows for downstream actions — notifying the sales manager when a deal advances, creating tasks, updating finance — without writing code.

Limits.

• BPFs are linear and (with branching) tree-shaped, not arbitrary state machines.
• The same record can't run two BPFs of the same definition at once.
• Excessive BPF complexity (twenty stages, deep branches) slows down adoption.

When not to use a BPF. When the process isn't truly staged — when users genuinely jump around between facets of the same record — a BPF gets in the way. Reach for business rules and forms discipline instead.

A balanced approach. Three to seven well-named stages, three to six steps each, with branching only where the process really diverges. Train users on it. Iterate based on how they actually use it.