Outputs and results

A Workflow run produces one output per step, and one result for the run. This page explains what that result is, which values become reviewable attributes, and how to get them out: in the result pane, in Debug, in a Workstation App, through the API and in Test Cases.

What a run returns

Every step that runs stores its output. The result of the run is the output of the last step that ran on the path the run took: in the running example, the escalation note for a high-value contract, or the generated letter for the others.

Step	Output
AI Module with Output Format	an object with the attributes
AI Module without Output Format	a text
Classifier	`answers` keyed by question ID, with probabilities
Condition	the name of the matched case, or `Default`
Split, Crop	a list of files with their page info
Map	a list, one entry per item, with the inner steps’ outputs; each inner step also exposes its list
Code Execution	whatever `execute` returned
Existing Canvas, Existing Agent	the Canvas or Agent output
Generate Document	`generatedDocument` and, optionally, a permalink
Stop	nothing

What becomes reviewable

When a Workflow runs in Test or in a Workstation App, people review the result attribute by attribute: a thumbs up or down on each field. Those attributes come from the Output Formats of the steps: each AI Module with an Output Format, each Existing Canvas whose Canvas has an Output Format, contributes its attributes under the step’s name (the UI calls this “N attributes from Step N”). Steps without a structured output (plain-text AI Modules, Code Execution, document steps) show their output but do not give reviewers fixed attributes to judge.

Decide early which values a reviewer must check and make sure they are attributes of an Output Format somewhere in the Workflow. If the final value is computed by Code Execution, add an AI Module or keep the attribute in an earlier step’s Output Format so it stays reviewable.

For developers: a Workflow saved through the API can also declare an explicit outputs map (field name → type and the step reference it comes from), which is what the run returns and what a Test Case result makes reviewable. In the editor there is no separate outputs panel: the steps themselves define the outputs, and the last step defines the final result.

In the result pane

After Run, the right-hand pane shows the run while it progresses and, when it finishes, two tabs:

Preview: the Workflow Status (Completed, Failed, Cancelled, Timed out) and one collapsible section per step with its status (Completed, Failed, Skipped for branches not taken, Waiting To Run) and its output. Structured outputs show as fields, files show with a preview you can open full screen, code outputs show the returned value, and a Map shows its iterations with previous/next controls. Errors appear in the failed step’s section.
Debug: the cost (in dollars or credits), duration, input and output tokens, the completion and request IDs, the dates and who started the run, and an Execution timeline with the detail of each step.

Result pane after a run, Preview tab, with the Extract Data section expanded and the Approval Letter file

Clear Preview empties the pane without deleting anything: the run stays in Debug and Usage.

The Debug tab loads the timeline a few seconds after the run ends. Missing cost or token figures appear as - rather than zero.

In the Debug experience

The Debug experience lists every run of the Workflow, from Craft, Test Cases, the Workstation, the API and schedules, with Status, Source, Started, Duration and Version. Filter by status, source, version, author or date range, then select a run. For a run you get:

an Execution overview: run ID, version, source, how many nodes completed, the Inputs it received and the run’s output;
a Graph and a Timeline view of the steps;
a node inspector for each step with Input, Output, Error and Metadata; for AI steps, the prompt as sent and the Expected output; for Code Execution, the Terminal; for a Condition, which case Matched and the Referenced values; for a Map, the Iterations with Open iteration as run.
Run actions: Re-run the same version with these inputs (editable before running), Edit in Craft (opens Craft on the latest version with this run’s inputs filled in) or View in Craft (opens the run read-only).

Debug experience with the executions table and one run selected, showing the node inspector

Opening a run from Debug in Craft puts the editor in read-only mode with a banner (“Viewing workflow run. Editing disabled.”); Return to editing leaves it, and Edit from this run restores the version that ran as the one you edit.

In a Workstation App

When you publish with Deploy App, your team runs the Workflow from a Workstation: each input they send becomes a task. A task runs the Workflow once, then waits in Pending Review with the result laid out for approval.

Reviewers see the reviewable attributes described above, can edit values, and Approve the task. Generated files are available to download.
Approved tasks can be downloaded as CSV or JSON and turned into Test Cases.
Through the Tasks API, a Workflow task’s outputContent wraps { response, stepOutputs, error? }: response is the run’s result and stepOutputs the output of every step by name. See Creating tasks via API.

A Workstation App currently exposes one variable. A Workflow with several Inputs can still be deployed, but check how the App maps them before relying on it.

Through the API

Two APIs give you results from your own systems.

