Condition Step

Splits the data flow into two streams based on a ONE expression condition.

This step is available for all transformation types: standalone plans, embedded plans, transformation rules, and transformation catalog items.

Overview

The Condition step evaluates each record against a condition and routes it to one of two outputs. Unlike the Filter step which discards non-matching records, the Condition step preserves all records by sending them to different branches for separate processing.

Use this step to:

Route records to different processing logic based on criteria.
Apply different transformations to different subsets of data.
Separate valid records from invalid ones for different handling.
Implement if-then-else logic in your transformation plan.

Configuration

Define the condition

In the step configuration, enter your condition using a ONE expression in the Condition field.
The expression must evaluate to a Boolean value (true or false).
Connect downstream steps to the appropriate outputs.

Outputs

The Condition step has two outputs:

out_true: Records where the condition evaluates to true.
out_false: Records where the condition evaluates to false.

Connect each output to the appropriate downstream steps for continued processing.

Condition examples

Route by customer type

customer_type = 'Premium'

Premium customers go to out_true, others to out_false.

Route by data quality

email is not null and matches(@"^[^@]+@[^@]+\.[^@]+$", email, true)

Valid emails go to out_true, invalid to out_false.

Route by threshold

order_total >= 1000

High-value orders go to out_true, standard orders to out_false.

Route by region

country in {'US', 'CA'}

North American records go to out_true, others to out_false.

Example: Handling valid and invalid records

A common pattern is to route valid records for normal processing and invalid records for error handling or manual review.

Condition expression

customer_id is not null and
email is not null and
order_date is not null

Processing flow

out_true → Continue with normal transformation and load to target.
out_false → Log to error table or send for manual review.

Condition vs Filter vs Split

Aspect Condition Filter Split

Aspect	Condition	Filter	Split
Number of outputs	2 (`out_true`, `out_false`)	1 (matching records only)	3 (`out_true`, `out_false`, `out_all`)
Non-matching records	Routed to `out_false`	Discarded	Routed to `out_false`
All records output	No (split between outputs)	No	Yes (via `out_all`)
Use case	Route to different processing	Remove unwanted data	Route while keeping a copy of all data

Number of outputs

2 (out_true, out_false)

1 (matching records only)

3 (out_true, out_false, out_all)

Non-matching records

Routed to out_false

Discarded

Routed to out_false

All records output

No (split between outputs)

Yes (via out_all)

Use case

Route to different processing

Remove unwanted data

Route while keeping a copy of all data

Best practices

Name your branches clearly: When building complex plans, add descriptive names or comments to clarify what each branch processes.
Handle both outputs: Always connect both outputs, even if one branch just terminates. Unconnected outputs can cause confusion when reviewing plans.
Keep conditions simple: Complex conditions are harder to maintain. Consider using multiple Condition steps for complex routing logic.
Consider null values: Null values can cause unexpected routing. Explicitly handle nulls in your conditions when needed.