Flow Validation

Check: Every Action Node in the flow must reference a template with APPROVED status.Type: BlockingWhat 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.

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.

Check: Every node in the flow must be connected — no orphaned nodes, no dead-end paths.Type: BlockingWhat 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.

Check: Every Condition Node must have both its YES branch and NO branch connected to a subsequent node.Type: BlockingWhat 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

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.

Check: Every Condition Node must have its logic fully configured — no empty fields, no partially defined rules.Type: BlockingWhat 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.

Check: The automation must have a frequency cap configured.Type: BlockingWhat 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 for guidance on which cap to choose.

Check: Galantis AI evaluates the flow’s logical quality against automation best practices and surfaces advisory recommendations.Type: Advisory — non-blockingAdvisory 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.

What this covers

When validation runs

Check types

Validation checks

Validation result summary

How to read validation results

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

​What this covers

​When validation runs

​Check types

​Validation checks

​Validation result summary

​How to read validation results

​Related guides

What this covers

When validation runs

Check types

Validation checks

Validation result summary

How to read validation results

Related guides