---
title: How automations work | Lightfield
description: Execution model, reliability, and operational guarantees behind automation runs.
---

Automations are in open beta, available to customers on the Pro plan.

Lightfield automations run on a durable execution engine. This page describes, at a high level, how runs execute and recover.

## Runs, steps, and the run thread

- One trigger starts one run. Multiple trigger types can feed the same automation; each enters the same step sequence.
- Each run executes one immutable version of the automation and produces a **run thread**: the record of what each step did.
- Steps run in sequence on that shared run thread, so later steps see what earlier steps produced.

A single step can involve many actions behind the scenes; that all counts as one step. Steps are durable: if a run is interrupted partway through, it resumes where it left off instead of starting over.

**Runs execute to completion without interruption.** You can’t approve or redirect actions mid-run; human-in-the-loop happens afterward through For review.

## Durable execution

Automation steps can take a long time. An agent reasoning over a complex payload might run for 60 seconds; an external call might take 30.

The engine runs slow work (external calls, AI execution) separately from fast work (state updates, scheduling the next step), so a long-running step doesn’t block other steps or runs.

Each step’s side effects are idempotent. If a step is retried after a transient failure, it produces the same result without duplicating records or sending duplicate requests.

## Event processing

When a trigger fires (webhook received, record changed, schedule ticks), the event is captured atomically, so it is not lost even if the system crashes immediately afterward.

A sharded background processor dispatches events to runs. Sharding keeps a single high-volume automation from starving others. Each event is processed with a scoped idempotency key, so replaying events after a failure never creates duplicate runs.

For event (record) triggers, only changes to watched fields count. If a trigger watches the `stage` and `amount` fields on an opportunity and an update only changes the `description` field, the trigger doesn’t fire. This filtering happens before a run ever starts.

## Identity and isolation

Each run’s identity (its [run-as](/automations/building-automations#run-as/index.md) actor) is resolved once, at run start, and never re-resolved, so editing the automation later can’t retroactively change who could see a historical run. Every step in the run executes under that identity, and run visibility follows from it: workspace-user runs are visible to eligible workspace members; specific-user runs are visible only to that user and workspace admins.

Each step is limited to its declared [permission set](/automations/building-automations#permissions/index.md). Any tool, connector, API, or CLI call outside that set is blocked and recorded as a policy violation.

## Reliability guarantees

| Guarantee                       | How                                                                         |
| ------------------------------- | --------------------------------------------------------------------------- |
| Events are never lost           | Trigger events are captured atomically with the originating change          |
| No duplicate runs               | Scoped idempotency keys on every event                                      |
| Safe to edit active automations | Immutable version snapshots; running runs are pinned to their start version |
| Stable run identity             | Run-as actor and inputs are resolved once at run start and never re-derived |
| Automatic recovery              | Interrupted runs resume from a durable checkpoint                           |

## Error handling

A step is monitored for completion and may be marked failed if errors are detected. When a step fails terminally, the run fails and no later steps run. The failed step retains the error and any results up to the point of failure, so the run thread shows what happened.

Infrastructure interruptions (a worker restarting mid-step) are handled separately from logical failures: the run resumes from its checkpoint rather than counting as a failure.

## Observability

Every run produces a browsable run thread: a record of each step’s input, actions, and output. From the run details page (or from chat), you and the agent can inspect a run together: status, duration, trigger metadata, per-step transcript, and any policy violations. The agent can read the same run thread, so you can ask it what went wrong on a run and have it propose a fix to the automation.

---

For how to build and configure automations, see [Building automations](/automations/building-automations/index.md). For the human-in-the-loop surface where reviewers approve the drafts a run produces, see [How For review works](/automations/how-for-review-works/index.md).