# Deploying a Flow

> Publish a workflow to Orchestrator so it can run in production.

Deploying a Flow makes it available to run in production. Before you deploy, you build and test your flow in the canvas — running it in **Debug** and checking it with **Eval** — but it cannot be triggered by external events, run on a schedule, or invoked by other systems until it is deployed.

## How deployment works

When you deploy a Flow, the platform:

1. Validates the workflow definition (checks for missing required fields, broken connections, and unresolved variables). Blocking validation errors stop the publish — you must resolve them before you can deploy.
2. Packages the workflow.
3. Publishes the package to Orchestrator and activates any triggers defined in the workflow (scheduled triggers start firing, integration triggers start listening).

## Publishing a workflow

1. Open the workflow on the canvas.
2. Select **Publish** in the top toolbar.
3. Confirm.

## Result

The workflow is published to Orchestrator and activated. Any triggers defined in the workflow become active — scheduled triggers start firing and integration triggers start listening.

If validation finds blocking errors, the publish is stopped and the errors are reported. Resolve them and publish again.

## Deploying from the editor

You can also publish by packaging your workspace and deploying it to Orchestrator from the editor. The editor uploads the workflow to Studio Web as part of this path. Refer to [Flow in VS Code](vs-code.md) for packaging and deploying from a local workspace.

## Common mistakes

- **Publishing without testing** — Always run your flow in **Debug** at least once before publishing.
- **Ignoring validation errors** — Blocking validation errors stop the publish. Resolve every reported error before you deploy.

## Related pages

- [Subflows](subflows.md)
- [Observing runs](observing-runs.md)
- [Your first Flow](quickstart.md)