Node Types
Reference the node types available when building a journey.
This page will cover each available node type, including Send Email, Wait, Branch, A/B Split, Update Contact, Trigger Event, Trigger Webhook, and External Check.
Documentation in progress
This page is being written. The Branch node is documented below; the others follow.
Branch
logic.branch routes each contact down its Yes or No path. Its conditions are the same filter grammar segments and campaign audiences use, and they are evaluated by the same engine at the moment the contact reaches the step, so a branch can test anything a segment can:
- Properties —
plan equals pro,signup_date within the last 30 days. - Email engagement — opened, clicked, received, bounced or complained, optionally limited to a campaign, a template or a subject, and optionally inside a rolling timeframe. Opens by link scanners and other bots are excluded, as they are everywhere else.
- Custom events — did (or did not do)
checkout_startedat least once in the last 7 days, with conditions on the event's payload. - Segment membership — is, or is not, a member of a saved segment.
In the builder, the Branch inspector shows the segment filter editor. Over the API, the node's config carries a filter:
{
"id": "opened-welcome",
"type": "logic.branch",
"config": {
"filter": {
"filterMatch": "AND",
"items": [
{
"type": "activity-rule",
"activityType": "email_opened",
"quantifier": "at_least",
"count": 1,
"timeframe": { "value": 3, "unit": "days" },
"conditions": [
{ "field": "emailTemplateId", "operator": "EQUALS", "value": "<template id>" }
]
}
]
}
}
}Connect the yes and no handles to the steps each path should continue with. Publishing validates the filter the way a segment is validated, and refuses an empty one: a branch with no conditions would send everyone down Yes.
The activity log records which path a contact took (Took the Yes path). When you enroll a test contact, the log also says how many of the top-level conditions matched, so a rehearsal explains its decision.
Property rules (older journeys)
Branch nodes built before filter conditions existed carry match: "all" | "any" and a list of rules (property, operator, value) and keep working unchanged. The inspector offers Switch to filter conditions, which converts the rules one-way: comparisons map directly, a list membership becomes a group of comparisons, and the absolute-date operators before/after (which have no filter equivalent) are reported back so you can rebuild them with a relative timeframe.