Console

Console is the fastest way to test a workflow while you build. Instead of deploying to production to see what happens, you run the workflow right in the canvas with real input and inspect every block’s output in seconds.

Open Console

In the workflow canvas, click the play icon (▶) in the top toolbar to open Console. It slides in on the right side of the canvas so you can see your workflow and its output at the same time.

What Console Shows You

When you run a workflow in Console, you get:

• Input payload — the exact JSON you sent in, so you can confirm it’s shaped correctly
• Block-by-block output — each block’s result in order, so you can see exactly where data transforms or breaks
• Final output — the full response your workflow returns
• Timing per block — how long each block took, useful for spotting slow LLM calls or external API requests
• Errors — if a block fails, Console shows the error message and which block threw it

This is different from Logs, which shows historical production runs. Console is for live, interactive testing during development.

What to Check in Each Test Run

Run through these four checks before moving on:

1. Input payload shape — does the input match what your blocks expect? A misnamed field here causes silent failures downstream.
2. Block-by-block output — scan each block’s output. If a block returns an empty string or null when you expected content, that’s where to dig.
3. Final output schema — does the last block return the fields your consumer expects? If you’re exposing this workflow as a tool, the output field names matter.
4. Errors and timing — look for any error status on a block. Check timing if the run feels slow — a single LLM block taking 10s vs 2s often points to a prompt or model config issue.

Debug Loop

When something’s off, use this cycle to isolate and fix it fast:

1. Run with realistic input — use a payload that mirrors real user data, not a toy example
2. Inspect the first failing or noisy block — click into the block output in Console to see exactly what it received and returned
3. Fix the block config or template — tweak the prompt, logic condition, or field reference based on what you saw
4. Re-run with the same input — confirm the fix works for the case that broke
5. Re-run with edge-case input — test an empty string, a missing field, or an unexpected format to make sure you didn’t just paper over the problem

If the same input fails in Console but works in production Logs, check your environment — you may be testing against different config values.

Console Tips

• Keep a small library of test payloads. Save a few JSON snippets (happy path, empty input, unusual characters) somewhere handy. Reusing them across sessions catches regressions before they reach production.
• Test failure paths, not just success. Pass in a missing required field or a value the workflow doesn’t expect. Your error-handling blocks need coverage too.
• Validate output field names before shipping. If you’re using this workflow as a tool in Copilot or calling it from the API, the output field names are part of your contract. Rename them in Console, not after deploy.
• Use Console after every non-trivial edit. A quick run after changing a prompt or logic condition takes 10 seconds and saves debugging a production incident later.

Next Steps

• Logs: Analyze production run history and triage failures
• History: Track what changed between revisions and find when a regression was introduced
• Running Workflows: Run workflows from the API or SDK for production systems

Built with ❤️ by Scout OS