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

# What are Workflows in Octave?

> Workflows chain Octave agents into multi-step pipelines you trigger as a single async job. Build them visually in the dashboard, run them via API.

## What is a Workflow?

A Workflow is a graph of [Agents](/concepts/agents) wired together into a multi-step pipeline — enrich → qualify → branch → generate → notify — that you trigger as a single async job. Workflows are the bridge between one-off agent calls and production GTM automation: instead of stitching together five API calls in your own code, you define the pipeline once in Octave and invoke it with a single request.

You build Workflows visually in the [Octave dashboard](https://app.octavehq.com). Each node in the graph is an [Agent](/concepts/agents) of a specific type, with its inputs mapped from upstream node outputs or from the workflow's initial payload.

## How Workflows run

Workflows are always asynchronous. The flow:

1. **You POST** to `/api/v2/workflows/run` with the workflow's `workflowOId`, a `callbackUrl`, and the input fields the **entry node** expects.
2. **Octave returns** a `workflowRunOId` immediately and starts executing the graph in the background.
3. **Each node runs** in sequence (or in parallel where the graph allows), passing its output downstream.
4. **On completion**, Octave POSTs the final result to your `callbackUrl`.
5. **You can poll** intermediate status with `GET /api/v2/workflows/run/status`.

The callback contract is shared with [other async endpoints](/concepts/async-callbacks).

## Entry node inputs

A Workflow's input schema is determined by its **entry node** — the agent type that kicks off the graph. If the entry node is an Enrich Person agent, the workflow expects person identification fields (email, LinkedIn URL, etc.). If it's a Content agent, it expects person/company context plus an optional output configuration.

Any fields you pass beyond `workflowOId` and `callbackUrl` are forwarded to the entry node as its `agentInputData`. To know what to send, open the workflow in the dashboard, identify the entry node, and reference the corresponding [Agent](/v2-api-reference/agents/list-agents) documentation.

## When to use Workflows vs ad-hoc agent calls

* **Single-step task** (enrich a company, generate one email) → call the agent's `/run` endpoint directly.
* **Multi-step pipeline** (enrich → qualify → write sequence if good fit) → wrap it in a Workflow.
* **Batched / scheduled processing** → invoke a Workflow from Clay, n8n, or a cron job. The async callback model is built for this.

Saved [Agents](/concepts/agents) handle the "I want a reusable, configured agent" need. Workflows handle the "I want a reusable, configured *pipeline*" need.

## Managing Workflows via API

* `POST /api/v2/workflows/run` — run a workflow with an input payload and callback URL
* `GET /api/v2/workflows/run/status` — get the current status of a workflow run
