Loading tutorials…
Loading tutorials…
Business Process Flows (BPFs) are not the same as cloud flows. BPFs are guided multi-stage processes embedded in Dynamics 365 or Dataverse — think 'wizard for sales pipeline progression.' Different tool, different patterns. This walks the right setup.
Who this is forOperators or admins in Dynamics 365 or Dataverse-heavy organizations who want to standardize multi-stage business processes (sales, onboarding, case resolution). BPFs require Dataverse — they are not for pure cloud-flow users.
What you'll need
Step 1
Cloud flows: event-driven automation. BPFs: guided multi-stage workflows visible IN the record. Users see stages and progress through them.
Cloud flow: runs in the background. Users do not see it. Triggers on events.
Business Process Flow: lives inside a Dataverse/Dynamics record. Users see a horizontal stage bar at the top of the record. Each stage has required fields the user fills before progressing.
BPF use case: standardized sales pipeline (Lead → Qualify → Propose → Negotiate → Close), customer onboarding stages, case resolution stages.
BPFs are NOT a replacement for cloud flows. They complement each other: cloud flow handles background automation, BPF guides users through the manual process.
Step 2
Map the business process: what are the stages? What MUST be true before progressing? What user is responsible per stage?
On paper, list each stage of the process.
For each stage: name it (verb-noun, e.g., "Qualify Lead"), list the required fields/actions before moving to the next stage, identify the role/user responsible.
Example: "Stage 1: Qualify Lead. Required: Budget confirmed, Authority confirmed, Need confirmed, Timeline confirmed (BANT). Owner: SDR."
"Stage 2: Propose. Required: Proposal sent, Pricing approved. Owner: AE."
"Stage 3: Negotiate. Required: Negotiation notes, Contract sent. Owner: AE."
"Stage 4: Close. Required: Contract signed, CRM updated. Owner: AE + Operations."
If any stage is unclear, the BPF will be unclear and users will abandon it.
Step 3
Power Apps maker portal → Solutions → New solution → Add BPF. Pick the target entity (e.g., Lead, Opportunity, Case).
Go to make.powerapps.com.
Switch to the correct environment (top-right).
Open Solutions → New solution (or pick an existing one to add to).
In the solution, click "+ New" → "Automation" → "Process" → "Business process flow."
Pick the target entity (e.g., "Opportunity"). The BPF will appear on every record of this entity.
Name the BPF descriptively.
Step 4
Drag stages from the toolbox. For each stage, add Data Steps (required fields). Configure who can advance the stage.
In the BPF designer, drag a Stage component from the right panel onto the canvas.
Name the stage. Set Category (e.g., Qualify, Develop, Propose, Close).
Inside the stage, add Data Steps. Each Data Step references a field on the entity.
For required steps: mark them as Required. Users cannot progress to the next stage until required fields are filled.
Repeat for each stage. Connect stages in order.
For branching: add multiple stages after a decision point and use conditions to route based on data.
Step 5
BPF must be activated AND assigned to security roles for users to see it. Otherwise users see a blank stage bar.
In the BPF designer, click "Activate" in the top toolbar. Validation runs; fix any errors.
After activation, the BPF still does not appear to users until security roles are assigned.
Go to Solutions → your BPF → "Enabled security roles." Add the roles that should see this BPF (e.g., "Salesperson," "Sales Manager").
Without role assignment, the BPF is invisible. This is the #1 "I activated it but nothing shows" support issue.
Step 6
For automation on stage transitions (e.g., notify manager when deal moves to Negotiate), create a cloud flow triggered by "When a record is created or updated."
BPFs themselves do not do background automation. Pair them with cloud flows.
Create a cloud flow with trigger "When a row is added, modified or deleted" (Dataverse connector).
Set the table to your BPF entity.
Add a condition: "If [BPF stage field] equals [target stage]" — e.g., when stage equals "Negotiate."
Add actions: send Teams notification to sales manager, update related records, log the transition timestamp.
This is how you bridge BPF user guidance with background automation.
Step 7
BPFs only work if users use them. Run training, collect feedback, measure stage progression rates. Adjust as needed.
Run a 30-minute training session for affected users. Show: how to see the BPF, how to fill required fields, how to advance stages.
Build a Power BI dashboard showing: average time per stage, % of records that complete all stages, abandoned stages.
Quarterly review: are users actually using the BPF? If completion rate is < 70%, investigate. Common issues: too many required fields, unclear stage definitions, BPF does not match how work actually happens.
Iterate. BPFs are not "set and forget" — they evolve with the business process.
Common mistakes
Building a BPF without a clear written process spec
What goes wrong: You build the BPF based on what 'feels right.' Users encounter required fields that do not match their actual workflow. They abandon the BPF and bypass it. 40 hours of build time wasted.
How to avoid: Write the process spec on paper FIRST. Validate with the team that will use it. Build the BPF only after sign-off on the spec.
Too many required fields per stage
What goes wrong: Each stage has 15 required fields. Users get blocked constantly. They start entering junk data just to advance. BPF becomes a checkbox compliance exercise, not a value-add.
How to avoid: Each stage should have 2-5 truly required fields. Optional fields are fine — make them visible but not blocking.
Forgot to activate the BPF
What goes wrong: You built the BPF. Tested it. Looks great. Users see no stage bar. You spend 2 hours debugging before realizing you never clicked Activate.
How to avoid: Activate immediately after build. Verify the stage bar appears on test records before declaring it done.
Forgot to assign security roles
What goes wrong: BPF is activated but invisible to users. They report 'BPF not showing.' You investigate, discover no security roles assigned, fix it, but users have already lost trust in the new tool.
How to avoid: Always assign security roles immediately after activation. Test with a non-admin user account.
No training rollout
What goes wrong: You ship the BPF without training. Users do not know how to use it. They click around, get confused, send angry messages to IT. Adoption rate is < 20% after 30 days.
How to avoid: Run a 30-minute training session. Provide a 1-page job aid. Have champions per team who can answer questions.
No adoption measurement
What goes wrong: BPF runs for 6 months. You assume it is working. Quarterly review reveals only 30% of records complete all stages. The other 70% are bypassed via direct field edits. The BPF is theater, not process.
How to avoid: Build a Power BI dashboard on BPF completion rates from day 1. Review monthly. Adjust the BPF when adoption drops.
Recap
Done — what's next
How to set up Power Automate cloud flows
Read the next tutorial
Hand it off
BPFs sit at the intersection of process design + Dataverse expertise + change management. EverestX specialists with Power Platform experience handle all three. Typically $500-1,500 for a first BPF + ongoing $300-700/mo for management across a BPF library.
See specialist rates
BPF: user-facing guided wizard for multi-stage processes. Cloud flow: background event-driven automation. Use them together — BPF guides users, cloud flow automates the background work.
Yes, if you have Dataverse (Power Apps Per User or Per App license). BPFs work on any Dataverse entity, not just Dynamics 365 entities. But you cannot use BPFs against SharePoint lists or external data.
Usually 3-6 stages. Fewer than 3 = the BPF adds little value. More than 6 = users get lost. Map the natural break points in your process and use those as stages.
Yes. Multiple stages can follow a decision point. Configure conditions on the stage transitions to route records (e.g., 'If deal size > $50K, go to Enterprise Review stage; else go to SMB Close').
The active stage is highlighted in the BPF stage bar at the top of the record. Required fields for that stage are clearly marked. Users click 'Next Stage' to advance — Power Platform validates required fields before allowing progression.
Microsoft Power Automate
Power Automate is the right call when your stack lives in Microsoft 365 — but the licensing maze and Premium connector trap catch most newcomers. This walks the right setup path end-to-end, in plain language.
Microsoft Power Automate
Dynamics 365 is the gold-standard automation target — deep schema, rich relationships, complex security. Power Automate is the right tool when it works. This walks the patterns that make it work.
Microsoft Power Automate
Approvals are the #1 use case for Power Automate in most M365 shops. Done right, a 3-day approval becomes a 30-minute click-in-Teams flow. Done wrong, requests sit in limbo for weeks. This walks the right pattern.
Microsoft Power Automate
DIY Power Automate is great until you have 15 flows, Premium licensing confusion, and a SharePoint admin asking why their list keeps getting cluttered. This is the honest framework: when the cost of self-managing exceeds the cost of hiring.
Zapier
One Zap. Five different outcomes depending on the trigger payload. This is where Filter by Zapier and Paths by Zapier earn their keep — and where most DIY setups stack conditions wrong and end up routing nothing.