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

# Flow Validation

> The validation checks Galantis AI runs before an automation can be activated — what is evaluated, what each result means, and how to resolve issues.

Flow validation is a mandatory step that runs before any automation can be activated. It evaluates the assembled flow against a set of structural, compliance, and configuration checks and returns either a clean result — the flow can proceed to activation — or a set of flagged issues that must be resolved first.

Validation produces two types of results: **blocking checks** that must pass before activation is permitted, and **advisory checks** that surface recommendations without preventing activation.

## What this covers

* When validation runs
* Blocking checks and advisory checks
* All validation checks and what they look for
* How to read and resolve validation results

## When validation runs

Validation runs automatically when you attempt to activate an automation. It also runs continuously in the background during flow building — issues detected during building are surfaced as inline node highlights without blocking the canvas. The formal validation gate only applies at the moment of activation.

A flow can be saved in any incomplete state as a draft — validation does not prevent saving. It only prevents the transition from inactive to active.

## Check types

**Blocking checks** — Structural and compliance conditions that must pass for the flow to be activatable. A flow with any blocking failure cannot be activated until the issue is resolved.

**Advisory checks** — Logical completeness and optimization quality checks. Advisory results surface recommendations without preventing activation. A flow with unresolved advisory suggestions can still be activated.

## Validation checks

<Tabs>
  <Tab title="Template Approval">
    **Check:** Every Action Node in the flow must reference a template with `APPROVED` status.

    **Type:** Blocking

    **What is checked:** Galantis inspects every Action Node's template assignment and verifies the current status of each referenced template. If any Action Node references a template in `DRAFT`, `PENDING_APPROVAL`, or `REJECTED` status, the flow fails this check.

    **Why it blocks:** WhatsApp does not accept message sends using unapproved templates. Activating a flow with an unapproved template would result in every customer who reaches that Action Node receiving a failed message send — the flow would appear active but would not function.

    **How to resolve:**

    * Open **Templates** and check the status of the template assigned to the flagged Action Node
    * If `PENDING_APPROVAL` — wait for Meta's review to complete. Approval typically takes minutes to a few hours
    * If `DRAFT` — submit the template for Meta review
    * If `REJECTED` — review the rejection reason, fix the template content, and resubmit

    Once the template reaches `APPROVED` status, return to the flow and attempt activation again — no changes to the flow itself are required.

    <Note>
      A template that was `APPROVED` when the automation was built can be paused by Meta after activation. The template approval check runs at activation time — it does not continuously monitor template status after the flow is live. If a template is paused post-activation, the flow will remain active but affected Action Nodes will fail for customers who reach them.
    </Note>
  </Tab>

  <Tab title="Node Connections">
    **Check:** Every node in the flow must be connected — no orphaned nodes, no dead-end paths.

    **Type:** Blocking

    **What is checked:** Galantis validates that the flow graph has no disconnected nodes — every node placed on the canvas must have at least one incoming edge (except the TriggerNode, which has none by design) and at least one outgoing edge (except terminal Action Nodes and explicit exit points).

    Specifically:

    * Every node is reachable from the TriggerNode via a connected edge path
    * No node sits on the canvas without being connected to the flow

    **Why it blocks:** An orphaned node indicates an incomplete flow — either a node was placed and never connected, or a connection was deleted without removing the node. Customers enrolled in the flow would never reach disconnected nodes, making them dead configuration that implies intent but delivers nothing.

    **How to resolve:** Open the canvas and look for any nodes without connecting edges. Either connect them into the flow at the appropriate position, or delete them if they were placed in error. The canvas highlights disconnected nodes when validation fails.
  </Tab>

  <Tab title="Condition Branch Completeness">
    **Check:** Every Condition Node must have both its YES branch and NO branch connected to a subsequent node.

    **Type:** Blocking

    **What is checked:** Galantis inspects every Condition Node in the flow and confirms that both output paths — the YES branch and the NO branch — connect to at least one subsequent node. A condition with one connected branch and one dead-end branch fails this check.

    **Why it blocks:** A condition branch that leads nowhere means customers routed down that path have no further nodes to execute — they are enrolled and then silently dropped from the flow. This is almost always a configuration error rather than an intentional design choice.

    **How to resolve:**

    * Identify the Condition Node with an unconnected branch — it will be highlighted on the canvas
    * Connect the open branch to an Action Node, Delay Node, or another Condition Node
    * If the intent is genuinely to do nothing on one path — for example, a YES branch sends a message but the NO branch should exit silently — connect the NO branch to an explicit exit node or a final Action Node appropriate for that path

    <Tip>
      If one branch of a condition should result in no action — for example, "if the customer has already ordered, exit the flow" — connect that branch to a terminal point rather than leaving it unconnected. This makes the intent explicit and passes the validation check.
    </Tip>
  </Tab>

  <Tab title="Condition Logic Completeness">
    **Check:** Every Condition Node must have its logic fully configured — no empty fields, no partially defined rules.

    **Type:** Blocking

    **What is checked:** Galantis inspects the condition logic defined in each Condition Node and verifies that every rule has a complete configuration: a condition type selected, an operator chosen, and a value provided. A condition node that was placed but not configured — or where a rule was started but not completed — fails this check.

    **Common incomplete states:**

    * A condition type selected but no operator or value set
    * An AND/OR group with an empty rule slot
    * A condition using a dynamic value source that has not been selected

    **How to resolve:** Open each flagged Condition Node and complete all rule fields. Every rule in every group must have a fully specified condition type, operator, and value before the flow can activate.
  </Tab>

  <Tab title="Frequency Cap">
    **Check:** The automation must have a frequency cap configured.

    **Type:** Blocking

    **What is checked:** Galantis verifies that a frequency cap is set on the automation. An automation with no frequency cap configured fails this check.

    **Why it blocks:** A flow without a frequency cap has no protection against a customer being enrolled and messaged multiple times in rapid succession if the trigger fires repeatedly. This is a guardrail against accidental over-messaging, which damages phone number quality and customer trust.

    **How to resolve:** Open the automation settings and configure a frequency cap appropriate for the trigger type and use case. See [Automations — Frequency Caps](/whatsapp/automations/frequency-caps) for guidance on which cap to choose.
  </Tab>

  <Tab title="Optimization Advisories">
    **Check:** Galantis AI evaluates the flow's logical quality against automation best practices and surfaces advisory recommendations.

    **Type:** Advisory — non-blocking

    Advisory checks do not prevent activation. They surface as highlighted suggestions that can be reviewed, acted on, or dismissed. A flow with unresolved advisory suggestions can still be activated.

    **Common advisories:**

    **Missing delay after trigger** — No Delay Node between the TriggerNode and the first Action Node. Immediate dispatch is flagged as an advisory because most use cases benefit from a short delay. Exception: the Back-in-Stock notification flow intentionally omits a delay — this advisory can be dismissed in that context.

    **Identical templates on both condition branches** — Both the YES and NO paths of a Condition Node reference the same template. The condition adds no differentiation value and is likely a configuration oversight.

    **High-frequency trigger with `EVER` cap** — A trigger like `ORDER_PLACED` or `CUSTOMER_CREATED` paired with an `EVER` frequency cap flags the question of whether once-per-customer-lifetime enrollment is genuinely intended. If so, the advisory can be dismissed. If not, the cap should be adjusted.

    **Broad trigger with no conditions** — A trigger that fires for all customers (e.g., `CUSTOMER_CREATED`, `ORDER_PLACED`) with no Condition Node before the first Action Node sends the same message to every enrollee without differentiation. Galantis AI flags this as an opportunity to add targeting.

    **How to resolve or dismiss:** Review each advisory by opening the flagged node on the canvas. If the suggestion is valid, make the recommended change. If the advisory does not apply to your specific flow design, dismiss it and proceed to activation.
  </Tab>
