Divide Function

The Divide function splits your data flow into multiple output paths based on conditions. Unlike Condition (which has two outputs: true/false), Divide can have many outputs, routing different rows to different branches for specialized processing.

How It Works

Divide evaluates each row against your defined branches:

1. Each branch has a condition
2. Rows matching a branch's condition go to that output
3. A default branch catches rows matching no conditions
4. Each row goes to exactly one output (first matching branch wins)

Divide vs. Condition

Aspect	Divide	Condition
Output count	Multiple (2+)	Exactly 2
Conditions	Multiple, named	Single
Evaluation	First match wins	True/False
Use case	Multi-way routing	Binary decision

Use Divide when:

• More than two processing paths needed
• Routing by category, type, or status
• Complex multi-way branching

Use Condition when:

• Simple true/false decision
• Two clear paths (valid/invalid, yes/no)

Adding a Divide

1. Drag Divide from the Functions section of the Element Panel
2. Connect it to your data source
3. Click the Divide node to configure branches
4. Connect each output to appropriate downstream processing

Configuration Panel

Branch Definition

Each branch consists of:

Branch Name: A descriptive name for the path:

Examples: "High Priority", "US Orders", "Error Records", "Premium Customers"

Condition: Rules determining which rows go to this branch (same syntax as Filter):

Priority = "High"
Region = "US" AND Amount > 1000
Status = "Error" OR ValidationFailed = true

Adding Branches

1. Click Add Branch
2. Enter a branch name
3. Configure the condition
4. Repeat for additional branches

Branch Order

Order matters: Rows go to the first branch whose condition matches.

Example:

Branch 1: Amount >= 10000  (Enterprise)
Branch 2: Amount >= 1000   (Business)
Branch 3: Amount >= 100    (Standard)
Default: (Starter)

A row with Amount = 5000 goes to Branch 1 (Enterprise) because it's checked first, even though it also matches Branch 2.

Default Branch

The default branch catches rows matching no conditions:

• Always exists (cannot be removed)
• Has no condition (matches everything not matched above)
• Ensures no rows are lost

Connecting default:

• Connect it even if you expect it to be empty
• Log or review unexpected default rows
• Consider adding a terminal node (for intentionally discarded rows)

Condition Builder

Each branch uses the standard condition builder:

Single condition:

Type = "Premium"

Multiple conditions (AND):

Type = "Premium"
AND Status = "Active"
AND JoinDate < 2020-01-01

Multiple conditions (OR):

Priority = "Critical"
OR
EscalatedBy IS NOT NULL

Complex logic:

(Region = "US" OR Region = "CA")
AND
(Amount > 5000 OR IsVIP = true)

Output Connections

After configuration, the Divide node shows multiple output ports:

Branch outputs: Each defined branch has its own output connection point, labeled with the branch name.

Connecting outputs:

1. Drag from a branch's output port
2. Connect to the appropriate downstream node
3. Each branch can have its own processing path

Parallel processing: All branch outputs can be processed simultaneously.

Common Use Cases

Processing by Region

Scenario: Different processing for different regions

Branches:

Branch	Condition	Processing
US Orders	Region = "US"	US tax calculation
EU Orders	Region IN ["UK", "DE", "FR", ...]	EU VAT handling
APAC Orders	Region IN ["JP", "CN", "AU", ...]	APAC formatting
Default	(other)	Generic processing

Tiered Customer Handling

Scenario: Different service levels

Branches:

Branch	Condition	Processing
Enterprise	TotalRevenue >= 1000000	Dedicated processing
Premium	TotalRevenue >= 100000	Priority queue
Standard	TotalRevenue >= 10000	Standard processing
Default	(new/small)	Basic processing

Status-Based Routing

Scenario: Route by order status

Branches:

Branch	Condition	Action
Pending	Status = "Pending"	Send to fulfillment
Processing	Status = "Processing"	Update tracking
Shipped	Status = "Shipped"	Notify customer
Delivered	Status = "Delivered"	Request review
Cancelled	Status = "Cancelled"	Process refund
Default	(unknown status)	Error handling

Error Segregation

Scenario: Separate valid from various error types

Branches:

Branch	Condition	Action
Valid	ErrorCode IS NULL	Continue processing
Validation Error	ErrorCode = "VAL"	Send to review
Data Error	ErrorCode = "DATA"	Log and skip
System Error	ErrorCode = "SYS"	Alert and retry
Default	(other errors)	Manual review queue

Product Type Routing

Scenario: Different workflows per product type

Branches:

Branch	Condition	Processing
Physical	ProductType = "Physical"	Inventory check, shipping
Digital	ProductType = "Digital"	Generate download link
Subscription	ProductType = "Subscription"	Setup recurring billing
Bundle	ProductType = "Bundle"	Explode into components
Default	(unknown)	Manual categorization

Branch Condition Patterns

Exact Match

Status = "Active"
Type = "Premium"

Multiple Values

Status IN ["New", "Pending", "Processing"]
Region IN ["US", "CA", "MX"]

Range-Based

Amount >= 1000 AND Amount < 5000
Age >= 18 AND Age < 65

Date-Based

OrderDate >= DATEADD(TODAY(), -30, "day")
ExpirationDate < TODAY()

Null Handling

AssignedTo IS NOT NULL
CompletedDate IS NULL

Text Patterns

Email ENDS WITH "@company.com"
ProductCode STARTS WITH "PROMO-"
Notes CONTAINS "urgent"

