# Baserow Workflow Management - Draft, Test, and Publish

> Draft, Paused, and Live are the three states a Baserow workflow moves through on its way to production - test run, publish click, run history, auto-disabling.

Source: https://opennix.org/en/docs/baserow/automation/workflow-management/


A Baserow workflow moves through three states - Draft, Paused, and Live - and will not process any data until it is explicitly published; this page covers the transitions between those states, the test run that precedes publishing, and how to read run history and understand automatic disabling.

## Overview

Workflow management in Baserow covers the full lifecycle of an automation, from the first build to a production run. The platform keeps that process safe and predictable through clearly separated execution states and visibility into every run; for how triggers and actions fit together inside a workflow, see the [automation section overview](/docs/baserow/automation/).

A critical point: a workflow does not run while in the **Draft** state. Every new workflow starts out as a draft by default, and it will not touch any data until the **Publish** button in the top right corner of the workflow editor has been clicked explicitly.

## Workflow Execution States

A workflow can be in one of three states at any time.

| State | Toggle Appearance | Behavior |
|---|---|---|
| **Draft (default)** | Gray, not clickable | The workflow is still being built and does not execute |
| **Paused** | Gray toggle (clickable) | Temporarily stopped but the configuration is preserved |
| **Live (published)** | Green toggle (clickable) | Active and listening for trigger events |

The typical progression runs Draft to Test to Publish to Live, and a live workflow can be toggled to Paused and back at any time.

## Testing and Publishing

**Testing.** Every node in the workflow needs to be configured before a test run - the full list of available free nodes is covered in [automation actions](/docs/baserow/automation/automation-actions/). The "Start test run" action executes the whole workflow once, for validation. Results land in the run history tab with a success indicator (a green checkmark) or an error warning (red).

**Publishing.** Once a test run succeeds, clicking **Publish** moves the workflow into production: it now monitors for trigger events continuously and runs automatically every time the trigger fires.

**Pausing and resuming.** A live workflow can be toggled to Paused without deleting it - execution stops temporarily while the trigger, action, and node configuration stay exactly as they were. The same toggle brings it back to Live.

## Run History and Monitoring

The run history tab lists the status of every run, its timestamp, a result message, and whether it was a test or a live execution. A failed run shows which node broke and why. This is a separate feature from tracking edits to a single record - individual row versions are covered in [row change history](/docs/baserow/rows/row-change-history/).

When one of the workflow's actions calls an external webhook, it helps to check the [webhooks](/docs/baserow/webhook-api/webhooks/) documentation for the request format and how retries are handled on the receiving end.

## Automatic Disabling

Baserow automatically disables a workflow after a run of consecutive failures - typically 5 to 10 failed executions in a row, persistent configuration errors, repeated authentication failures, or continuous timeouts. This protects data from a workflow that keeps failing in the same way. Renaming, duplicating before debugging, or deleting that workflow is covered in [automation settings](/docs/baserow/automation/automation-settings/).

## Frequently Asked Questions

**What is the difference between a test run and publishing?** A test run executes the workflow once, manually, to check the configuration. Publishing turns on automatic execution every time the trigger fires.

**What happens when editing an already-published workflow?** The edits create a draft version, while the currently published version keeps running unchanged until that draft is published again.

**Does a test run touch real data?** Yes - a test run performs real actions on live data, and those changes are permanent, so treat a test run with the same caution as a live one.

**Why is a workflow not running at all?** The most common reason is that it is still sitting in Draft and has never been published; check the state toggle in the top right of the editor first.

Checking that toggle before digging through node logs or rebuilding the trigger saves time when a workflow looks like it has gone silent.