# Durable Workflows for Distributed Applications

Dapr Workflow is a durable execution engine: you write workflows as ordinary code, and Dapr persists each completed step so a workflow resumes after a crash, restart, or redeployment.

Dapr Workflow brings durable, verifiable execution to distributed applications. Long-running processes such as multi-step orchestrations, sagas, approval flows, data pipelines, and agent plans survive crashes, restarts, and network failures because every step is checkpointed to state storage. Write workflows as ordinary code in Go, Python, .NET, Java, or JavaScript, and let Dapr handle the hard parts: retries, timers, fan-out/fan-in, and compensation.

### Write workflows as code

Define workflows as regular functions in your language of choice. Dapr turns them into durable executions automatically, with no DSL, state machine editor, or separate workflow engine to learn. Your existing testing tools and IDE work unchanged.

[Read the docs](https://docs.dapr.io/developing-applications/building-blocks/workflow/howto-author-workflow/)

### Automatic retries and compensation

Declare retry policies, timeouts, and compensation steps in code. Dapr handles transient failures, exponential backoff, and saga rollback. When a workflow can't recover, you get a clear failure path instead of a hung job.

[Read the docs](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-features-concepts/#retry-policies)

### Human-in-the-loop and external events

Pause workflows waiting for approvals, webhook callbacks, or events from other services. Dapr parks the execution in state storage and resumes instantly when the signal arrives, even weeks later or after the host restarts.

[Read the docs](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-patterns/#external-system-interaction)

### Scale without operating a workflow engine

There's no separate workflow server to deploy, patch, or scale. Dapr Workflow runs inside the same sidecar as the rest of your Dapr APIs, using your existing state store (Redis, Postgres, Cosmos DB, and more) as the durable backend. Dapr 1.19 delivers up to 40% higher workflow throughput in the project's nightly performance tests compared with 1.18.

[Read the docs](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-architecture/)

### Composable with every Dapr API

Call service invocation, pub/sub, state, bindings, actors, and AI agents directly from workflow activities. The entire Dapr building-block surface is compatible with Dapr workflow, with the same security and observability guarantees.

[Read the docs](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-overview/)

### Workflows across apps

An app can start, get, raise events on, pause, resume, terminate, and purge workflows that another app in the same namespace owns, without registering those workflows itself. Supported SDK workflow clients can also rerun them. The owning app's workflow access policy decides which callers can perform which operation on which workflow.

[Read the docs](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-multi-app/)

### Detached workflows

A workflow can start a detached workflow: an independent instance with its own history and lifecycle, no link to its parent, and no result back to it. Use it for work that should outlive the caller, such as a clean-up or report job.

[Read the docs](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-detached/)

### Production-grade observability

Every workflow instance, activity, and retry is traced with OpenTelemetry. Inspect running workflows, replay history, and debug failures using standard tracing backends such as Jaeger, Zipkin, Grafana Tempo, and Application Insights.

[Read the docs](https://docs.dapr.io/operations/observability/tracing/tracing-overview/)

### Verifiable execution

Workflow execution histories can be cryptographically signed, making what ran tamper-evident and auditable. Every history event is signed using the sidecar's mTLS identity, creating a chain of signatures that is verified each time workflow state is loaded.

[Read the docs](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-history-signing/)

### Inspect workflows while you build

Watch instances, activities, retries, and history as workflows run locally, without adding instrumentation. The Dapr Dev Dashboard, maintained by Diagrid, gives you a live view of Dapr on your machine while you develop.

[Read the docs](https://docs.diagrid.io/dapr-open-source/dapr-dev-dashboard/)

[Get started](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-overview/)

[Quickstart](https://docs.dapr.io/getting-started/quickstarts/workflow-quickstart/)