1Open the Test panel
Click TEST in the right activity bar
The right activity bar has a TEST tab. Click it (or use the toolbar Test icon) to open the test panel. The panel has three modes — Workflow, Node, and Pin — selectable from a small tab strip at the top.
What's the difference vs RUN?
- TEST is for in-canvas, dev-time runs while you're authoring. Outputs land in the test panel; nothing goes to the production audit trail.
- RUN is the real Workflow Runner — it's the same execution path callers will use, runs are recorded, and notifications fire as configured.
2Run to a target node
Right-click any node → Run to this node
The workflow runs from Start, taking the actual edges and conditions, until control reaches the chosen node. The chosen node becomes the stopping point — its inputs are visible but it does not execute.
Use this to confirm that upstream branching produces the right inputs for a downstream node before you trust it to run.
Provide test inputs
The test panel shows an Inputs JSON editor pre-filled with the workflow's declared input schema. Edit the values for this run; they don't change the saved workflow.
If any upstream node has a pinned output, the test will use the pin instead of re-calling the system. This makes "run to node" deterministic and fast.
3Isolated node test
Right-click → Test node
Test node executes only the selected node, with inputs you provide directly. Nothing upstream runs. This is the fastest way to debug a single system call or expression.
Useful when:
- You're not sure if a connector is configured correctly.
- You want to verify a parameter expression compiles.
- You want to exercise a connector with a specific payload that's hard to reach via the normal flow.
Read the result
The output appears in the test panel as a JSON tree, with timing and status. Errors show with the connector's response body so you can see what the upstream system returned.
4Pin a node output
A pin is a saved input or output for a single node. When pinned, the node returns the saved value during tests instead of calling the real system. Pins are kept per workflow and survive reloads.
Manual pin from a result
After a test or run, right-click the node and choose Pin output. The current output is saved as the pin. The node now shows a 📌 badge.
Record mode
Open the PINS panel and toggle Record mode on. Run the workflow once; every node's output is captured automatically as a pin. Turn record off and you have a full set of replayable pins for offline development.
Manage input pins
Right-click a node → Manage input pins. You can pin specific input values too — handy when one parameter changes per run but the rest are stable.
Unpin to use real values
Open the PINS panel, find the node row, and click Unpin. Or right-click the node → Unpin.
The Workflow Runner ignores pins. Pins are a development-time convenience — production runs always call the real systems.
5The Workflow Runner
Open it
Three ways:
- ▶ Execute on a workflow card in the gallery.
- Execute button on the canvas top toolbar.
- RUN tab on the right activity bar (opens the runner inline).
Provide inputs and start
{
"first_name": "Jane",
"last_name": "Doe",
"department": "Engineering",
"manager_id": "u_3a8b91"
}
Closing the runner doesn't stop the run
Once started, the run executes server-side. Closing the modal only hides the live view — the workflow keeps running. Re-open the runner from the same workflow to attach again.
6Watching the execution overlay
Live status on the canvas
While a run is in progress, the canvas overlays each node with its real-time status: queued, running, success, failed, skipped, waiting-for-input. Edges fade or pulse to show the path being taken.
Click a node to see its actual data
Click any executed node and the right panel shows the inputs and outputs of this run. The DATA panel switches automatically to last-run mode.
Toggle the last-run overlay
The floating-actions stack on the bottom-right of the canvas has a last-run overlay button. Toggle it off to see the clean graph; toggle it on to see status colours from the most recent run, even after it finished.
7Completing a paused human step
What pauses look like
When the engine reaches a User Interaction node, the run pauses with status waiting-for-input. The node turns amber on the canvas; the timeline shows ⏸. The runner header switches to ● paused — awaiting input.
Open the pending form
The right panel shows the Pending Tasks view with one row per outstanding human step. Click the row to open the form; fill the fields; submit.
Configured channels (email, Slack, Teams) receive a notification with a link to the form. The recipient does not need to be inside Orchestration Studio to complete the step.
8Resume after input
Submit advances the run
Once the form is submitted, the engine resumes from the User Interaction node. The submission becomes the node's output and downstream nodes start.
If you cancel
The form's Cancel ends the run with status cancelled. The timeline marks the node skipped; downstream nodes never run. This is recorded in the audit trail.
Long-running runs
A run can stay paused for hours or days. Close the runner; the workflow remains queued. Re-open from the gallery's Runs tab (or the workflow card menu) to resume monitoring.
9Console / Problems / Timeline
The bottom IDE panel has three tabs that surface what happened during a run.
| Tab | Contents |
|---|---|
| Console | Streaming log lines from the engine and any Log nodes you used. Filter by level (info / warn / error). Use the Clear button between runs. |
| Problems | Validation issues that need fixing before the workflow can execute cleanly: missing required parameters, dangling edges, expression errors. Clicking a row jumps to the offending node or edge. |
| Timeline | Per-node duration breakdown for the most recent run. Useful to identify slow nodes; hover for exact start/end timestamps. |
Press Ctrl + ` to show / hide the bottom panel, the same way an IDE does.