---
title: "Workflows"
summary: "How a business automates its own operations in LatticeKit: actions built from typed steps, triggered by events, schedules or state, with three execution modes depending on whether the work must be immediate, backgrounded or durable."
---

# Workflows

A business can automate its own operations without writing code. An **action** is a
sequence of steps the platform runs on the business's behalf: send a reminder the evening
before a booking, apply a credit when a class is cancelled, notify a manager when stock
runs low, follow up after a first visit.

## Actions and steps

An action is a graph of typed **steps** rather than a script. Each step declares what it
needs and what it produces, so an action can be validated before it ever runs, and a step
that would receive something of the wrong shape is rejected at authoring time rather than
at three in the morning.

Steps cover the obvious operations — send a message, wait, branch on a condition, call a
platform capability, update a record — and branching conditions are written as
[expressions](expressions.md).

Because steps call the same capabilities everything else calls, an action cannot do
something an operator could not, and cannot do it under weaker rules.

## Triggers

An action starts in one of three ways:

- **Event** — something happened in the business. A booking was confirmed, an order
  closed, a payment failed. Event triggers can be filtered by an expression, so an action
  runs only for the cases that matter rather than for every event.
- **Schedule** — a recurring time. Nightly, weekly, the first of the month.
- **State** — a condition became true, evaluated on a cadence rather than in response to a
  single event.

## Execution modes

Not all automation has the same reliability requirement, so an action declares which it
needs:

| Mode | For |
|---|---|
| **Immediate** | Short work whose result the caller waits for. |
| **Background** | Work that should not block the caller, and that can be safely retried. |
| **Durable** | Long-running or multi-step work that must survive restarts and continue exactly where it left off. |

Durable is the one to choose when an action spans hours or days — a multi-stage follow-up
sequence, a dunning cycle — because the platform keeps its position rather than starting
over.

## Obligations

Some workflows exist to resolve something a record is waiting on: a booking that cannot
confirm until a deposit is paid or a waiver is signed. These are tracked as explicit
obligations rather than as fields, so an action can satisfy one and the waiting record
advances on its own. See [scheduling](scheduling.md).

## What to expect as an integrator

Actions run asynchronously unless the mode says otherwise, so do not assume an effect has
already happened when a call returns. Where the effect matters to you, read the record
back or subscribe to the event rather than inferring it from a successful write.