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.

Actions are what a flow actually does. In Galantis automations, two node types produce execution behavior: the Action Node, which sends a WhatsApp template to the customer, and the Delay Node, which pauses execution for a defined period before the next step runs. Every meaningful automation contains at least one of each.

​
What this covers

  • Action Node configuration and template assignment
  • Delay Node configuration and available time units
  • Variable mapping in action nodes
  • How action execution is tracked

​
Action Node

The Action Node sends an approved WhatsApp template to the customer at the point in the flow where it is placed. It is the only node type that dispatches a message.

​
Configuring an Action Node

1

Select a template

Click the Action Node to open its settings panel. Select an approved template from the template picker. Only templates with APPROVED status are available for selection.
2

Map template variables

For each variable placeholder in the selected template ({{1}}, {{2}}, etc.), assign a value from the available customer or order data fields, or enter static text.Available variable sources:
  • customer.first_name, customer.last_name, customer.email, customer.phone
  • order.order_number, order.total_price, order.product_name
  • Store name
  • Custom static text
See Campaigns — Personalization for the full variable mapping reference — the same data sources apply in automations.
3

Save the node configuration

Save the node. If the assigned template is not APPROVED, the node will be flagged during validation and the automation cannot be activated until the template is approved.

​
Template approval requirement

Action Nodes can only use templates with APPROVED status. An automation with any Action Node referencing an unapproved template is flagged via has_unapproved_template and blocked from activation. This check runs at activation time — if a template is paused by Meta after the automation is already active, the affected Action Node will fail for customers who reach it until the template is restored to APPROVED status.
If Meta pauses a template used in an active automation, affected messages will fail silently for customers who reach that Action Node. Monitor template status in Templates periodically, especially after Meta quality reviews.
Before an Action Node dispatches a message, Galantis validates the customer’s marketing_state. Customers with UNSUBSCRIBED or REDACTED status are skipped — the node execution is recorded as SKIPPED in the activity log rather than FAILED. This distinction is important: a skip is a correct compliance behavior, not an error.

​
Delay Node

The Delay Node pauses the flow for a specific duration before execution moves to the next connected node. It does not send any message — it exists solely to control timing.

​
Available delay units

UnitWhen to use
MINUTESShort pauses within the same session — e.g., 10–30 minutes after trigger
HOURSSame-day delays — e.g., 2–4 hours after an event
DAYSMulti-day sequences — e.g., 3 days after a purchase for a cross-sell
MONTHSLong-term re-engagement sequences — e.g., 1 month after last purchase

​
Why delays matter

A flow without delays sends messages the instant a trigger fires. For most use cases this produces a poor customer experience — a welcome message arriving in the same second as Shopify’s registration confirmation email, or a recovery message sent before the customer has had any time to return on their own. Delays also affect conversion logic. An abandoned checkout recovery that fires 30 minutes after abandonment catches customers while the intent is still fresh. The same flow with a 3-day delay is largely irrelevant.
A useful pattern for multi-step flows is to place a delay after every action node, not just after the trigger. This creates breathing room between messages in a sequence and reduces the risk of a customer receiving two messages in rapid succession.

​
Delay precision and the abandoned checkout offset

For most triggers, delay timing is precise relative to the moment the trigger fires. For ABANDONED_CHECKOUT, factor in the 10-minute polling interval — the trigger fires up to 10 minutes after the actual abandonment event, so a 30-minute delay node results in the message arriving 30–40 minutes after the customer abandoned, not exactly 30. See Triggers for the polling timing detail.
  • Flow Builder — Placing and connecting nodes on the canvas
  • Triggers — Trigger events that precede the first Action or Delay node
  • Conditions — Branching nodes that sit between delays and actions
  • Activity Tracking — How Action Node execution is logged per customer