Skip to main content

Workflows

Stem Workflows let you orchestrate multi-step business processes with durable state, typed results, automatic retries, and event-driven resumes. The StemWorkflowApp helper wires together a StemApp, workflow store, event bus, and runtime so you can start runs, monitor progress, and interact with suspended workflow state from one place.

This page is now the short orientation page. The full workflow manual lives in the top-level Workflows section.

Start there for the full workflow guide​

Runtime overview​

bin/workflows.dart
  final client = await StemClient.fromUrl(
    'redis://127.0.0.1:56379',
    adapters: const [StemRedisAdapter(), StemPostgresAdapter()],
    overrides: const StemStoreOverrides(
      backend: 'redis://127.0.0.1:56379/1',
      workflow: 'postgresql://<user>:<password>@127.0.0.1:65432/stem',
    ),
  );
  final workflowApp = await client.createWorkflowApp(
    flows: [ApprovalsFlow.flow],
    scripts: [retryScript],
    eventBusFactory: WorkflowEventBusFactory.inMemory(),
    workerConfig: const StemWorkerConfig(queue: 'workflow'),
  );

Start the runtime once the app is constructed:

  await workflowApp.start();

StemWorkflowApp exposes:

  • runtime – registers workflow definitions and coordinates run execution and resume logic.
  • store – persists checkpoints, suspension metadata, and results.
  • eventBus – routes topics that resume waiting runs.
  • app – the underlying StemApp (broker + result backend + worker).

What makes workflows different from tasks​

  • workflow runs persist durable state in a workflow store
  • steps or checkpoints can suspend on time or external events
  • resumption happens through persisted watchers and due-run scheduling
  • admin tooling can inspect runs even after worker restarts

Flow versus script​

  • flows: declared steps are the execution plan
  • scripts: run(...) is the execution plan
  • script checkpoints are durable replay boundaries plus manifest metadata

The details now live in Flows and Scripts.