</Tabs>

## Validation result summary

| Check                                  | Type     | Blocks activation |
| -------------------------------------- | -------- | ----------------- |
| Template approval status               | Blocking | Yes               |
| Node connections                       | Blocking | Yes               |
| Condition branch completeness          | Blocking | Yes               |
| Condition logic completeness           | Blocking | Yes               |
| Frequency cap configured               | Blocking | Yes               |
| Missing delay after trigger            | Advisory | No                |
| Identical templates on both branches   | Advisory | No                |
| High-frequency trigger with `EVER` cap | Advisory | No                |
| Broad trigger with no conditions       | Advisory | No                |

## How to read validation results

When validation runs at activation time, results are surfaced in two ways:

**Inline on the canvas** — Nodes with blocking errors are highlighted in a distinct error state. Clicking a highlighted node opens its settings panel, which shows the specific issue and the resolution path.

**Validation summary panel** — A summary of all blocking errors and advisory suggestions appears as a list. Blocking errors must be resolved before the activation button becomes available. Advisory suggestions are listed separately and can be individually dismissed.

Work through blocking errors one at a time, starting with the simplest to resolve (unconnected nodes, missing frequency caps) before addressing more complex issues (template approval status, incomplete condition logic).

## Related guides

* [AI Flow Builder](./ai-flow-builder) — How inline validation highlights surface during building, before the formal activation check
* [Automations — Flow Builder](/whatsapp/automations/flow-builder) — The full validation check reference from the flow builder perspective
* [Templates — Approval Lifecycle](/whatsapp/templates/approval-lifecycle) — Resolving template status issues that block activation
* [Automations — Frequency Caps](/whatsapp/automations/frequency-caps) — Configuring the frequency cap required by validation