> ## 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

> Action nodes and Delay nodes — the execution steps that send messages and control timing in automation flows.

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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](/whatsapp/campaigns/personalization) for the full variable mapping reference — the same data sources apply in automations.
  </Step>

  <Step title="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.
  </Step>
</Steps>

### Template approval requirement

Action Nodes can only use templates with `APPROVED` status. An automation with any Action Node referencing an unapproved template is flagged 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.

<Warning>
  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.
</Warning>

### Consent validation at send time

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

| Unit      | When to use                                                              |
| --------- | ------------------------------------------------------------------------ |
| `MINUTES` | Short pauses within the same session — e.g., 10–30 minutes after trigger |
| `HOURS`   | Same-day delays — e.g., 2–4 hours after an event                         |
| `DAYS`    | Multi-day sequences — e.g., 3 days after a purchase for a cross-sell     |
| `MONTHS`  | Long-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.

<Tip>
  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.
</Tip>

### 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](./triggers) for the polling timing detail.

## Related guides

* [Flow Builder](./flow-builder) — Placing and connecting nodes on the canvas
* [Triggers](./triggers) — Trigger events that precede the first Action or Delay node
* [Conditions](./conditions) — Branching nodes that sit between delays and actions
* [Activity Tracking](./activity-tracking) — How Action Node execution is logged per customer