Calculated Conditions

${Revenue} - ${Cost} > 1000  // Profit > 1000
${Quantity} * ${Price} >= 500  // Order value >= 500

Merging Branches Back

After parallel processing, often branches need to merge:

Using Append

Stack rows from multiple branches:

[Divide]
  ├── Branch A → [Process A] ─┐
  ├── Branch B → [Process B] ─┼─→ [Append] → [Combined Output]
  └── Branch C → [Process C] ─┘

Using Action Group

When all branches do similar final actions:

[Divide]
  ├── Branch A → [Process A] ─┐
  └── Branch B → [Process B] ─┴─→ [Action Group: Write to DB]

Keeping Separate

Sometimes branches should remain separate:

[Divide]
  ├── US Orders → [US Processing] → [Write to US System]
  └── EU Orders → [EU Processing] → [Write to EU System]

Performance Considerations

Condition Ordering

Put most common conditions first:

• Reduces average evaluation time
• Most rows exit early

Example: If 80% of orders are "Standard":

Branch 1: Status = "Standard"  (80% match here)
Branch 2: Status = "Premium"   (15% reach here)
Branch 3: Status = "Enterprise" (5% reach here)

Complex Conditions

Complex conditions evaluated for every row:

• Keep conditions simple when possible
• Pre-calculate complex logic in Transform before Divide

Instead of:

(A AND B) OR (C AND D) OR (E AND F) OR (G AND H)

Consider:

Transform: RoutingCategory = CASE(...)
Divide on: RoutingCategory = "X"

Branch Count

More branches = more complexity:

• Each branch is a separate path to maintain
• Consider if GroupBy + lookup might be simpler
• 5-10 branches is typical; more may indicate need for different approach

Error Handling

Unexpected Values

Default branch catches unexpected data:

[Divide] → Default → [Log Unexpected] → [Alert]

Empty Branches

If a branch might have no rows:

• Downstream nodes handle empty gracefully
• Consider adding explicit empty handling

Branch Failures

If processing in one branch fails:

• Other branches continue
• Handle errors per-branch
• Consider error aggregation at the end

Troubleshooting

Wrong Branch Selected

Symptoms: Rows going to unexpected branch

Causes:

1. Condition overlaps with earlier branch
2. Condition logic incorrect
3. Data values unexpected

Solutions:

• Review branch order (first match wins)
• Preview data to check actual values
• Test conditions individually

All Rows in Default

Symptoms: No rows match any branch

Causes:

1. Conditions too restrictive
2. Data values don't match expected
3. Type mismatches (string vs number)

Solutions:

• Preview data before Divide
• Verify condition values match data
• Check data types

Missing Rows

Symptoms: Row counts don't add up

Causes:

1. Downstream processing filtering
2. Errors in branch processing

Solutions:

• Check each branch independently
• Count rows at each stage
• Verify all branches connected

Examples

Order Fulfillment Routing

Scenario: Route orders to appropriate fulfillment

[Orders] → [Divide: Fulfillment Type]
            ├── Drop Ship: SupplierShip = true → [Send to Supplier]
            ├── Warehouse: InStock = true → [Warehouse Pick]
            ├── Backorder: InStock = false AND AllowBackorder = true → [Backorder Queue]
            ├── Custom: IsCustom = true → [Custom Build Queue]
            └── Default → [Review Needed]

Support Ticket Triage

Scenario: Route tickets by severity and type

[Tickets] → [Divide: Triage]
            ├── Critical: Priority = "P1" → [Immediate Alert]
            ├── Billing: Category = "Billing" → [Finance Team]
            ├── Technical: Category = "Technical" → [Tech Support]
            ├── Sales: Category = "Sales" → [Sales Team]
            ├── Spam: IsSpam = true → [Delete]
            └── Default → [General Queue]

Data Quality Routing

Scenario: Separate clean data from issues

[Input Data] → [Divide: Data Quality]
               ├── Complete: RequiredFields ALL NOT NULL → [Main Processing]
               ├── Fixable: AutoFixable = true → [Auto Fix] → [Main Processing]
               ├── Review: ManualReview = true → [Review Queue]
               └── Default: (unfixable) → [Reject Log]

Multi-System Sync

Scenario: Route to different target systems

[Changes] → [Divide: Target System]
            ├── CRM: ChangeType IN ["Customer", "Contact"] → [CRM Sync]
            ├── ERP: ChangeType IN ["Order", "Invoice"] → [ERP Sync]
            ├── WMS: ChangeType IN ["Inventory", "Shipment"] → [WMS Sync]
            ├── All: ChangeType = "Master" → [All Systems]
            └── Default → [Log Unrouted]

Best Practices

Meaningful Branch Names

Good:

"Premium Customers", "International Orders", "Error Recovery"

Avoid:

"Branch 1", "Path A", "Other"

Exhaustive Conditions

Ensure all expected cases are handled:

• Define branches for all known values
• Use default for truly unexpected cases
• Don't rely on default for known categories

Document Complex Logic

Add comments or documentation:

• Explain why each branch exists
• Document the business rules
• Note any edge cases

Test Each Branch

Verify all paths work:

• Test with sample data for each branch
• Ensure default branch handles edge cases
• Verify row counts after divide

Next Steps

• Condition Function - Two-way branching
• Filter Function - Single-path filtering
• Append Function - Merge branches back together
• Building Flows - Complete workflow guide