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 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 is powered by two evaluators in the Galantis AI framework: GuardResult and PlanningResult. Together they cover everything from missing node connections to unapproved templates to incomplete condition logic.
What this covers
- When validation runs
- The two evaluators and what each checks
- All validation checks and what they look for
- How to read and resolve validation results
- The difference between blocking errors and advisory warnings
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.
The two evaluators
GuardResult — Evaluates structural and compliance conditions that must pass for the flow to be activatable. These are blocking checks — a flow with any GuardResult failure cannot be activated until the issue is resolved.
PlanningResult — Evaluates the flow’s logical completeness and optimization quality. Some PlanningResult checks are blocking; others are advisory. An advisory result surfaces a recommendation without preventing activation.
Validation checks
Check: Every Action Node in the flow must reference a template with APPROVED status.Evaluator: GuardResult — blockingWhat is checked: Galantis inspects every Action Node’s template assignment and verifies the current status of each referenced template via has_unapproved_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 has_unapproved_template flag is checked 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.Evaluator: GuardResult — 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.Evaluator: GuardResult — blockingWhat is checked: Galantis inspects every ConditionNode 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.Evaluator: GuardResult — blockingWhat is checked: Galantis inspects the condition logic defined in each ConditionNode 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.Evaluator: GuardResult — 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.Evaluator: PlanningResult — 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 surfaced by PlanningResult: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 — for instance, you intentionally built a broad flow or an immediate-send back-in-stock notification — dismiss the advisory and proceed to activation.
Validation result summary
| Check | Evaluator | Blocks activation |
|---|
| Template approval status | GuardResult | Yes |
| Node connections | GuardResult | Yes |
| Condition branch completeness | GuardResult | Yes |
| Condition logic completeness | GuardResult | Yes |
| Frequency cap configured | GuardResult | Yes |
| Missing delay after trigger | PlanningResult | No — advisory |
| Identical templates on both branches | PlanningResult | No — advisory |
High-frequency trigger with EVER cap | PlanningResult | No — advisory |
| Broad trigger with no conditions | PlanningResult | No — advisory |
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).
