# Workflows

Compose long-running, retry-safe application steps from Ferrite queues, state, transactions, and events.

Ferrite workflows coordinate durable steps without keeping a process alive for
the lifetime of the work. Each transition is persisted, retryable, and visible
through the same application logs and resources as the rest of your app.

## Model a workflow

Store the workflow instance, publish the next runnable step to a private queue,
and append an event for each accepted transition. Use a transaction when a
state change and its outbox record must commit together.

```text
checkout.received
  → inventory.reserved
  → payment.pending
  → payment.completed
  → fulfillment.requested
```

The worker treats the stored state as authoritative. A duplicate payment
webhook or redelivered queue lease observes that the transition already
completed and returns the prior result.

## Use the workflow package

`ferrite-workflows` provides the deployable workflow service used by the sample
stack. The [commerce fulfillment](/developers/samples/) and secure rollout
samples show waits, approvals, retries, and compensating actions.

## Design rules

- Give every external event a stable idempotency key.
- Persist intent before publishing work.
- Make each step safe to retry independently.
- Put attempt limits and dead-letter handling on every queue.
- Record the reason for a terminal failure; do not leave an instance merely
  “stuck.”

Continue with [Transactions](/developers/transactions/), [Webhooks](/developers/webhooks/),
and [Reliability](/developers/reliability/).