15.2 Configuring Business Process Flows
Key Takeaways
- A business process flow is made of stages, and each stage holds up to 30 steps; a single process is limited to 30 stages and can span at most 5 different tables.
- Stages, not steps, drive gating: a user cannot move to the next stage until the required data steps of the current stage are filled in.
- A multi-table BPF keeps one continuous guided process as the record moves between tables — for example Lead to Opportunity to Quote — and creates rows in the next table when the stage advances.
- BPFs run with the privileges of the signed-in user; they guide and gate data entry but do not bypass or enforce table-level security by themselves.
- Choose a BPF for human-guided, stage-based processes; choose a business rule for single-record column logic; choose a Power Automate flow for background automation with no user interaction.
Where business rules handle field-level logic, business process flows (BPFs) handle process logic: they render a guided path of stages across the top of a model-driven app form so every user follows the same steps to a consistent outcome. BPFs belong squarely in the AB-410 domain on building business application logic and automation, and the exam expects you to know their anatomy cold.
Anatomy: Stages, Steps, and Branching
A BPF is a sequence of stages — the chevrons in the process bar, such as Qualify, Develop, Propose, Close. Each stage contains steps, and steps come in two flavors:
- Data steps — a column the user fills in, optionally marked required
- Action steps — a button that runs an on-demand workflow or an instant Power Automate flow from inside the stage
Stage gating is the enforcement mechanism: if a stage's data steps are marked required, the user cannot advance to the next stage until those columns have values. This is guidance with teeth — it does not stop a user from saving the record, but it stops forward movement in the process.
Branching lets the process fork based on a condition. You add a Condition component between stages — for example, if Estimated Revenue is greater than $100,000, route to a Manager Approval stage; otherwise, skip straight to Propose. Branches can merge back into the main flow, and the condition is evaluated when the user tries to advance past it.
Exam trap: Branching conditions read column values from the record, so a condition on a column that is empty when the user advances can route the process down the wrong path. Designs that branch on a value should make that value required in an earlier stage.
Multi-Table Flows and the Designer
A BPF starts on a primary table chosen at creation — that is the table whose records the process bar first appears on. The power move is adding more tables: a stage can span tables, so when the user finishes the last stage on Lead, the flow creates (or links) a row in the next table and the process bar continues there. The classic pattern is Lead > Opportunity > Quote > Order, giving sellers one unbroken guided path even though the work crosses four tables.
You build BPFs in the visual designer: from make.powerapps.com, open a solution, choose New > Automation > Process > Business process flow, pick the primary table, then drag Stage, Data Step, Action Step (workflow/flow), and Condition components onto the canvas and set each one's properties. To span tables, edit a stage and change its table selection. Keep the documented limits in mind — the exam quotes them directly:
| Limit | Maximum |
|---|---|
| Stages per process | 30 |
| Steps per stage | 30 |
| Tables per process | 5 |
| Activated BPFs per table | 10 |
Immersive vs. classic BPFs
At awareness level: a classic (non-immersive) BPF lives as the process bar embedded on a record's form. An immersive BPF is a full-page experience built around the BPF itself — the BPF becomes the record users open, with its own views and form, useful when the process is the work rather than an annotation on it. Know that both exist and that the classic embedded bar is the default you get when you attach a BPF to a table.
User Experience, Security, and Choosing the Right Tool
In a model-driven app the process bar sits at the top of the form. Users select a stage to see its steps in a flyout, fill in data steps, and press Next Stage to advance. Two commands matter for the exam:
- Switch Process — starts the record on a different BPF (or a fresh run of the same one); with up to 10 active BPFs per table, makers order them and control which one applies by default
- Abandon — ends the process instance on that record while leaving the record itself untouched; it can later be reactivated
Each record that runs a BPF gets a process instance row in a hidden backing table, which is how views, charts, and dashboards can report on which stage records are sitting in.
Security
A BPF executes with the privileges of the signed-in user. It can guide and gate data entry, but it never grants access the user's security roles do not already give — a user who cannot write to the Opportunity table cannot complete a stage that spans into it. Conversely, a BPF is not a security enforcement tool: users can still edit columns directly on the form outside the process bar unless business rules or column security restrict them.
BPF vs. business rule vs. flow
| Requirement | Best tool |
|---|---|
| Guide people through a repeatable, stage-based process | Business process flow |
| Validate or manipulate columns on one record | Business rule |
| Background automation, approvals, notifications, integration | Power Automate flow |
Exam scenario pattern: "A sales team must follow the same five qualification steps on every lead, and managers must see which step each lead is on." That is a BPF — guided, stage-based, human-visible. Swap in "when a lead is created, email the owner and create a follow-up task automatically" and the answer becomes a flow. The human-in-the-loop, stage-gated signature is what points to BPF.
A service organization wants agents to follow a guided case-resolution process that starts on the Case table, and when the issue is confirmed as a product defect, continues seamlessly on a custom Defect table without the agent losing the process context. Which BPF capability supports this design?
Which requirement is the clearest signal to choose a business process flow instead of a business rule or a Power Automate flow?