First identify the boundary
Decide whether the problem is:
- the trigger never admitted an enrollment;
- an older publication ran instead of the edited draft;
- execution stopped or waited at a node;
- an external action failed; or
- the action succeeded locally but the provider/recipient outcome differed.
Open Automations and inspect the workflow's publication state, active state, Enrollments, Runtime/Executions, and Logs. Record the first missing or failed transition.
Trigger did not start
- Confirm the Automation is active and has a valid current publication.
- Confirm the event happened after that publication was enabled; activation does not replay old triggers.
- Verify the exact trigger resource and context: connected Facebook form, tenant Form, Pipeline/Status, Contact tag, Job event, schedule, User/Team, or webhook.
- For repeating triggers, verify a valid first occurrence, interval, and tenant timezone.
- For external triggers, check provider/integration health before changing the workflow.
Use the trigger's stable automation-node-trigger-* reference from the node catalog for its exact contract.
Draft changed but runtime did not
Saving changes creates a new draft revision; it does not mutate the published snapshot. Publish the confirmed revision. If publication validation fails, the previous publication remains authoritative. Reverting history also creates a draft and requires an explicit Publish before future runs use it.
Execution stopped at a node
- Read the execution and log message for missing context, resource, variables, or validation.
- Check that branch actions are inside the exact If/Else, Wait, search, or Call Connect branch. A branching action ends its parent path.
- A Wait can be legitimately waiting for time, business window, reply, or condition. Verify its
continuedand optionaltimeoutpaths. - Disabling a workflow permanently cancels unresolved snapshot-bound waits. Re-enabling does not revive them.
- Runtime rechecks active state before each next action and wait continuation. An external side effect already started cannot be rolled back, but later actions stop after disable is observed.
See Wait action and If / Else action.
Message or email failed
Open the Message Delivery Log and follow Troubleshoot Message Delivery. Automation sends can fail because of Contact DND, endpoint suppression, marketing eligibility, inactive/wrong-type template, unresolved variables, unavailable channel/number, registration, attachment/content rules, or provider/network response.
Send SMS and Send Email run immediately when reached. They do not apply Scheduling Hours unless an explicit Wait precedes them.
Call Connect did not complete as expected
Use Use Call Connect in an Automation and the Call Connect node reference. Verify the selected User(s), phone endpoint, Contact phone/call preference, provider/account state, and callback evidence. An internal User answer is not a successful Contact outcome. The canonical rollout, when enabled, also distinguishes Connected, Not connected, Failed, and Cancelled and requires authoritative bridge evidence.
Do not place real calls merely to diagnose documentation. A human with permission should decide whether a controlled provider test is necessary.
Import or reference failure
Imports create inactive, unpublished drafts with fresh IDs. Exact tenant resources must resolve uniquely, graph paths must remain bounded and acyclic, and unknown parameters are rejected. Use Automation JSON import format and the linked node reference instead of guessing a field or database ID.
Escalate with evidence
Provide the Automation name, publication/revision, active state, trigger time/resource, enrollment ID, first failed execution/log, node label/identifier, displayed reason, provider reference, and whether Disable/Enable/Revert/Import recently occurred. Remove secrets and minimize customer data. This guide was verified without running a tenant Automation, sending a message/call, or making a provider request.