Skip to main content
Branch is an if / else if / else step that routes notifications through different workflow paths based on conditions. You can add up to 10 branches (9 condition branches + 1 default branch). The first branch that satisfies its condition will be executed. Conditions are evaluated at runtime, using the latest available data at the moment the Branch node executes. Common use cases: A/B testing, personalized journeys, conditional follow-ups, multi-step reminders, routing by trigger payload, batch/digest data, or tenant settings.

​
Execution Model

The Branch node supports two branch types:
  1. Condition Branch: Executes when its condition evaluates to true (up to 9 condition branches).
  2. Default Branch: Executes when no condition branch evaluates to true.
Execution rules:
  • Conditions are evaluated in order from first to last.
  • The first branch whose condition evaluates to true is executed.
  • If no condition evaluates to true, the default branch executes.
  • If the branch has no nodes below it, it automatically connects to the exit node.

​
Condition Syntax

Conditions evaluate data from trigger payloads, user properties, tenant properties, or message status. A condition consists of four components: Data type, Key, Operator, and Value.

​
Data Types

Data TypeDescriptionWhat to pass in keyWhat to pass in dynamic value
Input PayloadData from trigger payload or nodes before the branchDirectly specify as key with no prefixUse key directly (e.g., payment_due_date)
ActorProperties of the user who performed the actionAdd as <property_key>Add as $actor.<property_key>
RecipientProperties of the user receiving the notificationAdd as <property_key>Add as $recipient.<property_key>
TenantProperties of the tenant/brandAdd as <property_key> for reserved properties, properties.<property_key> for custom propertiesAdd as $brand.<property_key> or $brand.properties.<property_key>
Message StatusDelivery status of previously sent notificationsPass the node slug whose message status you want to check, e.g., message_status from node "welcome-email" == "seen"Pass the status you want to check, e.g., "seen"Value can be one of delivered, seen, clicked, delivery_failed

​
Operators

OperatorUsageSupported Data Types
== / !=Equal to / not equal to (case sensitive)All
>, >=Greater than / greater than or equalNumbers, timestamps
<, <=Less than / less than or equal toNumbers, timestamps
contains / not containsSubstring or array item match / no substring or array item matchStrings, arrays
is empty / is not emptykey is missing, empty or null / key is present, not empty or nullAll
datetime is / datetime is before / datetime is afterDatetime equal to / less than / greater thanTimestamps
intersects / not intersectsAny array value matches / No array values matchArrays
Type constraints: If a key’s data type doesn’t match the operator (e.g., using > on a string), the condition will always evaluate to false.

​
Values

You can either add a fixed value or a dynamic value to the condition.

​
Fixed values

TypeSyntax
StringEnclose within double inverted commas as "string"
NumberAdd without double inverted commas as 100, 99.99
BooleanAdd without double inverted commas as true, false
DatetimeEnclose within double inverted commas as "2024-01-01T00:00:00Z" or "now+1d"
Message StatusSelect from dropdown on frontend or pass as $message.seen in workflow API. Value can be one of delivered, seen, clicked, delivery_failed

​
Dynamic values

Dynamic values are evaluated based on the data available at the node input along with actor, recipient or tenant properties. Refer below table for types of dynamic values and their respective syntax.
TypeSyntax
Input payloadAdd key directly (e.g., payment_due_date)
ActorAdd as $actor.<property_key> (e.g., $actor.role)
RecipientAdd as $recipient.<property_key> (e.g., $recipient.plan)
TenantAdd as $brand.<property_key> for reserved properties, add as properties.<property_key> for custom properties (e.g., $brand.timezone, properties.timezone)

​
Combining Conditions

Combine conditions using AND and OR logical operators:
  • AND: All conditions must evaluate to true
  • OR: At least one condition must evaluate to true
Example: (user_role == "admin" OR user_role == "manager") AND priority == "high"
Nested grouping is not supported. Rewrite complex logic using equivalent expanded conditions. For example, (a OR b) AND c becomes (a AND c) OR (b AND c).

​
Condition on Message Status

Message Status is a special data type that lets you evaluate the delivery or engagement state of a previously sent notification. Common use cases include reminder and escalation workflows—for example, sending a follow-up notification if the user has not seen the earlier message. When using message status checks, always add a delay before evaluating the status to allow sufficient time for vendors to report delivery or engagement events.
Condition Syntax:
Condition on message status looks like this
<node slug> IS/ IS_NOT <message status>. Eg. message_status from node "welcome-email" is "seen". You can find node slug below node name in the workflow editor. 
  {
      "op": "IS",
      "ref": "multichannel_1", // node slug
      "value": "$message.seen", // message status
      "variable": "message_status", // fixed value
      "variable_ns": "$ref" // fixed value
  }
On UI, it looks like this:

Message Status and their meaning:
Here’s a list of all message statuses, supported operators and their meaning.
StatusISIS_NOTDescription
delivered✅✅Notification reached user (includes delivered, seen, clicked)
seen✅✅User viewed/opened or clicked notification. For Android Push channel, user clearing the notification from tray is also considered as seen.
clicked✅✅User clicked notification
delivery_failed✅❌Vendor reported some error which prevented delivery
For multi-channel and smart channel routing, delivered, seen and clicked status requires at least one successful channel, while delivery_failed requires all channels to fail.

Per-Channel Message Status:
Following message statuses are currently tracked for each channel:
ChannelsDeliveredSeenClicked
Email, Android Push, iOS Push, Web Push, Inbox✅✅✅
WhatsApp✅✅❌
SMS, Slack, MS Teams✅❌❌
To track message status for external channels like WhatsApp, SMS, and Email, you’ll need to add suprsend tracking URL as webhook in your vendor dashboard.

​
Frequently Asked Questions

Up to 10 branches total: 9 condition branches + 1 default branch.
The first branch in order is executed (as mentioned in the intro). Place branch with more specificity before the branch with lesser condition if they have common condition set.
Only after the referenced node has executed and vendor feedback has been received. The condition checks actual delivery state, not input data.
Message Status requires vendor tracking to be setup. Ensure you have:
  • SuprSend tracking URL added as webhook in your vendor dashboard.
  • Proper SDK installation for Android Push and iOS Push channels.
  • For Inbox, Slack, MS Teams, engagement status are automatically tracked.
In case all the above conditions met and still the condition is not evaluated, it could be due to delay in vendor reporting the status.
  • IS delivery_failed: Evaluates to true only when the vendor explicitly reports a delivery failure. For multi-channel delivery nodes, this condition is met only if all channels fail.
  • IS_NOT "delivered": Indicates that a successful delivery status has not been received for the channel. This can also occur if the vendor has not yet reported the delivery status by the time the branch condition is evaluated.
Each node has a unique slug. You can see node slug below node name in the workflow editor. You can also edit node slug by clicking on navigation icon next to node name and selecting “Edit metadata”.