Business Rules and Business Process Flows
Two pieces of declarative logic that get confused constantly — one validates and sets data, the other guides a person through stages. Plus the scope traps that decide whether either one works at all.
Two things that sound alike and are not
Both live in Dataverse. Both are configured rather than coded. Both are described as “logic”. And they do completely different jobs.
| Business rule | Business process flow | |
|---|---|---|
| Question it answers | Is this data valid, and what should it be? | Where is this record up to, and what happens next? |
| Works on | Columns on a row | Stages a person moves a record through |
| Visible as | Values changing, fields appearing, an error message | A bar of chevrons across the top of the form |
| Contains logic? | Yes — conditions and actions | No conditional business logic beyond controlling entry into stages |
A business rule is a checker: if the shipment is international, make the customs field required. A business process flow is a map: quote, then book, then dispatch, then deliver — and it shows the driver which step they are on.
Business rules: conditions and actions
Every business rule starts with a condition. The rule then takes one or more actions depending on whether that condition is met — you attach actions to the tick branch or the cross branch in the designer.
What a business rule can do
Available at any scope:
- Set column values
- Clear column values
- Set default values
- Validate data and show error messages
Available only at form scope:
- Set column requirement levels
- Show or hide columns
- Enable or disable columns
- Create business recommendations
That split is the single most testable fact about business rules. Anything visual — showing, hiding, enabling, disabling, recommending — only exists on a form, because there is no form on the server.
Scope: the setting that decides where the rule runs
| Scope | Runs on | Consequence |
|---|---|---|
| Entity (table) | Model-driven app forms and the server | Applies even when data changes outside a form — imports, flows, integrations |
| All Forms | Model-driven app forms only | A record created by a flow bypasses it entirely |
| Specific form | Just that one model-driven app form | The narrowest scope — useful when one form has a rule others should not |
The canvas app trap
Business rules defined for a table apply to both canvas and model-driven apps when the table is used in the app — but only if the scope is right.
For a canvas app you must use table scope. A form-scope rule has no effect in a canvas app, because a canvas app has no model-driven form for it to attach to.
And even at table scope, not all actions reach a canvas app. These three do not work there:
- Show or hide columns
- Enable or disable columns
- Business recommendations
If a scenario says a rule works in the model-driven app but not in the canvas app, check the scope first and the action type second.
Column types business rules cannot touch
Business rules work with most column types — text, number, choice, date, lookup, owner, image. Three types are unsupported:
- Choices — the multi-select kind
- File
- Language
If a scenario needs validation on a multi-select choice column, a business rule is not the answer.
Two more business rule limitations
Editing and surface limits
- You must deactivate a business rule before you can modify it. A maker who cannot edit an existing rule has almost always skipped this step.
- Not all business rule actions work on editable grids, editable subgrids do not support business rules at all, and recommendations cannot be created for table-based view pages.
Business process flows: stages and steps
A business process flow defines a set of stages, each containing a group of steps. Each step represents a column where data can be entered. The whole thing renders as a control at the top of the form, and users move forward with the Next Stage button.
Building one
- In Power Apps or Power Automate, open Solutions and pick or create a solution.
- New → Automation → Process → Business process flow.
- Give it a display name and name, choose the table, and select Create.
- Drag Stage components into the designer, naming each and optionally giving it a category — the category appears as a chevron in the process bar.
- Open a stage’s Details and drag Step components in, binding each to a column and marking it Required if it must be completed.
- Drag a Condition component between stages to branch the process.
Branching is a first-class BPF feature
It is a common misconception that a business process flow can only run in a straight line and must hand any decision-making to a cloud flow. Not so. Microsoft’s guidance is explicit: “In simple cases, a linear business process flow is a good option. However, in more complex scenarios, you can enhance a business process flow with branching.”
- Branches are built with If-Else logic.
- A branching condition can combine multiple logical expressions using AND or OR operators.
- Branch selection happens automatically, in real time, based on the rules defined when the process was created — the user is not asked to choose a path.
What a BPF still does not do is general automation. It will not send an email, call a service or write to an unrelated table — that is a cloud flow’s job. Keep those two ideas apart: branching, yes; automation, no.
Where you create them
Since August 2022 you can no longer create or manage business process flows from Power Automate outside the solution explorer. They live in solutions, Power Apps, and Dataverse table views. If someone says “I cannot find where to make a BPF in Power Automate”, that is why.
Stage-gating and the traps inside it
Marking a step Required means the user must supply that column before advancing. This is called stage-gating, and it has sharp edges.
Three behaviours that surprise people
- Required columns block movement even if they are disabled. A disabled, empty, required column still stops stage navigation.
- A required Yes/No step must be Yes. A two-option column set to No counts as empty and blocks navigation. If both answers are legitimate, use a choice column instead of a two-option column.
- Add the column to the form too. If you put a business-required or system-required column into a stage, add it to the form as well, or users are blocked by something they cannot see.
Hard limits worth memorising
| Limit | Value | Why it exists |
|---|---|---|
| Activated processes per table | 10 | Interface usability and performance |
| Stages per process | 30 | The process bar becomes unusable beyond this |
| Tables per multi-table process | 5 | A process may span records across tables |
Concurrent flows and calling workflows
Concurrent business process flows let you associate several processes with the same starting row. Users switch between them and resume each at whatever stage they had reached — useful when a record legitimately participates in two processes, such as a fulfilment and a compliance review.
A BPF can also call an on-demand workflow, configured from the designer. This matters because it is how a BPF gets access to automation it cannot express itself.
Choosing between them — and choosing neither
| Requirement | Use | Reason |
|---|---|---|
| Make a field required when another field has a certain value | Business rule, form scope | Requirement level is a form-scope action |
| Default a value on every new row however it is created | Business rule, table scope | Table scope also runs on the server |
| Guide staff through quote, book, dispatch, deliver | Business process flow | Stages with visible progress |
| Stop a record advancing until a field is filled | Business process flow with a required step | That is exactly what stage-gating is |
| Send an email when a shipment is marked delivered | Cloud flow | BPFs do not automate; business rules do not send |
| Validate a multi-select choice column | Cloud flow or code | Business rules cannot use Choices columns |
| Show a suggestion the user can accept or ignore | Business rule recommendation, form scope | Recommendations are form-scope and model-driven only |
The last row of thinking matters most, and it needs stating precisely. A business process flow does support conditional logic — If-Else branching, with the applicable path selected automatically in real time. What it does not provide is general-purpose automation. When a scenario needs something to happen outside the guided process — a notification sent, a record created elsewhere, an unrelated table updated — the BPF is the wrong tool on its own. Pair it with a cloud flow, or have the BPF invoke a workflow. Hold both halves: branching, yes; automation, no.
Quick check
A maker builds a business rule that hides a column when a condition is met. It works in the model-driven app but has no effect in the canvas app that uses the same table. Why?
A required step in a business process flow is bound to a Yes/No two-option column. Users who answer No cannot advance to the next stage. What is happening?
Kite Freight needs every new shipment row to receive a default service level, whether it is created in the app, imported, or created by a cloud flow. What should be configured?
What to carry forward
- A business rule validates and sets data. A business process flow guides a person through stages.
- Business rule actions split into any scope (set, clear, default, validate) and form scope only (requirement level, show/hide, enable/disable, recommendations).
- Table scope runs on the server; form scopes do not. Canvas apps need table scope.
- Business rules cannot use Choices (multi-select), File, or Language columns, and must be deactivated before editing.
- BPFs = stages containing steps bound to columns, advanced with Next Stage, gated by required steps.
- Limits: 10 activated per table, 30 stages per process, 5 tables per multi-table process.
- BPFs do branch (If-Else, AND/OR, selected automatically in real time) but carry no general-purpose automation — pair them with cloud flows when something must actually happen.
One more piece of declarative logic remains, and it is the one with the most traps of all: the columns that calculate themselves.