Skip to main content

Gateways Overview

Gateways control the flow of execution in your BPMN processes. They determine which paths to take, when to split execution into parallel paths, and when to synchronize back together.

What Are Gateways?​

In BPMN, gateways are decision points represented by diamond shapes. The BankLingo Process Engine supports three types of gateways, each serving a different purpose:

Gateway Types​

🔀 Exclusive Gateway (XOR)​

Symbol: ◇X or ◇ with X marker

Behavior: Choose exactly ONE path from multiple options

When to Use:

  • Approve/Reject decisions
  • Risk level routing (Low/Medium/High)
  • Amount-based routing
  • Any either/or decision

Example:

Learn more about Exclusive Gateways →

🔁 Parallel Gateway (AND)​

Symbol: ◇+ with plus marker

Behavior: Execute ALL paths simultaneously, wait for ALL to complete

When to Use:

  • Run multiple background checks in parallel
  • Send notifications through multiple channels
  • Collect data from multiple sources
  • Any tasks that can run independently

Example:

Learn more about Parallel Gateways →

🔂 Inclusive Gateway (OR)​

Symbol: ◇O with circle marker

Behavior: Activate ONE OR MORE paths based on conditions

When to Use:

  • Send notifications (email always, SMS if available)
  • Perform optional checks based on data
  • Route to multiple teams conditionally
  • Any scenario where multiple paths may be valid

Example:

Learn more about Inclusive Gateways →

Quick Comparison​

FeatureExclusive (XOR)Parallel (AND)Inclusive (OR)
Paths TakenExactly 1All (always)1 or more
ConditionsRequiredNot allowedOptional
Use Conditions OnGateway OR flowsN/AIndividual flows
Join BehaviorN/A (single path)Wait for ALLWait for activated
Best ForEither/or decisionsIndependent parallel tasksConditional parallel tasks
ExampleApprove/RejectBackground checksMulti-channel alerts

Token-Based Execution​

Starting with the latest implementation, Parallel and Inclusive Gateways use a token-based execution model:

How Tokens Work​

  1. Single Token Start: Process begins with one execution token
  2. Split Creates Tokens: When a gateway splits, it creates a new token for each path
  3. Independent Execution: Each token executes its path independently
  4. Join Waits for Tokens: Join gateway waits for all tokens to arrive
  5. Merge and Continue: Tokens merge back into a single token after join

Example Flow​

Benefits​

  • True Parallelism: Each path executes independently
  • State Isolation: Each token tracks its own position and history
  • Reliable Synchronization: Join gateways know exactly how many tokens to expect
  • Debugging: Logs show each token's journey through the process

When to Use Which Gateway?​

Decision Tree​

Real-World Scenarios​

Loan Approval (Exclusive)​

<bpmn:exclusiveGateway id="Gateway_Amount">
  <bpmn:extensionElements>
    <custom:properties>
      <custom:property name="Condition" value="
        return amount > 50000 ? 'Flow_Senior' : 'Flow_Standard';
      " />
    </custom:properties>
  </bpmn:extensionElements>
</bpmn:exclusiveGateway>

Result: Either senior approval OR standard approval (not both)

Background Checks (Parallel)​

<bpmn:parallelGateway id="Gateway_Checks">
  <bpmn:outgoing>Flow_Credit</bpmn:outgoing>
  <bpmn:outgoing>Flow_Employment</bpmn:outgoing>
  <bpmn:outgoing>Flow_Identity</bpmn:outgoing>
</bpmn:parallelGateway>

Result: All three checks run at the same time

Notifications (Inclusive)​

<bpmn:inclusiveGateway id="Gateway_Notify">
  <bpmn:outgoing>Flow_Email</bpmn:outgoing>
  <bpmn:outgoing>Flow_SMS</bpmn:outgoing>
  <bpmn:outgoing>Flow_Push</bpmn:outgoing>
</bpmn:inclusiveGateway>

<bpmn:sequenceFlow id="Flow_SMS" sourceRef="Gateway_Notify" targetRef="Task_SMS">
  <bpmn:conditionExpression>hasPhone === true</bpmn:conditionExpression>
</bpmn:sequenceFlow>

Result: Email always + SMS if customer has phone + Push if customer has app

Common Patterns​

Pattern 1: Simple Branching​

Pattern 2: Parallel Execution​

Pattern 3: Conditional Parallel​

Pattern 4: Nested Gateways​

Next Steps​

Execution Logs​

All gateways produce detailed logs to help you understand and debug flow decisions:

[GATEWAY] Evaluating exclusive gateway: Gateway_Amount
[GATEWAY] Available paths: 2
[GATEWAY]   → Flow_Senior: 'Senior Approval' → Task_SeniorReview
[GATEWAY]   → Flow_Standard: 'Standard Approval' → Task_StandardReview (DEFAULT)
[GATEWAY] Executing gateway-level condition script
[GATEWAY] ✓ Condition script returned: 'Flow_Senior'
[GATEWAY] ✓ DECISION: Taking flow 'Flow_Senior' → Task_SeniorReview

Check your process execution logs to see exactly how gateways are making decisions in your processes.

Best Practices​

✅ DO:​

  1. Set default flows on Exclusive and Inclusive gateways
  2. Use descriptive names for flows: "High Value (>$100k)" not "Flow_1"
  3. Keep conditions simple - complex logic goes in ScriptTask before gateway
  4. Match split/join pairs - split 3 ways must join 3 ways
  5. Check execution logs to understand gateway decisions

❌ DON'T:​

  1. Don't add conditions to Parallel Gateway flows (all paths always execute)
  2. Don't forget default flows on Exclusive/Inclusive gateways
  3. Don't use complex expressions in conditions (hard to debug)
  4. Don't mismatch token counts between split and join
  5. Don't forget to complete all parallel paths (join will wait forever)

Further Reading​