Multi-table business process flows

What it does

A single business process flow can carry a deal across up to five different tables — the classic shape being Lead, then Opportunity, then Quote, then Order, then Invoice. The stage bar follows the user onto each new record, so the process looks like one continuous journey rather than five disconnected ones.

Key facts

Five unique tables per process is the hard cap. A table can be revisited more than once (a closed loop back to Opportunity is fine) without counting again.
Every stage after the first can sit on a different table, but a 1:N relationship must exist between the tables involved for the process to move across.
The out-of-the-box Sales estate ships process definitions of exactly this kind — the Lead to Opportunity Sales Process is the reference implementation and is the fastest way to see the mechanics before you build your own.
The process instance lives on the BPF's own Dataverse table and references the records it has traversed, which is what makes end-to-end cycle-time reporting possible without stitching tables together yourself.
Multi-table processes do not work offline. Offline BPF support in a Power Apps mobile app is single-table only.
The standard limits still apply: 30 stages, 30 steps per stage, 10 active processes per table, and the process has to be activated before anyone sees it.
Stage-level workflows fire on entry and exit of a stage regardless of which table that stage belongs to; global workflows on the process fire on activation and archiving.
Action steps inside a stage are constrained: actions taking Table, EntityCollection or Choice parameters aren't supported, nor are actions with multiple EntityReference outputs, nor global actions with no primary table.
Security is evaluated per record, not per process. A user who can see the process can be shown stages that belong to records they can't read.

When to use / skip

Use it when the client genuinely thinks in one deal lifecycle and the handover between record types is a real business moment — sales qualifies, presales quotes, operations orders. The single stage bar makes the handover visible and gives you one process record to measure the whole cycle from.

Skip it when the downstream records aren't reliably created. If half the deals close without a Quote record because the client emails PDFs from somewhere else, a process that expects a Quote stage will strand deals mid-bar and sellers will abandon it. The same applies where Order and Invoice live in a finance system rather than Dataverse.

Also skip it if mobile offline is a requirement. That's a straight incompatibility, not something to design around.

For most CRM-only implementations, a single-table Opportunity process plus a separate short Lead process is easier to run and reports just as well. Reach for multi-table when the client's value is in the handovers.

Configuration decisions

Where the process starts. Starting on Lead means the process instance covers qualification; starting on Opportunity keeps the reporting cleaner but loses lead-stage timing.
Which relationship each cross-table transition uses, and whether that relationship already exists or needs creating as part of the build.
Whether Quote, Order and Invoice stages are in scope at all, or whether the process stops at Closed Won and hands off to another system.
What happens to the process when a record is created out of band — a Quote created directly rather than from the Opportunity won't join an existing process instance.
Whether stage automation lives on the BPF table (one place, all tables) or on the individual record tables.
How you'll report cycle time: from the BPF table's stage history, or from a warehouse that also holds the finance side.

Gotchas

Qualifying a Lead creates the Opportunity through platform logic, and how the process carries across depends on how the qualify path is configured. Test the actual conversion, not a manually created Opportunity.
Records created independently of the process (a Quote made from the Quotes grid) start their own instance or none at all. This is the single biggest source of "the pipeline numbers don't add up" on multi-table designs.
Five tables is a design limit, not a target. Long processes have a fiddly stage bar on smaller screens and the stage flyout doesn't expand into the side pane on mobile.
Deleting or deactivating a downstream table's process participation breaks in-flight instances; there's no graceful migration for records mid-process.
The BPF table has to be added to the solution by hand alongside the process, and on multi-table processes it's easy to ship the process and forget the table.
Users moving backwards across a table boundary is allowed and does happen. Any automation assuming forward-only movement will misfire.

Consultant notes

Ask the client to walk you through one real deal end to end, including who touches which record. If nobody can name the person who creates the Order, the multi-table process won't survive contact with reality.
Demo the handover moment specifically — the point where pressing Next lands the user on a new record. That's what sells the design, and it's also what raises the objections you want early.
Push back on including Invoice unless invoicing genuinely happens in Dataverse. It's the stage most often bolted on and least often used.
Check offline requirements before committing. If the field sales team works offline, this design is off the table.
Before go-live, test creating each downstream record both from the process and directly, and agree with the client what the direct path means for reporting.

Worth another look if the client adds a finance integration, or if mobile offline moves from nice-to-have to a requirement.