---
title: Use the YAML editor
description: Author, test, and run workflows in the Kibana YAML editor, and understand the difference between test runs and production runs.
url: https://www.elastic.co/elastic/docs-builder/docs/4044/explore-analyze/workflows/authoring-techniques/use-yaml-editor
products:
- Elastic Cloud Enterprise
- Elastic Cloud Hosted
- Elastic Cloud Serverless
- Elastic Cloud on Kubernetes
- Elastic Stack
- Kibana
applies_to:
- Elastic Cloud Serverless: Generally available
- Elastic Stack: Generally available since 9.4, Preview in 9.3
---
# Use the YAML editor
The YAML editor is where you author, refine, and run workflow definitions in Kibana. You can write YAML yourself, or start from a [natural language description](https://www.elastic.co/elastic/docs-builder/docs/4044/explore-analyze/workflows/authoring-techniques/use-natural-language) and edit the generated definition here.
To use workflows, you must turn on the feature and ensure your role has the appropriate privileges. Refer to [Set up Workflows](https://www.elastic.co/elastic/docs-builder/docs/4044/explore-analyze/workflows/get-started/setup) for more information.You must also have the appropriate subscription. Refer to the subscription page for [Elastic Cloud](https://www.elastic.co/subscriptions/cloud) and [Elastic Stack/self-managed](https://www.elastic.co/subscriptions) for the breakdown of available features and their associated subscription tiers.
## Editor layout
The editor layout is composed of the following elements:
| Component | Description |
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Editor pane** | The main area for writing and editing workflows. To learn more about the expected workflow structure, refer to [Workflows](https://www.elastic.co/elastic/docs-builder/docs/4044/explore-analyze/workflows). |
| **Actions menu** | A quick-add menu for pre-formatted [triggers](https://www.elastic.co/elastic/docs-builder/docs/4044/explore-analyze/workflows/triggers) and [step types](https://www.elastic.co/elastic/docs-builder/docs/4044/explore-analyze/workflows/steps). Built-in triggers (`manual`, `scheduled`, and `alert`) appear at the top level. Elastic Stack: Generally available since 9.5 Event-driven triggers are grouped by family when a family has more than one trigger, so related triggers such as the cases triggers appear together under a **Cases** group. |
| **Save button** | Saves the current workflow. |
| **Run button** | Manually runs the entire workflow or an individual step. - Entire workflow: Click the **Run** icon `play` (next to **Save**). - Individual step: Select the step in the editor pane, then click the **Run** icon `play`. |
| **Executions tab** | Shows [execution history](https://www.elastic.co/elastic/docs-builder/docs/4044/explore-analyze/workflows/authoring-techniques/monitor-workflows) and real-time logs. |
| **Validation logs** | Shows validation successes and failures. Some common validation errors include: - Invalid YAML syntax because of incorrect indentation or formatting - Missing a required field or property (for example, `name`, `type`) - The step type is unknown or doesn't match a valid action - Invalid template syntax because of malformed template expression. |
When viewing step output in the executions panel, click the **Copy** icon next to a step name to copy its full output path to your clipboard. For example, clicking **Copy** on a step named `check_if_newer` copies `steps.check_if_newer.output.conditionResult`, which you can paste directly into your workflow YAML to reference that step's output.
## Test runs and production runs
Every workflow execution is either a test run or a production run. Understanding the difference helps you iterate safely during development without affecting real processes.
| | Test run `flask` | Production run `play` |
|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Purpose** | Try out a workflow or individual step while authoring | Run an enabled workflow for real |
| **How to start** | Click **Run** `play` in the workflow editor. Refer to [Provide data for a test run](#workflows-supply-test-input) for more information. | Click **Run** from the workflow list, or let a configured trigger fire. |
| **Scope** | Entire workflow or a single step | Entire workflow |
| **Execution history** | Saved with a flask (`flask`) badge so you can filter for test runs. Step-level test runs are not saved in history.  | Saved without a badge. Filter the executions list by **production** to see only these runs.  |
| **Template context** | `execution.isTestRun` resolves to `true`. | `execution.isTestRun` resolves to `false`. |
You can use the `execution.isTestRun` context variable in your workflow YAML to change behavior during testing. For example, you can choose to skip sending a real notification during a test run.
## Provide data for a test run
When you click **Run** `play` in the editor, the **Test workflow** dialog asks what data to run the workflow against. Which options appear depends on the workflow's triggers. Common options include:
- **Document**: Use a real document from Elasticsearch. Appears when the workflow has a [manual trigger](https://www.elastic.co/elastic/docs-builder/docs/4044/explore-analyze/workflows/triggers/manual-triggers).
- **Manual**: Type your own JSON.
- **Historical**: Reuse the data from a previous run. Elastic Stack: Generally available since 9.5 Elastic Cloud Serverless: Generally available
For [event-driven](https://www.elastic.co/elastic/docs-builder/docs/4044/explore-analyze/workflows/triggers/event-driven-triggers) workflows, the dialog also includes an **Event** tab where you can pick a real event to test against. Refer to [Test a workflow with a real event](/elastic/docs-builder/docs/4044/explore-analyze/workflows/triggers/event-driven-triggers#event-driven-triggers-test). Elastic Stack: Generally available since 9.5 Elastic Cloud Serverless: Generally available
For [alert-triggered](https://www.elastic.co/elastic/docs-builder/docs/4044/explore-analyze/workflows/triggers/alert-triggers) workflows, the dialog includes an **Alert** tab where you can pick a real alert to test against.
### Use a document from Elasticsearch
Select **Document**, then search for and pick a document from an Elasticsearch index. The workflow runs against that document's actual field values, which is useful for confirming your steps behave correctly with real data before you rely on a live trigger.
### Type your own JSON
Select **Manual**, then enter JSON directly in the dialog. This is useful for testing a specific scenario, such as an edge case or a field value that's hard to find in your existing data.
### Reuse data from a previous run
- Elastic Cloud Serverless: Generally available
- Elastic Stack: Generally available since 9.5
Select **Historical**, then, under **Select execution**, search or pick a previous run from the list. A time-range filter next to the picker defaults to the last week, so you can narrow a long execution history down to the runs you care about.
After a run from the editor finishes, click the **Run again** icon `refresh` next to **Done** in the execution panel. The **Test workflow** dialog opens on the **Historical** tab with that run selected. The time range uses the execution's start time as the end of the range and a start one week earlier, so the selected run stays in the list.
If you select a run from the **Executions** tab, click **Run** in the editor and select **Historical**.
If you change the time range so the selected execution falls outside it, the selection clears and **Run** stays unavailable until you pick another execution.
After you select an execution, click **Run** to start a test run using that execution's data.
Reusing data this way is useful when you want to reproduce an issue or validate a workflow change against real data from a prior run, without tracking down the original event or re-entering values by hand.