Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.digifist.com/llms.txt

Use this file to discover all available pages before exploring further.

Condition nodes evaluate data about the customer or their triggering event and split the flow into a YES path and a NO path. They are what makes automations targeted rather than generic — instead of sending the same message to every customer who triggers a flow, conditions let you branch based on order value, purchase history, segment membership, reply behavior, and more. Every condition branch must connect to at least one subsequent node. A branch that leads nowhere will fail flow validation.

​
What this covers

  • All ten available condition types
  • AND/OR logic and nested grouping
  • How to read a condition node’s output
  • Practical branching patterns

​
Condition types

MESSAGE_DELIVERY_STATUS — Evaluates whether the last message sent to the customer in this flow was delivered or read.Use this to branch based on whether previous communication reached the customer. A common pattern is to send a recovery message, wait 24 hours, then check delivery status before deciding whether to send a follow-up or exit the flow for undelivered cases.Available evaluations: delivered, read, failed, sent (but not yet delivered or read)
USER_REPLY_STATUS — Evaluates whether the customer replied to the last message sent in this flow within a defined window.Use this to suppress a follow-up message when the customer has already engaged. For example: send an initial recovery message, wait 4 hours, check if the customer replied — if YES, exit the flow; if NO, send a reminder.This condition requires an active conversation window context — it checks for a customer-initiated inbound message after the last outbound action in the flow.
ORDER_RECENCY — Evaluates how recently the customer placed an order.Use this to prevent recovery or re-engagement messages from reaching customers who have already purchased since the trigger fired. This is particularly useful in abandoned checkout flows where the customer may have completed a purchase on a different device or channel after abandoning.Available operators: before / after / within last X days
CUSTOMER_TAG — Evaluates whether the customer currently has a specific Shopify tag on their customer record.Use this to differentiate treatment based on lifecycle stage, loyalty tier, or any other tag-based segmentation your store uses. For example: branch VIP-tagged customers to a premium offer template while routing standard customers to a general recovery template.Available operators: has tag / does not have tag
PRODUCT_IN_ORDER_HAS_TAG — Evaluates whether the order that triggered this flow contains a product with a specific Shopify product tag.Use this to send product-category-specific follow-ups. For example: in a post-purchase cross-sell flow, check whether the triggering order contained a product tagged “Shoes” — if YES, send an accessories recommendation; if NO, route to a different recommendation template.Available operators: contains a product with tag / does not contain a product with tag
SEGMENT_MEMBERSHIP — Evaluates whether the customer is currently a member of a specific segment.Use this to apply dynamic audience logic mid-flow. Segment membership is evaluated at the moment the customer reaches the condition node — not at the time the flow was triggered. This means a customer who joins or leaves a segment between trigger and condition evaluation will be routed correctly based on their current state.Available operators: is a member / is not a member
ORDER_VALUE — Evaluates the total value of the order that triggered this flow.Use this to differentiate message treatment by order size. The most common pattern is an abandoned checkout flow that routes high-value abandonments to a personalized VIP recovery template and lower-value abandonments to a standard template.Available operators: >, <, >=, <=, =, between
ITEM_COUNT_IN_ORDER — Evaluates the number of line items in the triggering order.Use this to differentiate between single-item and multi-item orders, which often warrant different messaging strategies — a customer who bought one item may respond differently to a cross-sell than a customer who already bought multiple products.Available operators: >, <, >=, <=, =, between
LIST_MEMBERSHIP — Evaluates whether the customer is currently a member of a specific Customer List.Use this similarly to segment membership, but against static lists rather than dynamic rule-based segments. Useful for suppressing messages to customers on a VIP or do-not-contact list, or for routing list members to a dedicated message variant.Available operators: is a member / is not a member
CUSTOMER_COUNTRY — Evaluates the customer’s country from their Shopify profile.Use this to localize messaging — routing customers from different markets to templates written in the appropriate language, or applying market-specific offers. Particularly relevant for Galantis’s primary markets (LATAM, MENA, India) where a single flow serving multiple countries often needs country-level branching.Available operators: is / is not / in list / not in list

​
AND/OR logic and grouping

Multiple conditions can be combined within a single Condition Node using AND and OR operators, and grouped for complex evaluation. AND logic within a group — all conditions in the group must be true for the group to evaluate as true: 
Order Value > 100
AND Customer Country = MX
→ Both must be true
OR logic between groups — if any group evaluates as true, the overall condition evaluates as true: 
(Order Value > 100 AND Customer Country = MX)
OR
(Customer Tag = "VIP")
→ Either group being true is sufficient
This structure allows conditions like: “Route to the VIP template if the order is over $100 from Mexico, OR if the customer is tagged VIP regardless of order value.” Group conditions in the condition node’s settings panel by adding rule groups and selecting AND or OR as the inter-group operator.

​
Condition reference

ConditionEvaluatesKey operators
MESSAGE_DELIVERY_STATUSDelivery state of last messagedelivered / read / failed
USER_REPLY_STATUSWhether customer repliedreplied / did not reply
ORDER_RECENCYTime since last orderbefore / after / within X days
CUSTOMER_TAGShopify tag presencehas / does not have
PRODUCT_IN_ORDER_HAS_TAGProduct tag in triggering ordercontains / does not contain
SEGMENT_MEMBERSHIPCurrent segment membershipis / is not member
ORDER_VALUETriggering order total>, <, >=, <=, =, between
ITEM_COUNT_IN_ORDERLine item count in triggering order>, <, >=, <=, =, between
LIST_MEMBERSHIPCurrent list membershipis / is not member
CUSTOMER_COUNTRYCustomer’s countryis / is not / in / not in

​
Best practices

  • Always connect both YES and NO branches. A condition with an unconnected branch fails validation and blocks activation. Even if the NO path should do nothing, connect it to an explicit exit point or omit the condition if branching is not needed.
  • Use ORDER_RECENCY in recovery flows. An abandoned checkout customer who purchased before the recovery message sends should not receive a recovery message. A recency check before the action node prevents this.
  • Prefer segment conditions for complex audience logic. Rather than stacking multiple conditions in a single node, consider building a segment that captures the complex logic and using a single SEGMENT_MEMBERSHIP condition node. This makes the flow easier to read and the segment independently useful for campaigns.
  • Evaluate country conditions early in international flows. If a flow needs to send different templates per language, place the country condition node before any action nodes so routing happens before any message is sent.
  • Flow Builder — Placing and connecting Condition Nodes on the canvas
  • Actions — The Action Nodes that conditions route customers toward
  • Triggers — What data is available from each trigger for condition evaluation
  • Recipes — Condition usage in context across common flow patterns