Business Process Flows (BPFs) transform inconsistent, documentation-dependent workflows into structured, in-form guidance that enforces data quality at every stage. Learn how to design, build, and deploy BPFs that actually guide users — including branching logic, stage-gating, and security configuration.
Imagine your sales team is onboarding a new client. There are seven distinct steps: initial qualification, needs assessment, proposal review, legal sign-off, contract execution, account setup, and handoff to customer success. Without structure, some reps skip legal review. Others forget to complete the needs assessment before sending a proposal. The process exists in a training document that nobody reads twice, and the result is inconsistency, errors, and frustrated customers.
This is exactly the problem that Business Process Flows (BPFs) solve in Power Apps model-driven apps. A BPF is a guided, visual workflow that appears at the top of a Dataverse form and walks users through a defined sequence of stages — each stage containing specific steps (fields to fill out, decisions to make, or actions to take) before moving forward. It doesn't hide the rest of the form or lock users out of functionality. Instead, it provides a persistent visual guide that makes the right path obvious and enforces data quality along the way.
By the end of this lesson, you'll know how to design, build, configure, and deploy a Business Process Flow in a model-driven app. You'll understand how BPFs relate to your Dataverse tables, how to enforce stage gates with required fields, how to handle branching scenarios, and how to manage BPF security so the right roles see the right process.
What you'll learn:
Before diving in, you should be comfortable with the basics of Dataverse and model-driven apps. Specifically, you'll get the most out of this lesson if you've read Dataverse Fundamentals: Tables, Columns, and Rows Explained for Power Apps Makers and Building Your First Model-Driven App: Site Map, Tables, Forms, and Views. If you've also read about Business Rules in Dataverse: Validation and Field Logic Without Code, you'll already understand how Dataverse enforces logic declaratively — BPFs extend that philosophy to multi-stage processes.
Let's clear up a common confusion right away: a Business Process Flow is not a Power Automate flow. Power Automate flows run in the background, triggered by events, and execute automated logic (sending emails, updating records, calling APIs). BPFs are interactive, user-facing guides that live on a form and require human action to advance.
Think of a BPF like the progress bar at the top of a tax filing website. It shows you where you are (Personal Info → Income → Deductions → Review → Submit), it highlights the current step, and it won't let you jump to "Submit" until you've actually filled in your income. The experience is synchronous — you're in it, making decisions, moving forward deliberately.
Technically, here's what happens under the hood: when a BPF is activated and associated with a Dataverse table, Power Platform creates a hidden BPF table in Dataverse to track the process state for each record. Every row in your main table (say, an Opportunity) gets a corresponding row in the BPF table that records which stage it's currently in, when it entered that stage, and the history of stage transitions. This is important to understand because it means BPF data is queryable — you can build views filtered by stage, or use Power Automate to trigger when a record advances past a certain stage.
Key insight
Because each active Business Process Flow creates its own Dataverse table, you can surface BPF stage data in views, charts, and even dashboards. A manager can see a pipeline view filtered to "Proposal Review" without anyone manually tagging records. The process tracking is structural, not just visual.
A BPF is made up of three hierarchical pieces:
Resist the temptation to open the BPF editor and start dragging things around immediately. The most effective BPFs are designed on paper (or a whiteboard) first. You need to answer three questions before touching the tool:
1. What are the stages? Stages should represent meaningful business milestones — moments where someone in the organization would naturally ask "has this record reached X yet?" If you can't articulate what a stage means in a sentence, it's probably not a real stage; it might be a step within a larger stage instead.
2. What data do you need to capture at each stage? For each stage, list the fields that absolutely must be populated before the record can move forward. These become required steps. Also list fields that are relevant but not mandatory — those can be optional steps or simply visible on the form.
3. Does the process ever branch? Some processes are linear: every record goes through the same stages in the same order. Others branch: a deal over $500,000 requires executive approval (a stage that smaller deals skip), or a support ticket classified as a bug routes through engineering review while a feature request routes through product. If your process branches, you'll need to map out those diverging paths.
For our lesson, we'll use a concrete example: a Contract Management process attached to a Contract table. The stages are:
This is a clean, linear process — every contract goes through the same five stages. We'll introduce a condition-based branch later to handle contracts above a $1M threshold.
Tip
Keep your stage count between 3 and 7. Fewer than 3 and a BPF adds overhead without meaningful guidance. More than 7 and users experience "stage fatigue" — the progress bar becomes something to dismiss rather than something to follow.
You build BPFs in the Power Apps maker portal (make.powerapps.com). The editor is part of the solution experience, which means your BPF lives in a solution and can be exported, versioned, and deployed across environments.
Here's how to get started:
Navigate to the BPF editor: Open make.powerapps.com and select your environment from the top-right environment picker. Click "Solutions" in the left navigation, open your solution, and click "New" → "Automation" → "Process" → "Business process flow."
Configure the BPF:
A dialog appears asking for:
Click "Create." The BPF designer opens.
The designer canvas:
The canvas shows a horizontal strip — this is your BPF. By default, it contains one stage ("New Stage") and a finish node. Everything you build goes between these.
Adding and naming a stage:
Click the default "New Stage" node to select it. On the right panel, you'll see properties. Change the Display Name to "Initiation." You'll also notice a "Category" dropdown — this maps to a standard business category (Qualify, Develop, Propose, Close, etc.) and is primarily cosmetic, but it does drive the color of the stage chip in the UI. For a contract process, you can leave this as "Qualify" for the first stage or set it to a custom value.
Adding steps to a stage:
With your "Initiation" stage selected, click "Add" → "Add Step" in the properties panel. Each step maps to a specific column on your Dataverse table. In the step properties:
For the Initiation stage, add these steps:
Warning
Required steps in a BPF only enforce that the field has a value when the user clicks "Next Stage." They do not prevent saving the record with the field blank, and they do not replace proper business rules or column-level requirements. If a field is truly mandatory for the record to be valid (not just mandatory at this stage), mark it required on the Dataverse column itself.
Adding more stages:
Click the "+" button to the right of your Initiation stage to add another stage. Name it "Legal Review" and add steps:
Repeat this process for the remaining three stages (Approvals, Execution, Active), mapping each step to the appropriate column on your Contract table. As you build, the designer renders a left-to-right strip of stage nodes connected by arrows, giving you a visual representation of the full process.
Note
Steps in a BPF can map to columns on the primary table only — unless you use a multi-table BPF (discussed shortly). If you need to capture data in a related table (like individual approver records in a child Approvals table), those columns aren't directly available as BPF steps. In that case, users interact with a subgrid on the form to add the related records, while the BPF step can be a non-field step that just serves as a reminder or checklist item with a description.
The most powerful (and often underused) feature of BPFs is the ability to span multiple Dataverse tables. A multi-table BPF means that as a record advances through stages, the active entity (the record the user is working with) can switch from one table to another.
This sounds abstract, so let's make it concrete. Imagine a Sales process:
The BPF handles this handoff cleanly. When you add a stage in the designer, you can change the table for that stage using the "Entity" dropdown. The BPF engine manages the cross-table relationship behind the scenes. Users experience a seamless transition — the form shifts from the Lead form to the Opportunity form when they cross that stage boundary.
For our contract example, we'll keep a single-table flow (everything on the Contract table), but understanding multi-table flows is essential for processes like lead-to-opportunity qualification, which is actually the built-in "Lead to Opportunity Sales Process" BPF that ships with Dynamics 365 Sales.
Real processes rarely flow in a straight line. Our contract process needs a branch: contracts with an Estimated Value over $1,000,000 require an additional "Executive Approval" stage before Execution. Contracts below that threshold skip straight from Approvals to Execution.
Adding a condition:
In the BPF designer, between the "Approvals" stage and the "Execution" stage, click "Add" → "Add Condition." A diamond-shaped condition node appears on the canvas.
Click the condition node to open its properties. You'll build a rule using Dataverse columns:
This creates two branches — one for records where the condition is true (high-value contracts) and one where it's false.
Configuring the branches:
On the "true" branch (condition met), add an "Executive Approval" stage with steps:
Then connect the Executive Approval stage to the Execution stage to rejoin the single path.
On the "false" branch (condition not met), connect directly from the condition node to the Execution stage.
Key insight
BPF branching doesn't create parallel paths — it creates diverging then re-converging paths. At any moment, a record follows exactly one branch. If the data changes (say, someone revises Estimated Value from $1.2M to $800K), the branch evaluation doesn't automatically re-route the record. Once a record enters a branch, it stays on that path unless you manually move it. Design your branching conditions around data that's stable by the time the branch is evaluated.
The whole point of a BPF is to enforce process discipline. Stage-gating is the mechanism that prevents users from skipping ahead. When a step is marked Required, the "Next Stage" button stays grayed out until that field has a value.
But what about more complex conditions? What if you want to prevent advancing from "Legal Review" to "Approvals" unless the Review Outcome is set to "Approved" or "Approved with Changes" — not "Rejected"?
This is where BPF steps combine with business rules and Power Automate. The BPF itself can only enforce "field has a value." For logic-based gates ("field must equal X"), you have two options:
Option 1: Business Rule on the table Create a business rule that fires when the Review Outcome is "Rejected" and sets a new column (e.g., "Block Advancement" checkbox) to true. Then in the BPF, make "Block Advancement = false" a required condition by... well, this gets complicated quickly because BPFs don't directly read boolean locks.
Option 2: Power Automate + Error Notifications Let the user click "Next Stage." Use a Power Automate flow triggered by the stage change to validate the condition, and if it fails, send an in-app notification and revert the stage back. This is more sophisticated but gives you full control over validation logic.
For most real-world scenarios, the combination of BPF required steps for data presence + a business rule for field-level logic covers 90% of enforcement needs. The key is to design your process so that the BPF-enforced steps naturally prove the work was done — if Legal Review Outcome is populated, the reviewer clearly made a decision.
A BPF isn't available to users until you activate it. In the designer, click "Activate" in the top command bar. Once activated, the BPF is live in your environment and will appear on new records of the associated table.
Deactivating vs. modifying: You cannot edit an active BPF — you must deactivate it first, make changes, then reactivate. During the deactivation window, existing records retain their current stage data; they just won't see the progress bar until you reactivate. Plan BPF modifications carefully in production environments.
Setting order for multiple BPFs: A single table can have multiple active BPFs — for example, a Contract table might have both a "Standard Contract Process" and an "Emergency Contract Process." When multiple BPFs exist for a table, users are prompted to choose one when they create a new record. You can control which BPF appears first (the default) by setting the Order value in the BPF properties. The BPF with the lowest order number is the default.
Security roles: BPF security is managed separately from table security. By default, when you activate a BPF, only System Administrators and System Customizers can use it. To make it available to your users, you need to assign the BPF to the appropriate security roles.
In the BPF designer, click "Edit Security Roles" (or go to the BPF's Properties). A list of security roles appears. Check the boxes next to the roles that should be able to initiate and interact with this BPF. This is separate from whether those roles can read the Contract table itself — you need both the table access (configured in the security role) and BPF access (configured here) for the experience to work correctly.
Warning
Don't skip security role assignment in production. A common mistake is activating a BPF and assuming it's visible to everyone. If your users aren't seeing the BPF bar on their records, missing security role assignment is the first thing to check.
Once activated and secured, you need to make sure your model-driven app includes the BPF. Open your app in the app designer (make.powerapps.com → Apps → select your app → Edit).
In the modern app designer, the BPF is included automatically when it's active and the table is in your app. However, if you're using the classic app designer, you'll see a "Business Process Flows" node in the left panel — click it and verify your BPF is checked. If it's not checked, users won't see it even if the BPF is active in the environment.
Also ensure the form your table uses is set up to support the BPF. Open the main form for your Contract table in the form designer. The BPF bar renders at the very top of the form, above all tabs and sections — you don't need to add any controls. But if you've heavily customized your form with locked headers or custom headers, visually verify the BPF bar renders correctly when you preview the form.
For guidance on form design fundamentals, see Designing Model-Driven Forms: Sections, Tabs, Subgrids, and Quick View Forms.
Let's build the Contract Lifecycle BPF described in this lesson. You'll need a Dataverse environment with a Contract table (or create a new custom table called "Contract" if one doesn't exist). If you need to build the table first, the concepts from Designing a Dataverse Data Model: Relationships, Lookups, and Choice Columns will guide you through creating the right columns.
Step 1: Prepare your Contract table
Ensure your Contract table has these columns:
Step 2: Create the BPF
Navigate to your solution → New → Automation → Process → Business Process Flow. Name it "Contract Lifecycle," select the Contract table, and click Create.
Step 3: Build five stages
Add each stage (Initiation, Legal Review, Approvals, Execution, Active) with the steps mapped to the appropriate columns, marking required steps as specified in the lesson.
Step 4: Add the condition branch
Between Approvals and Execution, add a condition on Estimated Value > 1,000,000. On the true branch, add the Executive Approval stage with its three steps.
Step 5: Activate and assign roles
Click Activate. Then click Edit Security Roles and assign the BPF to at least one non-admin role in your environment (or the Basic User role if you're testing in a dev environment).
Step 6: Test the experience
Open your model-driven app (or add the Contract table to your app if it isn't there). Create a new Contract record. You should see the BPF bar at the top with "Initiation" highlighted. Fill in the required fields and click "Next Stage." Verify that leaving a required field empty prevents advancement. Test with an Estimated Value above $1M to verify the branch routes through Executive Approval.
"My users don't see the BPF bar." Check three things in order: (1) Is the BPF activated? (2) Are the users' security roles assigned to the BPF? (3) Is the BPF included in the app? All three must be true simultaneously.
"The BPF appears on old records but not new ones." If you activated the BPF after records were already created, those existing records won't automatically get the BPF attached. You can write a Power Automate flow or use bulk data operations to associate existing records with the BPF, but new records will pick it up automatically.
"Required steps aren't blocking advancement." Make sure you toggled "Required" on in the BPF step properties, not just at the column level. BPF required steps are configured in the BPF designer, not in the table schema.
"I can't edit the BPF." You must deactivate the BPF first. Go to Solutions → find your BPF → click the ellipsis → Deactivate. Then you can reopen the designer and make changes.
"The condition branch isn't routing correctly." Verify the condition rule uses the exact column name (not the display label) and that the data type of the column matches the operator. Currency comparisons with "is greater than" are reliable, but text comparisons can be case-sensitive in some environments. Also confirm that the field value is populated before the condition is evaluated — if Estimated Value is blank when the user clicks Next Stage, the condition evaluates as false.
"Multiple BPFs are showing for one table and confusing users." This is by design but manageable. Use the Order property to ensure the correct BPF is the default. If only one process applies to your users, consider making the other BPFs unavailable by removing them from those users' security roles.
Tip
When testing BPFs, use a dedicated test user account rather than your admin account. Admin accounts bypass many BPF security restrictions, which can give you a false sense that the configuration is working correctly for regular users.
Business Process Flows are one of the most practical tools in the model-driven app maker's toolkit. They transform chaotic, documentation-dependent processes into structured, self-documenting workflows — right inside the forms where users are already working. You've learned how to design stages that reflect real business milestones, configure steps that enforce data quality, add condition-based branching for diverging paths, activate and secure BPFs, and troubleshoot the most common configuration issues.
The key principles to carry forward:
For your next steps, explore how views and dashboards can surface BPF stage data to give managers real-time visibility into process health — Creating and Customizing Views in Model-Driven Apps: Filters, Sorting, and Editable Grids covers the techniques you need. You might also look at how security roles interact with the broader model-driven app experience in Power Apps Security: Roles, Sharing, and Data Permissions to ensure your BPF security design fits within your overall data access model.