Test a node and publish a workflow
Run a single node against real input, clear publish-gate validation errors, and publish a workflow version so it goes live.
Goal
Confirm one node works in isolation, fix the validation errors that block publishing, and publish the workflow version. A published version that reaches the Active status receives live events.
When to use this
Reach for this page when you have built a workflow in the editor and you are ready to take it from draft to live. Use it to:
- Spot-check a single step before you publish the whole workflow.
- Read and clear the errors the editor shows when you press Publish.
- Understand what "published" actually means and which version receives events.
If your workflow is published but no runs are starting, see No data coming in instead. For the full list of validation messages and how to clear each one, see Fix publish errors.
Test a single node
Every node's configuration panel has a test button. The label matches the node: Test node and Test trigger on a trigger, Test action on an app action, Test loop on a loop, Test switch on a switch, and so on. The test runs the step for real against your input. It is not a simulation.
Testing is gated. The button stays disabled until the node is valid. A switch with no selector, for example, shows the tooltip Configure a selector and at least one valid case before testing. An action that is missing its app, definition, connection, or config shows Configure the action (app, definition, connection, and config) before testing. Finish configuring the node first, then test.
Open the node and supply input
Select the node on the canvas to open its configuration panel. For most nodes the test uses an object you type into the Input pane (an empty object
{}if you type nothing). A webhook trigger defaults to a small sample payload of the shape{ "data": { "test": true, "timestamp": "<ISO timestamp>" } }, so you can test it without wiring up the real source.Run the test
Press the test button. TaskJuice runs the step against your input and against the output of any upstream node you have already tested. AI nodes stream their output as it is produced. The result appears in the panel's Output pane.
Read the result
A successful test shows the node's output. A failed test shows the error message and detail. Either way, the output is now pinned to the node.
When you test a node, its output is pinned. Pinned output is what feeds the reference picker
downstream, so testing an upstream node first is how you get real field paths (such as
$steps.action1.data.id) to appear when you map data into a later node. See Map data between
nodes.
Fix publish-gate validation errors
When you publish, TaskJuice validates the whole workflow graph before it compiles. Errors block the publish; warnings do not. The editor shows the blocking messages in a toast titled Failed to publish workflow, with the specific reason as the description.
These are the rules you are most likely to hit, with the exact message and the fix.
| Error message | Why it fires | Fix |
|---|---|---|
Workflow must include at least one trigger node | The workflow has no trigger. | Add a trigger as the first node. |
Node <id> is not connected to the workflow | A node has no path back to a starting node. | Connect it with an edge, or delete it. |
Node must have incoming edges | A non-trigger node has nothing feeding into it. | Draw an edge from an upstream node. |
Trigger requires an account connection | A trigger needs an account connection and none is set. | Open the trigger and select a connection. |
Action node authentication not hooked up. | An action that needs auth has no connection. | Open the action and select a connection. |
Trigger node has an inactive connection / Action node has an inactive connection | The selected connection is not active (for example, it needs reauthorization). | Reconnect the integration, then try again. See Reconnect an integration. |
Branch node must have at least 2 conditions | A branch has fewer than two conditions. | Add conditions until you have at least two (the maximum is eight). |
Switch node must have a selector expression | A switch has no selector. | Enter a selector expression and at least one case. |
Loop node has no incoming edges and will never be executed | A loop is not reachable. | Connect an upstream node into the loop. |
Parallel node must have at least 2 branches | A parallel node has fewer than two branches. | Add branches until you have at least two. |
Duplicate node name: "<name>" | Two nodes share a name. This is a warning, not a blocker. | Rename one of the nodes if you want to clear it. |
A separate gate checks forms. If any node references a form whose status is not published (it is draft, archived, or missing), the publish is blocked with the toast Some referenced forms are not published. The description names the offending node, for example Node "form-1" references a draft form and 1 other node. Publish the form (or remove the node) and try again. Publish the referenced form, or remove the node, then try again.
For the complete rule set and every message string, see Fix publish errors.
Publish the version
Once the graph validates, you are ready to publish. The Publish button (rocket icon) appears in the editor header for draft versions. When the draft has no unsaved changes and has pending changes to ship, the header also shows a blue Ready to publish badge.
Save your changes
The Save button is disabled unless you have unsaved edits, shown by the amber
Unsaved changesbadge. Save first so what you publish matches what you see.Press Publish
Press Publish. The button label changes to
Publishing...while TaskJuice compiles the version. You cannot publish a version that is already compiling or evaluating: that returns the messageWorkflow version is currently compiling. Please wait.Confirm it went live
On success you see the toast
Workflow published successfully, and the version moves toward the Active status. An active version receives live events. If queued client connection requests existed for the workflow, publishing dispatches them and the toast reports how many were sent.
You can publish from the Draft, Inactive, Failed, and Eval failed statuses. Publishing a version that is already Active returns Workflow version is already published and active. For how versions move between these statuses and how to swap the live version, see How workflow versions work.
Verify it worked
You have published successfully when all three of these are true:
- The success toast
Workflow published successfullyappeared. - The version status reads Active in the editor.
- The Run button in the header is enabled. It is disabled unless the current version is active, so an enabled Run button is a reliable signal that the version is live.
Troubleshooting
If the graph passes validation but the publish still fails, the version status becomes Failed
and the toast Failed to publish workflow (or Workflow compilation failed) shows the reason as
its description. Read that description, correct the named issue, and publish again. A version in
Failed is publishable, so you do not need to start over.
A few specific cases worth knowing:
- An OAuth scope needs a client you have not set up. The editor shows
BYOC OAuth client requiredwith an Open BYOC settings action. Open BYOC settings to provide the client, then publish. - A client-provided credential is missing. The editor shows
Client connection requests are not readywith an Open Client requests action. Send the outstanding request from the Client requests sidebar, wait for the client to authorize, then publish. - The Run button stays disabled after publishing. The version is not yet Active. Check the version status badge; if it is Compiling or Evaluating, wait for it to finish.
Related
- Fix publish errors: every validation message and how to clear it.
- How workflow versions work: the draft-to-active lifecycle and swapping the live version.
- No data coming in: published but no runs are starting.