> ## Documentation Index
> Fetch the complete documentation index at: https://docs.connectstrata.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflows

> Read data from sources and write to destinations in real-time

## Creating a Workflow

Start a conversation with the Strata agent to create a workflow. Describe the systems you want to connect and how data should flow between them. The agent will automatically find or prompt you to create the necessary [integrations](/integrations) and connections, then build the workflow for you.

## Workflow Structure

A workflow is a collection of nodes automates data flows between your integrations. Workflow actions include things like making API requests, transforming data, and branching logic.

Every workflow must have exactly one trigger node. When the trigger fires, the workflow executes each downstream action in sequence.

### Triggers

A trigger defines when and how a workflow starts. Currently, workflows support **webhook triggers** — an external system sends an HTTP request to a Strata-managed URL, which kicks off the workflow.

The incoming webhook payload is available to all downstream actions as the trigger's output.

### Actions

An action performs work during a workflow execution. Currently, workflows support **HTTP actions** — making an API request to one of your connected integrations.

When you configure an HTTP action, you specify:

* The **integration** to call (e.g. HubSpot, Slack)
* The **API endpoint** to request
* The **request parameters** — path parameters, query parameters, headers, and body

Request parameters are defined using [Specs](#specs), which let you reference and transform data from upstream nodes.

## Data Flow

Each node in a workflow can produce output. To reference that output in a downstream node, every node has an **output key** — a unique identifier like `get_customer` or `create_ticket`. Downstream nodes use this key to access the output data.

For example, if a webhook trigger has the output key `new_order`, a downstream HTTP action can reference the order's customer ID as `new_order.customer.id`.

## Testing

You can test a workflow before deploying it. Run a test execution with sample input data to verify that each step produces the expected output. Test executions support **dry-run mode**, which validates the workflow without making any external API calls.

Test results show the input, output, and HTTP request/response details for each step, making it easy to debug data mapping issues.

## Deployment

Workflows have a lifecycle status:

| Status       | Description                                                |
| ------------ | ---------------------------------------------------------- |
| **Draft**    | The workflow is being edited and will not execute.         |
| **Active**   | The workflow is deployed and will execute when triggered.  |
| **Inactive** | The workflow is paused and will not execute.               |
| **Error**    | The workflow encountered a configuration or runtime error. |

New workflows start in **Draft** status. When you're ready to go live, set the status to **Active**. You can pause a workflow at any time by setting it to **Inactive**, and reactivate it when you're ready.

## Version History

Every time you update a workflow's definition, Strata saves a snapshot. You can view previous versions and restore any snapshot to roll back changes.

## Execution History

Each workflow execution is recorded with:

* The overall execution status (running, completed, or failed)
* A step-by-step log showing the input, output, and timing for each node
* Full HTTP request and response details for each API call

Use execution history to monitor your workflows and diagnose failures.