Skip to main content
Testing a workflow means sending a real event through its configured trigger, then inspecting what each action received and produced. WorkflowDog does not currently have a generic Test Run button.

​
The test loop

1

Save the graph and trigger

Finish the change, save any open trigger configuration, and wait until the editor header says Saved!. Sending an event earlier can start a run from the previous graph.
2

Enable the workflow

A paused workflow does not accept new trigger events. Follow Enable and pause if the workflow is not live.
3

Send one representative event

Cause the event the trigger is designed to receive. Use realistic values, including optional fields and attachments that matter to the automation.
4

Inspect the run

Open the workflow’s runs, select the new run, and inspect trigger data, action outputs, and node errors.
5

Change one thing and repeat

Deselect the historical run, edit the current graph, wait for Saved, and send another event. Compare the new result with the expected outcome.

​
Send the right event

For HTTP request formats and response behavior, see HTTP endpoints and webhooks. For provider account and filter setup, see Service triggers.

​
Inspect more than the final result

A correct final value can hide a broken branch that happened not to affect this event. Check:
  • the Data from Trigger outputs,
  • each action that should have run,
  • values on output handles,
  • node-level errors,
  • branches intentionally skipped by conditions, and
  • side effects in the destination service.
Actions on independent branches can run concurrently. Do not use their visual left-to-right order as evidence that one finished before the other. Add a data connection or Wait For dependency when order matters. Historical runs keep the graph snapshot used when they started. Use that snapshot to understand an old result; use the current graph for the next test. See Workflow runs and Troubleshooting runs for the detailed inspection workflow.

​
Reuse an event after the first test

After you have one representative run, Rerun can reuse its trigger payload against the workflow’s current saved graph. This is useful when repeatedly tuning transformations or branch logic.
Rerun repeats the stored trigger data; it does not recreate the external event. It may repeat side effects such as sending messages, creating rows, or calling APIs. Disable or isolate destructive actions before using it as a tight test loop.

​
Test the unhappy paths

Before relying on the workflow, send cases that exercise its boundaries:
  • a missing optional field,
  • an empty list,
  • a value in the wrong format,
  • a false condition,
  • an expired or disconnected service account, and
  • a downstream service error.
An action error stops dependent actions from receiving its normal outputs, but independent branches can continue. Use Meta controls when the workflow should recover, report, or clean up after a failed action.