Business process flows

What it does

A business process flow (BPF) draws a stage bar across the top of a record and tells the user which fields to complete before they move on. In Sales it's the thing that turns "sales stage" from a text field into something the platform actually understands — pipeline charts, Kanban lanes and most stage-based reporting all read from it.

Key facts

Limits are Dataverse platform limits, not Sales limits: 30 stages per process, 30 steps per stage, 5 unique tables per process, and a maximum of 10 active business process flows per table.
More than one BPF can be active on the same record at once — one instance per process definition. Users switch between them with Switch Process and each instance keeps its own current stage in the background.
Which process a new record gets is decided by security role plus Order Process Flow: the first activated process the user has access to wins. Change the order and new records pick up a different default; existing records keep the process they started on.
By default only System Administrator and System Customizer can see a new BPF. You grant access with Edit Security Roles on the process itself, then assign that role to users. Forget this and sellers see no stage bar at all.
Since v9.0 every BPF is its own Dataverse table. That's where stage history lives, and it's also why the BPF tables have to be added to a solution by hand — they aren't pulled in automatically with the process.
Enabling BPFs on a custom table means ticking Business process flows (fields will be created) on the table. That cannot be undone.
Steps map one-to-one to columns. A step marked required on a Boolean column forces the value to Yes before the stage advances — use a Choice column if "No" is a legitimate answer.
Workflows attached to a stage fire on stage entry or stage exit; a Stage Exit workflow on the final stage never runs, because completing or abandoning the process isn't a stage transition. Use a global workflow with Process Completed or Process Abandoned instead.
BPFs work offline in a Power Apps mobile app only if the process uses a single table. Offline you get Next stage, Previous stage and Set active stage, nothing more.
Renaming a process only changes the name shown on new instances. Existing running instances keep the old display name, and the name's translation is fixed at creation time from the creator's language.

When to use / skip

Every Sales implementation ends up with at least one. The question is not whether to use a BPF but how much to load onto it. The default Opportunity Sales Process is fine as a starting shape — Qualify, Develop, Propose, Close — and most clients want to rename the stages to match their own methodology, which is a five-minute job with a large downstream effect on charts and adoption.

Where people go wrong is treating the BPF as a rules engine. It is a guidance bar with light gating: required steps stop the user pressing Next, and that's about it. If the client wants hard approval gates, revenue thresholds or "sales director must sign off before Propose", that's business rules, Power Automate or a plugin sitting alongside the BPF, not the BPF itself.

Skip a second or third process on the same table unless the sales motions are genuinely different — new business versus renewals, direct versus channel. Two similar processes are worse than one process with branching, because reporting then has to union two BPF tables.

Configuration decisions

One process or several on Opportunity, and if several, what determines the default — process order alone, or security role per sales motion.
Stage names and, separately, stage categories. The category drives colour and grouping in the pipeline chart, so it needs deciding at design time, not retrofitted.
Which steps are required. Every required step is a place a seller gets stuck; be stingy and revisit after a month of real use.
Whether the process spans tables (Lead to Opportunity to Quote to Order) or stays on Opportunity only. That decision constrains offline support and reporting.
Which security roles get the process, and whether sales managers get a second process the sellers can't see.
Whether stage entry/exit automation lives in classic workflows on the BPF table or in cloud flows — pick one and stick to it, mixed estates are painful to debug.

Gotchas

Changing stage names after go-live rewrites what users see but doesn't retro-fix saved records' historical stage data in the way people expect; anything reporting on stage names by string will drift.
Ticking the BPF checkbox on a custom table is a one-way door. If the client later wants that table clean, the columns stay.
The 10-active-processes-per-table limit includes processes nobody uses. Deactivate old ones during cleanup or you'll hit it on a mature org.
Solution export silently ships a process without its BPF table, and the import then fails or lands half-configured in the target. Add both.
A process the user has no security role for simply doesn't appear — no error, no empty bar. Test with a real sales role, never as System Administrator.
Multi-table processes can expose stage information from records the user can't otherwise read. Worth a look if the client is sensitive about visibility between teams.

Consultant notes

Demo the stage bar with a genuinely short process first. Clients who see a 12-stage bar in a demo will ask for 12 stages, and their sellers will hate it.
Push back hard on required steps. The most common cause of "the sellers aren't using the CRM" is a BPF that won't let them save reality.
Agree stage categories with whoever owns the pipeline reporting before you build, because the pipeline chart is downstream of that choice.
Before go-live, check the process order and the role assignment as an actual salesperson account, and check that the BPF table is in the solution.
Tell the client that the stage bar is guidance, not control. If they need control, budget for it separately.

Worth another look if the client adds a second sales motion, or if stage-based reporting starts disagreeing with what sellers see on screen.