Branch
Use branch to route notifications through different workflow routes based on conditions
Branch is an if/elseif/else
step used to route notification through different paths in a workflow based on conditions. Some common usecases could be to send multi-step reminder to users until payment is made and route notification on different paths based on user properties.
You can add upto 10 branches in a workflow. The First branch satisfying the condition in the order will be executed.
How branch works?
There are 2 types of branches: Condition branch, Default branch
- Condition branch - User proceeds through this branch when a condition is met. The condition can be applied on recipient, actor, brand properties and node input data. You can add upto 9 condition branches. If 2 branches satisfies the condition, the first branch in the order will be executed.
- Default branch - This is the fallback branch which is executed if no condition branch results in truthy value.
Constructing a condition
You can add conditions on data payload passed in the trigger, user properties and brand properties. A condition is a combination of 3 parts: Data type, Key, operator and Value.
Data type
You can apply conditions to all data available at the node's input. For instance, if a condition branch follows a batch, fetch, or webhook node, it can utilize data that has been modified or added by those nodes.
Data Type | Description | Referring this property in condition |
---|---|---|
Input Payload | This includes the data from your trigger payload and any data modified or added by nodes such as data transform, batch/digest, or webhook/fetch nodes before the branch node. | Specify key if you are adding this variable in key or value field. |
Actor | Actor properties. In case of event trigger, distinct_id works both as actor and recipient and for inline workflow trigger, it is the distinct_id in actor object. | Directly specify key if you are adding this in key or add as $actor.<property_key> if you add it in value field. |
Recipient | Recipient properties. It is the distinct_id in your event trigger or the key value defined in override recipient field. For inline workflow trigger, it is the distinct_id in recipient object. | Directly specify key if you are adding this in key or add as $recipient.<property_key> if you add it in value field. |
Brand / Tenant | Brand / Tenant properties. It is all the properties of the tenant_id in your workflow trigger. | Directly specify key if you are adding this in key or add as$brand.<property_key> if you add it in value field. |
Key-Value Pair
- Key - It is the variable key in your data input to apply condition on.
- Operator - you can use any of the below operators to compare key and value:
Operator | Description |
---|---|
== | key is equal to value. This is a case sensitive check. |
!= | key is not equal to value. This is a case sensitive check. |
> | key is greater than value. can be applied to integers, float values or epoch timestamps |
> = | key is greater than or equals to value. can be applied to integers, float values or epoch timestamps |
< | key is less than value. can be applied to integers and float values |
<= | key is less than or equals to value. can be applied to integers and float values |
contains | key should be a substring or list item of an array. |
not contains | key should not be a substring or match any list item of an array. |
is empty | evaluates to true if the key is missing, is an empty string or has null value. |
is not empty | key should be present and should not be an empty string or null value |
datetime is | datetime comparator. key is equal to value. Both values are converted into timestamp for comparison. Use "now" in value for current timestamp (evaluated at time of node evaluation) and add interval as "now+1d" (y-year, M-month, w-week, d-day, h-hour, m-minute, s-second) |
datetime is before | datetime comparator. key is less than value. Both values are converted into timestamp for comparison. Use "now" in value for current timestamp (evaluated at time of node evaluation) and add interval as "now+1d" (y-year, M-month, w-week, d-day, h-hour, m-minute, s-second) |
datetime is after | datetime comparator. key is greater than value. Both values are converted into timestamp for comparison. Use "now" in value for current timestamp (evaluated at time of node evaluation) and add interval as "now+1d" (y-year, M-month, w-week, d-day, h-hour, m-minute, s-second) |
- Value - Value can be fixed or dynamic (evaluated based on workflow input payload). Dynamic values are helpful when the comparison value is dynamic for each user. For example, in case of payment reminder, the payment due date could vary for each user and is part of your trigger data. You can add condition in this case as
current_date >= payment_due_date
(where both timestamps are in epoch).
Fixed values
Fixed values can be added as:
- string - enclose within double inverted commas as
"string"
- number -
1
,1.2
- boolean -
true
,false
- datetime - "2024-01-01T00:00:00Z", "now" (current timestamp), "now+1d", "now-1d" (current timestamp +/- interval). You can add only 1 of these interval units in the expression (y-year, M-month, w-week, d-day, h-hour, m-minute, s-second).
Dynamic values
You can add input payload key directly as key
with no prefix. All other properties should start with their respective $
prefix. You can refer to all the data types available in workflow in the above section.
Adding Multiple Conditions in a single branch
You can combine multiple conditions in a branch with AND
, OR
operator.
AND
- all conditions separated byAND
should be true for the evaluation to pass.OR
- Evaluation will pass if any of the conditions separated byOR
is true.
If you have a condition (a or b) and c, you can construct it as (a and b) or (b and c).
Updated 8 days ago