# Test and debug a draft

**Run Draft** executes the flow you're building so you can see how it behaves before you publish it. You provide a sample input, run the current draft against a chosen environment, and inspect what each node received and produced. Testing this way keeps experimentation off your live process and lets you correct configuration and run again until the flow does what you expect.

**Permissions.** Building and running drafts requires the **Admin** or **Partner** role. See [Users and access](../onboarding/users-access.md).

## Before you run

- **Work in the draft.** Make sure you're editing the draft — the version selector should show **Draft**. The editor shows the draft's state, including whether your latest changes are synced, and whether the builder is connected.
- **Choose an environment.** Use the environment selector to pick the environment the draft should run against. Choose a **test** environment so write-back nodes use sandbox settings rather than production. See [Configure environments and variables](./environments-variables.md).

## Provide a sample input

A run needs an input, and how you supply it depends on the flow's trigger:

- **Manual File Upload trigger.** When you run the draft, upload a sample file to start the run. You can also **save test files** so you can re-run with the same sample without uploading it again — once test files are saved, the run control offers a **Test** option that reuses them.
- **Outlook Trigger.** Exercise the flow by sending a matching email to the connected mailbox, which starts a run the same way a real message would. See [Configure triggers](./triggers.md).

Use safe sample documents for this — see [Safe test-data practices](#safe-test-data-practices) below.

## Run the draft

1. Confirm the version selector shows **Draft** and the environment selector shows your test environment.
2. Click **Run Draft** (or **Test** to reuse saved test files).
3. Provide the sample input if prompted.

The draft executes in the selected environment, running each node in order from the trigger onward.

## Inspect the run

As the run progresses, the builder shows its steps so you can see what happened at each node:

- **Status.** Each step reports its status — for example **Running**, **Completed**, or **Error** — so you can see how far the run got and where it stopped.
- **Inputs and outputs.** Select a step to inspect the data it received and the data it produced. This is how you confirm a node got the values you expected and passed the right results downstream — for example, that extraction returned the fields you defined, or that a write-back node received the correct payload.
- **Errors.** If a step fails, its error is shown alongside that step, so you can pinpoint which node failed and why.

Sensitive values, such as variable values, are masked in the inspection view; the document content and extracted field values you test with are visible there, which is why you should test with safe sample data.

## Correct and rerun

Testing is a loop:

1. Find the step that failed or produced the wrong output.
2. Fix the node's configuration — a mapping, a missing field, an endpoint, a filter, a validation rule.
3. Make sure your change is synced, then click **Run Draft** again (or **Test** with your saved files) and inspect the results.

Repeat until every step completes and the outputs are what you expect. When the draft runs cleanly end to end, it's ready to publish — see [Drafts and publishing](./drafts-publishing.md).

## Safe test-data practices

- **Use redacted or synthetic samples.** Prefer documents with fake or masked details over real customer data, especially because saved test files are reused across runs and the inputs and outputs are visible in the inspection view.
- **Run against a test environment.** Point the environment selector at a sandbox environment so integration and write-back nodes don't touch production systems or records.
- **Keep secrets in variables.** Connection credentials belong in variables (which are masked in the inspection view), not typed into node fields as constants. See [Configure environments and variables](./environments-variables.md).

## Current limitations

- **Run Draft runs the current draft once per run.** To try a change, correct the configuration and run again — testing is the correct-and-rerun loop described above.
- **Manual upload is the in-builder sample path.** Saving and reusing test files applies to flows that start with the Manual File Upload trigger; flows that start from email are exercised by sending a matching message to the connected mailbox.

For the run records a flow produces once it's published and running, see [Run history](../monitor-review/run-history.md).

## Where to go next

- [Configure environments and variables](./environments-variables.md) — choose the environment a draft runs against.
- [Drafts and publishing](./drafts-publishing.md) — publish a draft once it tests cleanly.
- [Configure triggers](./triggers.md) — how each trigger supplies the run's input.
- [Node catalog](./node-catalog.md) — the nodes whose inputs and outputs you inspect.
- [Run history](../monitor-review/run-history.md) — review runs of a published flow.