Workflows

The problem with traditional automation

Consider a Stripe webhook integration. A customer.subscription.created event arrives. You need to find or create a contact, associate them with an account, and open an opportunity. Sounds simple.

Then reality hits. The customer.name field is sometimes a person’s name, sometimes a company name, sometimes empty. The email might map to an existing contact or it might not. The subscription metadata includes a company field that your sales team populated inconsistently. The same customer shows up across three different Stripe events with slightly different data.

In a traditional automation tool, you handle this with conditionals. Check if customer.name contains a space (probably a person). Check if the email domain matches an existing account. Check if metadata.company is non-empty. Check if a contact with this email already exists. Check, check, check.

Three layers in, your workflow is a brittle mess of string comparisons and null checks. It works for the cases you thought of when you wrote it. It silently does the wrong thing for everything else. And when Stripe changes their payload structure or your sales team starts using a new metadata convention, the whole thing breaks.

This is the fundamental problem. Real webhook data is messy. Real field mappings are ambiguous. Real business logic has edge cases that multiply faster than you can write conditionals for them. The traditional approach of expressing this logic as a decision tree turns every integration into a maintenance liability.

A different approach

Lightfield workflows replace brittle conditional logic with AI agents that can interpret data the same way a human would.

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.

The key difference is what a step can be. In Lightfield, any step in the pipeline can be an AI agent with structured access to Lightfield and your connected tool ecosystem. 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, handles the ambiguity, and writes the right output.

This is not a cosmetic difference. It changes what’s tractable. Integrations that would require dozens of fragile conditionals become a single step with a clear prompt.

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. Useful 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 describing what you want, and it has the tools to execute: search Lightfield for existing records, create new ones, update fields, read account and opportunity data, manage tasks and notes. It can execute code in a sandboxed environment. It can search the web. And because it operates through MCP, you can extend its capabilities with any MCP-compatible tool server (Granola for meeting notes, Salesforce, Slack, Airtable, and more).

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

Consider the difference. A traditional automation for syncing LinkedIn DMs from Kondo into Lightfield would need to: parse the conversation JSON, extract participant names, fuzzy-match against existing contacts, decide whether to create or update, extract any deal signals from unstructured text, and map them to opportunity fields. That’s six separate problems, each with its own edge cases, each requiring its own conditional logic.

With an agent request, you describe the intent: “Match this LinkedIn conversation to the right contact, create a note summarizing the discussion, and flag any buying signals as opportunity updates.” The agent handles the parsing, matching, and judgment calls. When the data format changes or a new edge case appears, the agent adapts. Your workflow doesn’t need to change.

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. A step late in the pipeline can pull data from the original trigger, from an intermediate HTTP response, and from an AI agent’s structured output all at once.

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.

What this enables

The combination of webhook ingestion, AI reasoning, record writes, and HTTP egress means Lightfield workflows are a general-purpose integration layer for your go-to-market stack. Data flows in from payment systems, conversation tools, meeting platforms, and internal services. AI agents interpret and enrich it. Clean, structured records appear in Lightfield. And when something changes, workflows push that data back out to the systems that need it.

The point is not that AI is involved. The point is that entire categories of integration work that were previously too fragile to automate reliably are now tractable.

See it in practice:

• Building workflows - Detailed reference for triggers, actions, and data flow configuration.
• Workflow recipes - Four end-to-end walkthroughs: Stripe webhook ingestion, LinkedIn DM sync with Kondo, daily Granola meeting digests, and outbound sync.
• How workflows work - Architecture deep-dive: execution model, concurrency control, and reliability guarantees.