> For the complete documentation index, see [llms.txt](https://v2.dataos.info/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://v2.dataos.info/references/resources/workflow.md).

# Workflow

Explains workflows for orchestrated, multi-step execution.

A Workflow is a batch workload that runs steps in a directed acyclic graph, or DAG. Use it to orchestrate scheduled jobs, validations, backfills, and repeatable batch tasks.

Each DAG node is a step. Each dependency edge defines execution order. The Workflow defines orchestration. The stack defines what each step runs.

## Access requirements

Before creating or managing a Workflow, ensure you have the required permissions. See [Workflow: Access control](https://v2.dataos.info/operate/access-control/roles-and-permissions/resource-level-permissions/workflow-access-control).

## When to use

Use a Workflow when you need to:

* Run batch logic to completion.
* Trigger execution on a schedule or on demand.
* Coordinate one or more dependent steps.

## Manifest structure

Use the following structure to define a Workflow resource.

{% code title="workflow\.yaml" expandable="true" collapsedlinecount="12" %}

```yaml
version: v2alpha
name: ${{workflow-name}}
type: workflow
tags:
  - ${{tag1}}
  - ${{tag2}}
description: ${{workflow-description}}
spec:
  schedule:
    crons:
      - ${{cron-expression}}
    timezone: UTC
    concurrencyPolicy: Forbid
  dag:
    - name: ${{step-name}}
      title: ${{step-title}}
      depends:
        - ${{upstream-step-name}}
      spec:
        compute: ${{compute-resource}}
        resources:
          requests:
            cpu: ${{cpu-request}}
            memory: ${{memory-request}}
          limits:
            cpu: ${{cpu-limit}}
            memory: ${{memory-limit}}
        stack: ${{stack-name}}
        stackSpec:
          ${{stack-specific-configuration}}
```

{% endcode %}

## Create a Workflow

Follow [Create a Workflow](/references/resources/workflow/create-a-workflow.md) to define the DAG, configure step runtimes, apply the manifest, and verify the run.

## Learn the building blocks

Use [Core concepts](/references/resources/workflow/core-concepts.md) for DAG design, scheduling, steps, stacks, projections, and storage.

Use [Example](/references/resources/workflow/example.md) for end-to-end Workflow manifests.

### Workflow lifecycle

Workflows are runnable resources. They support runtime details and logs from creation through completion.

#### Create or update a Workflow

```bash
dataos-ctl resource apply -f /home/workflow.yaml
```

#### Get the specific Workflow details

```bash
dataos-ctl resource get -t workflow -n echo-workflow -d
```

#### View runtime details

```bash
dataos-ctl resource runtime get -t workflow -n echo-workflow
```

#### List Workflows

```bash
dataos-ctl resource get -t workflow
```

#### View across all Workspaces

```bash
dataos-ctl resource get -t workflow -a
```

#### View execution logs

```bash
dataos-ctl resource log -t workflow -n echo-workflow
```

#### View logs for a specific container

```bash
dataos-ctl resource log -t workflow -n echo-workflow --container extract
```

#### Delete a Workflow

```bash
dataos-ctl resource delete -t workflow -n echo-workflow
```

## Workflow states

Workflows move through these common states:

* `creating`
* `active`
* `running`
* `succeeded`
* `failed`
* `deleted`

## Field reference

See [Field reference](/references/resources/workflow/field-reference.md) for the complete Workflow manifest field reference, including DAG and step-level runtime fields.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://v2.dataos.info/references/resources/workflow.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.