Skip to main content
The Console lets you test a workflow during development by running it directly in the canvas with real input and inspecting each block’s output — no production deploy needed. It’s the fastest feedback loop you have while building, and the primary tool for catching problems before they reach real users.

​
Opening the Console

In the workflow canvas, click the play icon (▶) in the top toolbar. The Console opens on the right side of Studio so you can see your workflow and its output at the same time. Type or paste an input payload, click Run, and watch each block execute in order.

​
What the Console Shows You

Running a workflow in the Console gives you a full picture of the execution:
  • Input payload — the JSON you submitted, so you can verify its shape
  • Block-by-block output — each block’s result in order, revealing exactly where data transforms or breaks
  • Final output — the complete response your workflow returns
  • Timing per block — how long each block took, helpful for catching slow LLM or API calls
  • Errors — failure messages and which block triggered them
The Console is built for live, interactive development testing. Logs display historical production runs instead. Reach for the Console when you’re actively building; reach for Logs when you’re triaging what already happened in production.

​
What to Check in Each Test Run

Run these four checks before moving on from a test:
  1. Input payload shape — confirm the input matches what your blocks expect. Mismatched field names cause silent downstream failures.
  2. Block-by-block output — review each block. Empty or null results where you expected content show you exactly where to investigate.
  3. Final output schema — verify the last block returns the fields your consumer needs, especially if you’re exposing the workflow as a tool.
  4. Errors and timing — watch for error statuses, and check timing. A slow LLM block may signal a prompt or model config problem.

​
The Debug Loop

When something is wrong, work through this cycle to isolate and fix it:
  1. Run with realistic input — use data that resembles real users, not a toy example
  2. Inspect the first failing or noisy block — click into its output to see what went in and what came out
  3. Fix the block config or template — adjust the prompt, logic, or field reference
  4. Re-run with the same input — verify the fix addresses the broken case
  5. Re-run with edge-case input — test empty strings, missing fields, or odd formats
If the same input fails in the Console but succeeds in production Logs, check your environment — config values like API keys, model selection, or variables may differ between development and production.

​
Console Tips

Keep a test payload library

Save reusable JSON snippets — happy path, empty input, unusual characters — so you can re-run them after every change and catch regressions early.

Test failure paths

Pass missing required fields or unexpected values so your error-handling blocks actually get exercised, not just the success path.

Validate output field names

When a workflow is used as a tool in Copilot or via the API, output field names form part of your contract. Rename them here, not after deploy.

Run after every edit

A quick Console run after a prompt or logic change takes ten seconds and saves debugging a production incident later.

​
Next Steps

Logs

Analyze production run history and triage failures after they happen.

Environments

Understand how development and production config differences affect runs.

Running Workflows

Run workflows from the REST API or SDKs once they’re ready for production.

Blocks

Understand block types and their failure modes to debug traces faster.