The Completion API

Running a published Workflow with POST /v2/chat/completions works like a Canvas: canvas_id is the Workflow ID from Connect via API, variables carries the Inputs, and choices[0].message.content carries the Workflow response when the run finishes. Use async: true or webhook_url for long runs. See Completion API overview and Async and webhooks.

The Workflow Run API

To read every step, use the Workflow Run endpoints:

GET /workflow/runs?promptId=<workflow id> lists runs, newest first. Filter with status (pending, running, completed, failed, cancelled), environment (craft-preview, test-case, workstation, api), promptVersionId, and rootOnly=true to hide the child runs created by Map iterations.
GET /workflow/runs/{id} returns one run with its steps and the executed graph. id is the run ID, or the external execution ID you received when you started the run through the API.
POST /workflow/runs/{id}/cancel cancels a run that is still active.

cURL

curl "https://api.tela.com/workflow/runs?promptId=9d2e4f6a-1b3c-4d5e-8f70-1a2b3c4d5e6f&status=completed&rootOnly=true&limit=20" \
    -H "Authorization: Bearer $TELA_API_KEY"

A run looks like this:

{
  "id": "exec_01J9Z8Q4M6N2P8R1S3T5V7W9X",
  "promptVersionId": "9d2e4f6a-1b3c-4d5e-8f70-1a2b3c4d5e6f",
  "environment": "api",
  "status": "completed",
  "startedAt": "2026-09-01T12:00:00.000Z",
  "completedAt": "2026-09-01T12:00:08.412Z",
  "input": {
    "contract": { "name": "contract", "type": "file", "required": true, "files": [{ "name": "acme.pdf", "mimeType": "application/pdf", "fileUrl": "vault://files/acme.pdf" }] }
  },
  "steps": [
    { "id": "extract", "name": "Extract Data", "actionId": "llm-completion", "status": "completed", "input": { "...": "..." }, "output": { "counterparty": "Acme Ltd", "total_value": 125000 }, "error": null },
    { "id": "route", "name": "Route by value", "actionId": "condition", "status": "completed", "input": { "...": "..." }, "output": "High value", "error": null },
    { "id": "note", "name": "Draft Escalation Note", "actionId": "llm-completion", "status": "completed", "input": { "...": "..." }, "output": { "note": "..." }, "error": null },
    { "id": "letter", "name": "Approval Letter", "actionId": "document-templater", "status": "skipped", "input": null, "output": null, "error": null }
  ],
  "output": { "id": "note", "name": "Draft Escalation Note", "status": "completed", "output": { "note": "..." }, "error": null, "metadata": {} }
}

steps lists the visible steps in order; steps on branches not taken are skipped.
output is the completed leaf step whose output is the run’s result; null while no leaf step has completed. Its metadata may carry outputFormatMismatch: true when an AI step could not honour its Output Format.
status can be pending, running, completed, failed, requires-action, cancelled, timeout or waiting-for-review. Terminal statuses are completed, failed, cancelled and timeout.
In GET /workflow/runs/{id}, graph.nodes repeats each step with its ports, status and output, and a node that ran inside a Map has a runs array with one entry per iteration (index, status, output, error).

Full parameter details: List workflow runs, Get a workflow run, Cancel a workflow run.

Which field of the Completion API response carries the external execution ID to pass to GET /workflow/runs/{id} is not documented here. When in doubt, list runs by promptId and environment=api and match them by startedAt or by the Inputs.

In Test Cases

In Test, each Test Case runs the Workflow and shows the result with its reviewable attributes, grouped by step. You mark each attribute Good or Bad, add Expected Answers and Wrong Answers that auto-classify future runs, and write Validation Rules in plain language that an AI judge applies on every run. The Score of a version is computed from these reviews. See Validation rules and metrics for how they are evaluated. A Test Case that ran but was never reviewed also shows as completed. Review the attributes before trusting a version; see Running, testing and publishing.

Get started

Build

Test

Operate

Integrate

Outputs and results

What a run returns

What becomes reviewable

In the result pane

In the Debug experience

In a Workstation App

Through the API

The Completion API

The Workflow Run API

In Test Cases

​What a run returns

​What becomes reviewable

​In the result pane

​In the Debug experience

​In a Workstation App

​Through the API

​The Completion API

​The Workflow Run API

​In Test Cases

What a run returns

What becomes reviewable

In the result pane

In the Debug experience

In a Workstation App

Through the API

The Completion API

The Workflow Run API

In Test Cases