Transitions

What are Transitions?

Transitions define where the process can go after completing a stage. They are the "arrows" connecting stages in your process diagram, but they carry intelligence beyond simple sequencing.

In a simple, linear process, transitions are straightforward—Stage A leads to Stage B, which leads to Stage C. But real-world business processes are rarely this simple. A loan application might be approved, rejected, or returned for more information. An order might proceed to fulfillment, be flagged for review, or be cancelled.

Transitions in FlowOn BPM handle all these scenarios by allowing multiple possible paths from any stage, with rules that determine which path is taken based on data, decisions, or conditions.

Concept	Description
Transition	A defined path from the current stage to a potential next stage
Transition Guard	A rule or condition that must evaluate to true for the transition to be taken
Target Stage	The stage the process moves to when the transition is taken

Transition Types

Transition Type	Description	Use Case
Unconditional	Always proceeds to the next stage when the current stage completes	Linear, sequential steps that always occur
Conditional	Proceeds only if specified business rules evaluate to true	Branching based on data values, user input, or calculated results
Multi-path	Evaluates multiple conditions to determine which of several possible paths to take	Credit scoring tiers, approval levels, exception handling

Transition Guards

Transition Guards are the rules that determine which path is taken when multiple transitions exist from a single stage. When a stage completes, FlowOn BPM evaluates the guards on each outgoing transition and takes the first transition whose guard evaluates to true.

FlowOn BPM leverages FlowOn Logic to provide powerful guard capabilities—from simple conditions to complex Decision Tables and Decision Trees.

Guard Types

Guard Type	Description	Example
Simple Condition	Single field comparison	Amount > 10000
Expression	Complex formula with multiple conditions	CreditScore >= 700 AND LoanAmount <= 50000
Decision Table	Multi-factor lookup returning a routing decision	Routing based on amount, tier, and urgency
Decision Tree	Sequential yes/no evaluations	Risk assessment flowchart

Simple Condition Guards

For straightforward branching based on a single value:

Stage: Initial Review
Transitions:
  1. Target: Fast-Track Approval
     Guard: Application.Amount < 10000
  
  2. Target: Standard Review
     Guard: Application.Amount >= 10000

Expression Guards

For complex conditions involving multiple factors:

Guard: CreditScore >= 700 AND LoanAmount <= 50000 AND NOT(HasPreviousDefaults)

Decision Table Guards

For sophisticated routing with many input factors:

Stage: Credit Assessment
Transitions:
  
  1. Target: Auto-Approval Stage
     Guard: RunLogicBlock("LoanRoutingDecision", ...) = "AutoApprove"
     Priority: 1
  
  2. Target: Standard Review Stage
     Guard: RunLogicBlock("LoanRoutingDecision", ...) = "StandardReview"
     Priority: 2
  
  3. Target: Manual Review Stage
     Guard: RunLogicBlock("LoanRoutingDecision", ...) = "ManualReview"
     Priority: 3
  
  4. Target: Senior Review Stage
     Guard: RunLogicBlock("LoanRoutingDecision", ...) = "SeniorReview"
     Priority: 4

Expression Builder in Guards

All guard conditions use the Expression Builder, which provides access to:

Feature	Description	Example
Field References	Access any field on the process entity	Application.LoanAmount > 50000
Functions	Use FlowOn expression functions	DaysBetween(Application.SubmitDate, Now()) > 30
Logic Blocks	Execute Decision Tables/Trees	RunLogicBlock("RiskAssessment", ...)
Configurations	Reference Configuration variables	Application.Amount > Config("HighValueThreshold")
Operators	AND, OR, NOT, comparisons	CreditScore >= 700 AND LoanAmount <= 50000

Transition Evaluation Flow

When a stage completes, FlowOn BPM evaluates transitions in priority order:

1. Stage Completed - All completion criteria met
2. Evaluate Transitions - Check guards in priority order
3. First Match Wins - Take the first transition whose guard is true
4. Default Fallback - If no guards match, use the default transition
5. Error if No Path - If no valid transition exists, process is stuck

Always Define a Default

If no transition guards evaluate to true and no default transition is defined, the process instance will be stuck. Always ensure at least one transition can be taken from every non-terminating stage.

Transition Priority

When multiple transitions exist from a stage, they are evaluated in priority order:

Priority	Behavior
1 (Highest)	Evaluated first; if guard is true, this transition is taken
2	Evaluated only if priority 1 guard was false
3	Evaluated only if priorities 1 and 2 were false
... (Default)	Typically set as lowest priority; acts as fallback

Priority Best Practices

Order by specificity: Most specific conditions first, most general last

Priority 1: Amount > 100000 AND IsVIP = true → Executive Review
Priority 2: Amount > 100000 → Senior Review  
Priority 3: Amount > 10000 → Standard Review
Priority 4: (Default) → Quick Review

Creating a New Process

When creating a new process, you configure the following settings:

Process Configuration

Setting	Description
Process Name	Unique identifier and display name
Primary Entity	Dynamics 365 entity the process operates on
FlowOn Project	Associates process with a FlowOn project
Process Action	Whether process is exposed as a callable action
Enable Tracing	Activates detailed execution logging

Primary Entity

The Primary Entity specifies the Dynamics 365 entity that this process operates on. Each process instance will be associated with a record of this entity type.

Aspect	Details
Purpose	Defines the data context for the process
Relationship	Each process instance is linked to one record of this entity
Data Access	Process stages can read/write fields on this entity and related entities

Choosing the Right Entity

Select the entity that represents the "subject" of your process:

• Loan Approval → Loan Application entity
• Employee Onboarding → Employee entity
• Order Fulfillment → Order entity
• Support Ticket → Case entity

Process Action

When enabled, the process is exposed as a callable action that can be invoked programmatically.

Scenario	Enable?	Reason
Process is called as a sub-process	✅ Yes	Parent process needs to invoke it
Process triggered by Logic Flow	✅ Yes	Flow needs to start process instances
Process started by external API	✅ Yes	Integration requires programmatic access
Process only started by users	❌ No	Manual initiation is sufficient

What Happens on Save

When you save a new process, FlowOn BPM automatically:

1. Creates the Process Definition — Registers the process with your configured settings
2. Generates a Draft Version — Initializes version 0.1 in Draft state
3. Prepares the Designer Canvas — Empty canvas ready for you to add stages
4. Opens the Process Designer — Takes you directly into design mode