What it does

A business process flow puts a stage-and-step bar across the top of a form, guiding users through a defined sequence and optionally blocking progress until required columns are filled. Each BPF is also a Dataverse table in its own right, so process state is queryable, reportable and automatable.

Key facts

• Structure is stages containing steps; each step maps to a column. Users advance with Next Stage, and can work in the stage flyout or pin it to the side pane. Pinning to the side pane isn't supported on mobile.
• Hard limits: 10 activated BPFs per table, 30 stages per process, 5 tables per multi-table process.
• Marking a step required is "stage-gating". If any stage — including the current one — has empty required columns that aren't hidden, the user can't save the form or move stages. Disabled columns still block if they're empty and required.
• A required step bound to a Two Option (Yes/No) column must be Yes to count as filled. This is different from business-required behaviour on a form, where No is a value.
• Which BPF applies is filtered by the user's security role, then by process order — the first available active process wins. Users can switch with Switch Process, and a switched-out process keeps its state and can be switched back.
• A record can carry multiple concurrent process instances, one per definition, up to 10.
• On form load only one BPF renders. A user's choice of process becomes their default for that record; making a process default for everyone needs a client API script on form load that loads the instance by definition ID.
• All custom tables can be enabled for BPFs, plus a documented list of standard tables. Enabling a custom table means ticking Business process flows (fields will be created) in the table definition — this can't be undone.
• BPF data flows into the form's columns immediately, so business rules and form scripts run on it. Workflows triggered by those columns run when the form is saved. Hide a column on the form and it's hidden in the BPF control too.
• The BPF control offers no direct client-side programmability, but business rules and form scripts applied to the underlying columns take effect in it.
• On-demand workflows can be called from a stage or from Global Workflows. A workflow set to trigger on Stage Exit of the last stage never fires, because completing or abandoning the process isn't a stage transition. Use a global workflow with a Process Completed or Process Abandoned trigger instead.
• BPFs run offline only if the app is offline-enabled and the process uses a single table. The offline commands are Next stage, Previous stage and Set Active stage.
• BPF tables can't have custom forms. A BPF table must be manually added to a solution before export or it won't be included.
• Process names don't update retrospectively — rename a definition and existing instances keep the old name, in the language of whoever created them.

When to use / skip

A BPF is worth it when there's a genuine sequence that people get wrong, and where showing them where they are in it has value — a sales qualification path, a case triage, an onboarding. Skip it when the "process" is really just a status field with four values, because you've then added a component, a table and a set of limits to achieve a dropdown. And be careful with stage-gating: it's the feature clients ask for and the one that generates the most user complaints, because it stops people saving a record they're halfway through.

Configuration decisions

• Whether the sequence is a BPF at all, or a status column plus some business rules.
• Single-table or multi-table. Multi-table is powerful and it costs you offline support and a lot of clarity.
• Which steps are required, which is the whole stage-gating decision and deserves a real conversation with the process owner.
• How many BPFs per table and how they're ordered, since order plus security role decides what each user gets by default.
• Whether a script pins a specific process as the default for everyone, or users are allowed to switch freely.
• Whether workflows hang off stages, and whether any of them are on the last stage — because those need to be global instead.

Gotchas

• Enabling a custom table for BPFs is permanent. There is no undo and no removal of the generated columns.
• Stage-gating blocks the save, not just the stage change. Users interpret this as the app refusing to save their work, and they're not wrong.
• A required Yes/No step where the correct answer is No blocks the user forever. This trips up almost every project that uses Boolean steps.
• BPF tables must be added to the solution by hand or they're missing after import, and the failure shows up as processes behaving oddly rather than as a clear error.
• Renaming a process doesn't rename existing instances, and instance names carry the creator's language permanently. Multilingual clients see mixed-language process names in views.
• Workflow on Stage Exit of the final stage silently does nothing. No warning, no error, just a workflow that never runs.
• A Social Activity stage that offers Create produces an unsaveable form and an "Unexpected error".

Consultant notes

• Get the process owner to walk the stages with real records before you build. BPFs encode process assumptions harder than anything else in the product, and changing them after go-live means live instances mid-flight.
• Push back hard on required steps. Every one you add is a future support ticket. Required should mean "the business genuinely cannot proceed", not "it would be nice to have".
• The BPF tables are the underused half of the feature. Views, charts and dashboards over process data answer "where does work get stuck", which is usually what the client actually wanted.
• Warn about the permanence of enabling a table for BPFs, in writing, before you tick the box.
• If offline matters, keep the process single-table. That constraint should shape the design from day one, not be discovered during mobile testing.

---

Worth revisiting if the per-table process or stage limits change, or if BPF tables ever support custom forms.