Workflows

Automations are the evolution of workflows, in open beta for Pro customers.

A workflow is a pipeline: one trigger followed by a sequence of steps. The trigger is the event that starts execution. Each step is an action. Steps execute in sequence, and each one can read the output of the trigger and every step before it.

Any step can be an AI agent with access to Lightfield and your connected tools. Instead of writing a decision tree to parse a Stripe webhook, you give the agent the raw payload and a prompt: “Find or create the right contact, account, and opportunity from this Stripe event.” The agent reads the data, searches Lightfield for existing records, and creates or updates records as needed.

Triggers

Every workflow starts with a trigger. Lightfield supports four types.

Webhooks receive HTTP POST requests from external services. Stripe sends a payment event, Kondo sends a LinkedIn DM, your internal tools push custom payloads. The webhook captures the raw JSON and makes it available to every step that follows.

Object lifecycle triggers fire when objects change inside Lightfield. A new contact is created. An opportunity moves to closed-won. An account’s industry field gets updated. You can watch specific fields, so a workflow that enriches contacts on creation doesn’t fire again every time someone edits a phone number. The trigger output includes the full object and, for updates, a diff with before and after values.

Scheduled triggers run on a cadence: daily, weekly, monthly, or a custom cron expression. Each schedule is timezone-aware. A daily trigger set to 9:00 AM America/New_York fires at 9:00 AM Eastern regardless of daylight saving transitions. These are the entry point for workflows that pull data rather than waiting for it to arrive.

Manual triggers let you fire a workflow by hand, for testing or one-off operations.

Steps

After the trigger, steps do the work. You add them in sequence, and each one can reference the output of any step before it.

Object operations create and update records directly. Create a contact, upsert an account, open an opportunity, log a task or note. These use the same Object API that powers the rest of Lightfield, with full field mapping and relationship linking. Use these when the mapping between input and output is simple and deterministic.

HTTP requests call external APIs. Any method (GET, POST, PUT, PATCH, DELETE), arbitrary headers, JSON request bodies, all with template variables so you can pass data from prior steps into the request. Response bodies are parsed and their fields become available to subsequent steps.

Agent request is the agent step.

The agent step

An agent request runs a Claude-powered agent with access to MCP tools. You give it a prompt, and it can search Lightfield for existing records, create new ones, update fields, read account and opportunity data, and manage tasks and notes. It can also run code in a sandbox and search the web. Because it works through MCP, you can add any MCP-compatible tool server (Granola for meeting notes, Salesforce, Slack, Airtable, and more).

You choose which capabilities to enable: entity creation, entity updates, code execution. Its output is structured and available to subsequent steps, like any other action.

For example, syncing LinkedIn DMs from Kondo into Lightfield with rules alone means parsing the conversation JSON, extracting participant names, fuzzy-matching them against existing contacts, deciding whether to create or update, and mapping any deal signals in the text to opportunity fields. With an agent request, the prompt can be: “Match this LinkedIn conversation to the right contact, create a note summarizing the discussion, and flag any buying signals as opportunity updates.”

Data flow

Steps communicate through a shared execution context. When a step completes, its output is stored under its step ID. Subsequent steps reference that output using template syntax:

{{trigger.email}}              // The email from the trigger payload
{{step1.contact.id}}           // The contact ID created by step 1
{{trigger._diff.stage.after}}  // The new value of 'stage' after an update

Templates resolve against the full context, so one step can reference the trigger, an earlier HTTP response, and an agent step’s output together.

For Object lifecycle triggers on updates, the special _diff field gives you before and after values for every changed field. A workflow that fires when an opportunity stage changes can read {{trigger._diff.stage.before}} and {{trigger._diff.stage.after}} to know exactly what transition happened.

Versioning

Workflow definitions are immutable-versioned. Every edit creates a new version snapshot. Running workflows are pinned to the version that was active when they started, so publishing a new version never disrupts in-flight executions.

Next steps

• Building workflows - Detailed reference for triggers, actions, and data flow configuration.
• Workflow recipes - Three end-to-end walkthroughs: Stripe webhook ingestion, LinkedIn DM sync with Kondo, and outbound sync.
• How workflows work - Execution model, concurrency control, and reliability guarantees.