Process Orchestrator

Best practices

Design guidance that keeps business processes reliable, readable and easy to change.

These practices come from the rules the designer enforces, the way the process runtime behaves, and the reviews that governance tools run on processes. Follow them and your processes are easier to read, fault less often and survive change.

Shape the process

Keep each process focused on one business outcome. Split large processes into a parent and sub-processes, started from a stage flow of type Business Process. Remember that the parent does not wait for the child.
Name things for the reader. Stages as tasks (Review discount, not Stage 2), transitions by their condition (Discount over 20%), Ends by their outcome (Quote sent, Request rejected). Use the Docs section to explain anything that is not obvious.
Use one End per outcome. Several named Ends make the viewer tell the story of each instance at a glance.
Use Tidy up after larger changes, and add titles to transitions so connectors show business language instead of raw expressions.

Route safely

Give every stage a way out. A stage that finds no true transition faults the instance. Add a last transition with an always-true condition, at the end of the Evaluation order, as a catch-all.
Order transitions from most specific to most general. Only the first true transition is taken from a stage.
Give every exclusive and inclusive gateway a default path. Without one, an unexpected value faults the instance.
Match merges to splits. Merge parallel branches with a parallel gateway, and optional branches with an inclusive gateway. Never feed a parallel merge from an exclusive split: only one branch arrives and the instance faults.
Avoid gateways that neither split nor merge, and loops made only of gateways. The designer reports both.
Put complex decisions in logic blocks. When a condition depends on many factors, call a decision table or decision tree from the guard instead of chaining many transitions or gateways.

Design stages

Write the completion criteria you mean. There is no built-in “all” or “any” option; express it, and think about canceled tasks and disabled users.
Set the deadline in Assignment > Due Date, the date escalation checks, and use the same expression in General > Due Date. Take SLA durations from configuration values so business users can change them without republishing.
Add escalation stages for real SLAs instead of building schedulers. Remember that escalation can happen up to the Escalation Monitor’s minimum interval after the due date.
Use stage flows for automated work. There is no “system” assignment; a step without people is a flow in On Entering or On Exiting.
Guard optional flows with Run only when instead of putting the check inside the flow, so the trace shows whether the flow ran.

Keep it fast

Keep stage flows short, especially in processes with parallel branches. Completing a task runs the On Exiting flows, the routing and the next stages’ On Entering flows while the user’s task is being saved, and the instance’s other branches wait meanwhile. All of it counts toward Dataverse’s two-minute limit for synchronous operations.
Move long-running work out of the stage, for example into an asynchronous recipe.
Enable tracing where you need it. It is invaluable in development and test, and while you investigate a production problem; it also adds records to every instance.

Change safely

Publish, test, then activate. Use Publish when someone should review the version first, and Publish & Activate for tested changes.
Roll back by activating the previous version. Running instances are never moved to the new version.
Use the Precondition tab to stop processes from starting for the wrong users or records, instead of checking inside the first stage.
Check dependencies before deleting. A process that another process, flow or recipe uses cannot be deleted.

Use governance reviews

When processes are reviewed by Logic Guard, these findings relate to the topics above:

Rule	Finding	What to do
BP-004	No reachable End	Connect every path to an End.
BP-006	Stage with no outgoing transition	Connect it to a stage, gateway or End.
BP-013	Transition with no guard	Add a condition (parallel and default paths are not flagged).
BP-028	Gateway neither splits nor merges	Add paths or remove the gateway.
BP-029	Guard or default not allowed by the gateway kind	Remove the condition or default, or change the kind.
BP-030	Parallel merge fed by an exclusive split	Use a matching merge.
BP-031	Decision gateway without a default path	Add a Default path.