# Workflow Testing and Execution History
URL: /response-workflows/testing-and-history
Type: howto
Description: Test a response workflow against a real Zendesk ticket, review saved executions, and debug failures or escalations.
Keywords: testing, execution history, debug, zendesk ticket
Use the test panel to check a response workflow against a real Zendesk ticket before you publish changes widely. Then use execution history to review saved runs, inspect failures, and see the exact input, output, and metadata recorded for that workflow.

{/* TODO(docs): Screenshot of the response workflow editor showing the Test Panel and the Executions button. Tracked in public/images/README.md. */}

When to use each tool [#when-to-use-each-tool]

Use the two surfaces for different jobs:

* **Test Panel** for rapid validation while you are editing a workflow
* **Execution History** for reviewing saved workflow runs after the workflow has been used

The test panel is temporary. Execution history is recorded.

Run a test from the editor [#run-a-test-from-the-editor]

Open the workflow editor and use the **Test Panel** at the bottom of the page.

1. Enter a Zendesk ticket ID.
2. Select **Run Test**.
3. Review the returned result before you save or publish.

The test uses the current editor state, including unsaved changes. That means you can test strategy instructions, template edits, tools, escalation rules, and knowledge base selections before you publish a new version.

What the test panel shows [#what-the-test-panel-shows]

After a test run, Stylo can show:

* A generated response when no escalation rule blocks the run
* An escalation result with the matched rule reason
* Tool output for any tool calls used during the test
* Response mode as `template`, `guided`, or `hybrid`
* Model and token usage details when available
* Run time in milliseconds
* The count of unresolved placeholders

{/* TODO(docs): GIF of running a response workflow test and reviewing the result panels. Tracked in public/images/README.md. */}

What the test panel does not do [#what-the-test-panel-does-not-do]

The test panel is designed for editing, not production tracking.

* It does not save an execution record to history
* It does not require you to save the draft first
* It does not publish a new workflow version
* It depends on Zendesk being connected and on a real ticket being available

If Zendesk is not connected, the test request fails. If the ticket ID is invalid or the ticket cannot be loaded, the test also fails.

Use execution history [#use-execution-history]

Select **Executions** from the workflow editor header to open the saved run history for that workflow.

Execution history helps you answer questions like:

* Did this workflow succeed, fail, or remain pending?
* What trigger started the run?
* What input and output were recorded?
* Was there an error message?
* How long did the run take?

The history page lists the most recent executions first.

What each execution record includes [#what-each-execution-record-includes]

Each execution row shows a compact summary first, then expands to reveal the recorded payloads.

* Status such as `pending`, `running`, `succeeded`, or `failed`
* The created time
* The trigger that started the run
* The user ID for the person who started it, when present
* Duration when timing metadata is available
* Error text for failed runs
* Recorded `input`, `output`, and `metadata` JSON when you expand the row

Limits and boundaries [#limits-and-boundaries]

Keep these operational limits in mind:

* Execution history is permission-gated. Users without execution history access cannot view it.
* The response workflow history view shows the most recent 50 executions for that workflow.
* The current response workflow history page is a list view with expandable JSON. It does not provide a separate execution detail page like the broader workflow builder.

Recommended review workflow [#recommended-review-workflow]

Use this sequence when you change a workflow:

1. Run the test panel against one or more representative Zendesk tickets.
2. Fix any escalations, placeholder gaps, or tool output problems.
3. Save and publish the workflow when the result is acceptable.
4. Monitor **Executions** after real usage begins.
5. Open failed or unexpected runs and inspect the stored input, output, and metadata.

Related [#related]

* [Creating a Workflow](/response-workflows/creating-a-workflow) to build the workflow before testing
* [Workflow Editor](/response-workflows/workflow-editor) to understand where editing controls live
* [Escalation Rules](/response-workflows/escalation-rules) to tighten workflow guardrails
* [Background Automation](/response-workflows/background-automation) to understand the higher-risk execution path