Testing and run history

Before an automation works for your members, you want to see it work for you. A test run starts it once on demand. The run history then shows every run, real or test, step by step, so you can see what happened and why a run failed.

Open Automations

What a test run really does

A test run is not a simulation. It runs the automation once, right away:

• Actions really execute. Emails go out, tags, groups and course access change, and webhooks and external requests are sent. Test with your own account or a test member, not with a real customer.
• It uses the latest saved version, even if you have not published it yet. Real events keep using the published version until you publish.
• It also works while the automation is switched off.
• When the flow reaches a Delay or Wait until date step, the test run waits like a real run. The remaining steps run for real once the wait is over.
• A Run workflow step starts the other automation for real. That run shows up in the other automation's run history with the source Automatic.
• Every integration the flow uses must be connected. Otherwise the test stops with "Connect these integrations first:" and the missing names.

Test runs do not count in the list: Last run, Runs (7d), Success (7d) and the Failed view ignore them. A failed test does not mark your automation as failed.

Building an automation

Starting a test run from the list

Open the menu of an automation in the list and choose Test run. The dialog explains: "Runs the current draft once with an empty test payload. Actions really execute." This test starts without trigger data and without a member. It suits a quick check. To test with a member or your own data, start the test in the editor.

If the automation has several triggers, pick one under Start from trigger. Then click Start test run. The result appears in the same dialog:

• Test run completed, with the duration.
• Test run is waiting at a delay or wait step when the flow paused at a Delay or Wait until date step. The rest follows later.
• Test run failed, with the error message of the run.

Run again starts another test. If the automation has no trigger, the dialog shows "This automation has no trigger to start from."

Starting a test run in the editor

Click Test run in the editor header. The dialog offers more control:

• If you have unsaved changes, a note says "Your unsaved changes are saved before the test run." The test saves first and then starts. If saving fails, the test does not start.
• With one trigger, the dialog names it. With several, choose one under Trigger node.
• Payload (JSON) is the data the trigger would deliver. It starts as {}. Enter the fields your steps read, for example the field a condition checks or a placeholder like {{order_id}} uses: {"order_id": 1042, "amount": 4900}. While the text is not valid JSON, the dialog shows "Payload must be valid JSON." and does not run.
• Member UUID (optional) is the member the run is about. Actions that work on a member, for example adding a tag or granting a course, need one. Leave it empty for flows without a member, such as a schedule or a webhook. You find the UUID at the end of the web address when you open the member in the admin area. An unknown UUID stops the test with "This member was not found in this business."

Click Run. The dialog closes, the run history opens and the canvas shows the new run.

These messages stop a test before it starts:

• "Save the automation once before you start a test run."
• "Add a trigger and save before you start a test run."
• "This trigger is not in the saved version yet. Save, then try again."
• "Drop a trigger node on the canvas first. Test runs always start from a trigger."

The run history

Click Run history in the editor header. The button works once the automation is saved. The panel lists the 50 most recent runs that match your filters, newest first, and refreshes every few seconds. Each entry shows the status, the source, the trigger, when the run started and, once it is finished, how long it took. For a waiting run, it also shows when it resumes.

Status

• Running: the run is in progress.
• Waiting: the run waits at a Delay or Wait until date step. The entry shows Resumes with the date and time in your local time when it continues. If several paths wait, it is the earliest time.
• Completed: the run reached its end.
• Failed: a step failed or the run hit a limit. Open the run to see why.
• Cancelled: the run was waiting and was stopped because the automation was switched off, archived or deleted. More on this further down.

Source

• Automatic: something in your platform started the run, for example a new member or an order. Runs started by a Run workflow step of another automation also show this source.
• Scheduler: the platform's clock started the run. This covers the triggers On a schedule (cron), Member inactive, Event starting soon and Renewal due soon.
• Manual: a test run or a replay.
• Webhook: an incoming webhook or a call from an external service.
• Other: any other start.

Filters

Above the list you can filter by status (Any status), by source (Any source) and by a start date and time under Since. There is no separate status filter for waiting runs: they appear under Running. Clear resets all filters and shows how many are active. When nothing matches, the panel says "No runs match these filters." with a link Show all runs. Before the first run it says "No runs yet. Hit Test run to fire one."

Looking at a run

Click a run in the list. The canvas switches to that run and shows the flow as it was in the version the run used. A banner at the top shows when the run started, its status and "Canvas is read-only." You cannot edit while you look at a run. Exit replay brings back your current draft.

Every step the run reached gets a coloured ring and a small badge:

• Green: Completed.
• Red: Failed.
• Blue: Running.
• Purple with an hourglass: Waiting. The step is a Delay or Wait until date step and the run continues later.
• Grey: Skipped. The step was passed over, for example because a filter stopped this path or the run was cancelled during the wait.

Steps without a ring were not reached.

Click a step to open it in the panel on the right. Settings shows its configuration, read-only. Run shows what happened:

• Status, Started and Finished. A waiting step shows Resumes with the time the run continues.
• Input and Output: the data the step received and passed on.
• A red box with the error if the step failed. Show stack trace opens technical details you can send to support.
• A yellow Note on a completed step means the step ran but changed nothing, for example "The member already has this badge."

A step the run never reached says "This node was not reached during the run." If the whole run failed, the banner also shows the error of the run in red.

Replaying a run

