---
title: Building automations | Lightfield
description: How the agent builds automations from chat, and the triggers, steps, permissions, run-as modes, and lifecycle behind them.
---

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

This page covers the building blocks of a Lightfield automation: how the agent builds one with you in chat, what triggers and steps are available, how permissions and run-as identity work, and the draft-test-activate lifecycle.

You don’t assemble automations in a node editor. You describe what you want in chat, and Lightfield’s agent, acting as your automation engineer, programs it for you.

## Building with the agent

To build an automation, describe the outcome you want in chat. The agent works through a structured process:

1. **Describe**: you and the agent agree on a clear name and a plain-language description of what the automation does and when it runs.
2. **Research**: the agent uses the tools available to it (file system, MCP connectors, CRM search) to understand the data, interfaces, and exact calls the automation will need.
3. **Design**: the agent divides the task into steps, each with a single clear purpose, and works out the triggers, the declared inputs, the run-as identity, and the per-step permission set each step needs.
4. **Validate**: before saving the draft, the agent roughly validates the design: that the steps hang together, the prompts reference inputs that exist, and the permissions cover what each step actually does. This is a sanity check, not a guarantee; the real proof is a test run.
5. **Draft**: the agent saves the validated design as a draft. Nothing is live yet, and its triggers are inactive.
6. **Test run or activate**: once a draft exists, you can grant its permissions and **test run** it to see it work end to end, or **activate** it to put it live on its triggers. You typically iterate (test, review the run, ask the agent to adjust) until the behavior is right, then activate.

The same agent can also work on existing automations: point it at one to investigate what happened on a run and improve it.

## Steps

An automation is an ordered list of **steps**. Each step has:

- a **name**,
- a **prompt**: the natural-language instruction the agent follows for that step, written in Markdown,
- a **permission set**: the tools, MCP connectors, APIs, and CLIs that step is allowed to use.

Steps are plain-language instructions, not rigid blocks with fixed inputs and outputs. The agent decides how to divide the work and how context carries from one step to the next. Each step runs as an AI turn in a shared run thread, so later steps automatically see what earlier steps produced, and you never wire one step’s output into the next.

### Defined inputs

Alongside its steps, an automation declares a short list of **inputs**: the named values each run works with (for example, an `account`, an `email`, or a number of days to look back). Each input has a name, a type (text, a date, a number, a CRM record like an account or contact, or a workspace member), and a description.

Each run fills in its inputs once, when it starts: a create- or update-record trigger supplies the record that fired it, a webhook pulls them from the incoming data, and a manual run uses the values you pass. Step prompts then refer to an input by name (for example `{{inputs.account}}`) instead of digging through raw trigger data. If an input the automation expects isn’t there when a run starts, the run stops with a clear error rather than guessing.

Inputs are also what make **variable run-as** possible. When you want an automation to run as “the owner of the account being processed” rather than a fixed person, the agent uses the `account` input and points the run-as identity at the account’s owner. When a run starts, Lightfield reads that owner and runs every step as them. See [Run as](#run-as) for how this affects permissions and visibility.

## Triggers

Every automation runs on a set of triggers. An automation can listen for more than one; each trigger starts the same step sequence.

### Scheduled

Runs on a recurring cadence: daily, weekly, monthly, or an advanced custom (cron) schedule. All schedules are timezone-aware: a daily trigger set to 8:00 AM in your workspace timezone fires at 8:00 AM local time, respecting daylight saving transitions.

### Event (create or update record)

Fires when a CRM or custom-object record changes:

- **Create record**: fires when a record of the configured type is created.
- **Update record**: fires when a record is updated. You can scope an update trigger to specific watched fields, so an automation that reacts to opportunity stage changes won’t fire when someone edits the description.

### Webhook

Fires on an inbound HTTP event from an external service (or via the Lightfield API): a customer created in Stripe, a LinkedIn message received via a connector, a payload from an internal tool. The incoming data becomes the run’s input. You can provide an example payload to help the agent design steps around the data it should expect.

### Manual

You (or the agent, during testing) can trigger a run by hand, optionally passing a JSON payload as input. This is how the agent test-runs a draft while building.

## Tools

The tools available to automation steps span the full set available in chat plus Lightfield’s API capabilities. Depending on the permissions you grant, a step can:

| Capability         | What the step can do                                                    |
| ------------------ | ----------------------------------------------------------------------- |
| Records            | Create and update accounts, contacts, opportunities, and custom objects |
| Objects            | Generate tasks, notes, files, and other objects                         |
| Knowledge & Skills | Read and write knowledge and Skills                                     |
| Connectors (MCP)   | Call connected MCP tool servers (Granola, Linear, Notion, and others)   |
| API / CLI          | Use Lightfield’s API and command-line tools from a secure sandbox       |
| Network & secrets  | Make network requests and use workspace secrets for authentication      |
| Email              | Draft emails for user review                                            |

## Permissions

Every step has an explicit list of what it’s allowed to do, and each entry comes with a reason the step needs it. An entry can be:

- a **Lightfield tool**: for example, “create a task,”
- a **connector** and the specific actions on it: for example, Linear’s “create issue,”
- **API access** scoped to certain data: for example, “read and update accounts,”
- a **command-line tool** the step can run in its sandbox.

You never write these out yourself; the agent proposes them as it builds the automation, and you approve them. The grant flow is:

1. **Build**: the agent proposes the permissions each step needs, based on what that step’s prompt actually does.
2. **Grant**: when a test run, publish, or activation needs permissions you haven’t granted yet, the agent shows you the full set of permissions through an approval card. You click to grant.
3. **Activate**: once granted, you can activate the automation; it moves to active and its triggers go live.
4. **Change**: if a step’s prompt or permissions change later, the agent checks whether you need to re-grant before testing or activating again.

A run can only do what its steps have been granted. Anything a step tries outside its permissions is blocked and recorded.

## Run as

An automation declares the identity its steps run under. This determines both what the run can read and who can see the run and its outputs.

- **Workspace user**: the shared default. The run reads only what every workspace member can read, and the run and its outputs are visible to eligible workspace members.
- **A specific user**: the run uses that user’s permissions and connected accounts. The run and its outputs are visible only to that user and to workspace admins. The user can be fixed (“always run as Mary”) or taken from the trigger (“the owner of the account being processed”, “the sender of the email”).

When the user is taken from the trigger, the agent uses a [defined input](#defined-inputs) (for example, the `account` the run works with) and points the run-as identity at a person on it. When the run starts, Lightfield reads that person (say, the account owner) and runs every step as them. Scheduled automations can’t pick a user this way, since there’s no record in the trigger to read it from.

**Connectors are tied to the user who connected them.** If a step needs a connected account (a Granola, Salesforce, or Gmail connector someone set up under their own login), the automation has to run as that user to reach it. A workspace-user run can’t use a personal connector, so an automation that depends on one runs as a fixed user (the person who owns the connection). For shared resources that aren’t tied to a person (a Slack bot token or a service API key stored as a workspace secret), a workspace-user run is fine.

**A connector also has to be opted in to automations.** Connecting an app isn’t enough on its own: in the connector’s settings, its owner must turn on **Use in workflows and automations** to allow that connector’s data and tools to be used inside automations. Until that toggle is on, steps can’t reach the connector even when the run is executing as the user who set it up.

## Lifecycle

Automations move through three states:

| Status      | Description                                                      |
| ----------- | ---------------------------------------------------------------- |
| Draft       | Being built or edited with the agent. Triggers are not active.   |
| Active      | Published and listening for triggers. Edits create new versions. |
| Deactivated | Paused. Triggers stop firing. Can be reactivated.                |

Each time you publish, Lightfield saves that version. A run always uses the version that was live when it started, so editing and republishing never disrupts runs that are already going. Only workspace admins can see and edit automations.

## For review

Instead of writing changes directly, a step can produce a draft **for review** that a person approves or dismisses afterward. A draft is assigned a reviewer when it’s generated and routed to that reviewer’s For review queue.

For now, **email drafts are the only review item type available**: a step can draft an email for a reviewer to approve and send. Record creation, record updates, and more are coming to For review. See [How For review works](/automations/how-for-review-works/index.md) for how drafts are routed to reviewers and what approving or dismissing one does.

## Next steps

- **[How automations work](/automations/how-automations-work/index.md)**: the execution engine behind runs, reliability, and recovery.
- **[How For review works](/automations/how-for-review-works/index.md)**: how the drafts your steps produce reach a reviewer.