Replay in the banner starts the run again. After the question Replay this run? the dialog warns: "Runs the current draft again with the same payload. Actions really execute." The replay uses the same trigger data and the same member as the original run, but the latest saved version of your flow. That makes it the quickest way to check a fix: find the failed run, correct the step, save, replay.

The replay is a new run with the source Manual, and the canvas switches to it right away. If you replaced the trigger since the original run, the replay stops with "The trigger of this run no longer exists in the current version. Start a new test run instead."

Spotting failures in the list

You do not have to open every automation to find problems. The list shows them, based on real runs only:

• The view Failed next to your folders lists every automation whose last run failed. When there is none, it shows No failed automations.
• The column Last run shows Never, or the time of the last run with a coloured dot: green for completed, blue for running, grey for cancelled. A failed last run appears as a red badge with the tooltip Last run failed.
• Success (7d) is the share of completed runs among the finished runs of the last seven days. Runs still in progress do not count. Failed and cancelled runs lower it. Runs (7d) counts all runs of the last seven days and is hidden by default.
• The filter Last run status finds automations by Completed, Failed, Running, Cancelled or Never.

From there, open the automation, open Run history, filter by Failed and click the run to see which step failed and why.

Activity: who changed what

Activity in the menu of an automation lists its last 50 changes, each with the person and the time: Created, Saved, Published, Rolled back, Enabled, Disabled, Archived, Unarchived, Deleted, Duplicated, Imported for an automation made from a template, and Webhook secret rotated. Changes made for several automations at once appear in each of them. Test runs and replays are not part of the activity; you find them in the run history. A new automation without changes shows "No activity yet."

Automations overview

What happens to waiting runs

A run that waits at a Delay or Wait until date step checks the automation again when the wait is over:

• Switched off: a real run that comes due while the automation is off is cancelled. Its remaining steps do not run. If you switch the automation back on before the wait ends, the run continues normally. Test runs and replays continue even while the automation is off.
• Archived: the run is cancelled, test runs included. Archiving also switches the automation off.
• Deleted: the run is cancelled.
• New version published: a run that has already started finishes with the version it started with. Only runs that start after publishing use the new version. The same applies to a rollback.

A cancelled run shows Cancelled in the run history, and its waiting step turns to Skipped. The error of the run says why: "The automation was paused while the run was waiting.", or the same with archived or deleted.

Conditions, branches and delays

How long runs are kept

The run history keeps runs for 90 days. Once a day, older runs are deleted together with the input and output of their steps. Runs that are still waiting are kept until they are finished.

Common errors and what they mean

Issues the editor flags

The editor marks steps with problems before you run anything. Saving still works, but the automation may not behave as you expect:

• "Trigger has no event type selected.": choose what the trigger reacts to.
• "Trigger should not have an incoming edge.": a trigger always starts the flow. Remove the connection that leads into it.
• "Action has no type selected.": pick what the action does.
• "Action needs an integration but none is picked." and "Required integration is not connected.": connect the service under Integrations and select the connection in the step.
• "Days inactive must be 1 or more.", "Days before renewal must be 1 or more." and "Hours before start must be 1 or more.": the triggers Member inactive, Renewal due soon and Event starting soon never start without this number. Enter a whole number of 1 or more.
• "Delay has no duration.": enter a duration greater than zero.
• "Run workflow has no workflow selected.": pick the automation the step should start.
• "No incoming edge. This node is unreachable.": connect the step to the flow or delete it.
• "Graph has no trigger node.": add a trigger.
• "Respond to webhook runs after a delay or wait step. The webhook caller gets the default reply instead.": move the reply before the wait.

Errors in a failed run

The error of a failed run names the step and its type, for example "Step "Send Email" (Action) failed." or "Step "Send Email" (Action) stopped with an error.", followed by the reason. Triggers and actions appear with their name from the library, all other steps with the name shown on the canvas. Click the red step on the canvas to read the full message. These errors appear in the default language of your platform, also for test runs and replays. Frequent causes:

• "… stopped with an error.": the step ran into an error, often an external service that rejected the request or a connection that needs to be renewed.
• "The request returned HTTP …", "The request could not be sent: …" or "The URL "…" is not valid or not allowed.": a Make External Request step got an error from your server, no answer in time, a redirect, or an address it may not call.
• "The workflow to run was not found.", "The workflow to run has no published version." or "The workflow to run has no trigger.": the automation a Run workflow step starts was deleted, never published or has no trigger.
• "A workflow cannot run itself." and "Workflows are nested too deeply (at most 5 levels).": Run workflow steps call each other in a circle or too deeply.
• "The workflow "…" failed.": the other automation failed. Look at its own run history.
• "The step limit of 500 was reached.": a run executes at most 500 steps in one go. This usually comes from a loop over a long list with several steps inside.
• "The run took too long and was stopped.": the run took longer than the platform allows, for example because an external service answered too slowly.

Notes on completed steps

A yellow note marks a step that completed without doing its job:

• "No member of this business could be resolved for this run.": the run has no member. Test again with a Member UUID (optional), or check whether the member was deleted during a wait.
• "The configured course no longer exists.", or the same for a group or a badge: choose a new one in the step.
• "The course is not published, so no access was granted.": publish the course first.
• "No date found in "…". The flow continued without waiting." or "The date "…" could not be read. The flow continued without waiting.": a Wait until date step found no usable date and continued without waiting.
• "The workflow "…" is paused. The flow continued without it.": switch on the automation that the Run workflow step starts.

Not every action leaves a note. If a member step shows Completed but nothing changed, check whether the run had a member under Input.