Automations

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

The problem with traditional automation

Say you want to open an opportunity whenever a prospect shows real buying intent. In a traditional automation tool, you have to reduce “buying intent” to something the tool can check: a specific email subject line, a form submission, a stage someone sets by hand. The tool can’t sit in on a sales call and decide there’s a deal worth tracking, so you encode a proxy and hope it correlates.

Then reality hits. Intent shows up in a meeting where the champion says “we’re ready to move forward next quarter,” in a thread where pricing finally comes up, in a renewal call that turns into an upsell. A rule keyed on a stage field misses all of it, and fires on plenty of deals that aren’t real. And even when it fires, creating the opportunity correctly takes judgment: which account it belongs to, a sensible amount and stage, whether one already exists. Judgment is exactly what a decision tree can’t supply.

A different approach

A Lightfield automation is a sequence of AI steps that the agent builds with you in chat. You don’t open a node editor or write conditionals; you describe the outcome (“when a meeting signals a real deal, open an opportunity on the right account”) and the agent programs the trigger and steps for you.

What makes this different from a hand-assembled pipeline is that every step reasons over your full customer context, not just the fields in a payload. The step is an agent with access to your meetings, emails, accounts, and opportunities, plus the Skills and knowledge your team has already built. It reads the transcript, confirms there’s genuine intent, matches the right account, checks whether an opportunity already exists, and creates one with an amount and stage that fit, the same judgment you’d apply in chat.

The agent is your automation engineer

You don’t build automations in a node editor. Lightfield’s agent acts as your automation engineer. To automate something in your go-to-market motion, you describe what you want in chat and the agent “programs” it for you, generating an automation with a name, a description, and an ordered set of steps, organizing the steps and the flow of context based on its capabilities and the outcome you described.

Automations are first created as a draft by the agent in chat. You can test run and edit a draft iteratively until it does what you want. Once it’s drafted and tested, you can activate it, and later pause or update it with further changes.

Triggers

Every automation runs on a set of triggers it listens for.

• Scheduled triggers fire on a cadence: every morning at 8am, weekly, monthly, or a custom schedule, all timezone-aware.
• Event triggers fire when something happens in your CRM: an account is created, an opportunity is updated, a watched field value changes.
• Webhook triggers fire on an inbound HTTP event: a customer is created in Stripe, a message is received in LinkedIn, an internal tool posts a payload.

Runs

When triggered, an automation starts a new run. In each run the agent follows the step-by-step instructions in a series of turns until completion. Steps execute in a shared “thread,” so later steps have full access to what earlier steps produced, and context flows between steps automatically, with no manual wiring.

The agent watches each step for completion and marks one failed if it detects an error. You and the agent can both look back over any run (from the run details page or from chat) to troubleshoot and improve it together.

One constraint to keep in mind: runs execute to completion without interruption. You cannot follow up or approve actions mid-run. Human-in-the-loop review happens after a run, through For review.

Tools

The tools available in automations span the full set available in chat plus our API capabilities. Across its steps, an automation can:

• Create and update records, Skills, and knowledge;
• Generate objects like tasks, notes, and files;
• Use connectors, Skills, and knowledge;
• Make network requests and use workspace secrets for authentication;
• Draft emails for user review.

Permissions

Before testing or activating an automation, the agent asks you to grant permissions for the tools each step will use. Permissions are defined per step: an explicit list of exactly which tools, connectors, APIs, and integrations that step is allowed to use, each with a reason. Anything outside that list is blocked. You see the full set of permissions for all steps and approve it before the automation can run on its triggers.

Run as

Automations can run as a generic workspace member (giving the run only workspace-shared context from records, objects, and activity) or run as a specific user with their unique context.

The specific user can be predetermined or variable based on the trigger (for example, the opportunity owner when triggering on an opportunity-created event). When an automation runs as a specific user, it uses their permissions and connected accounts, and the run becomes private to them and to workspace admins.

For review

When automations run, they can automatically create or update records and objects in the CRM, or they can draft them for review.

For review is a companion surface to automations that enables human-in-the-loop workflows with the agent. Drafts produced by an automation run are assigned a reviewer by the agent when they’re generated and show up in that reviewer’s For review queue. A member’s most recent For review items appear at the top of Up next, alongside their meetings and tasks, and the full list is available from the For review page in the global sidebar, a dedicated queue of pending work produced by automations, where items can be approved or dismissed.

For now, email drafts are the only available review item type: an automation can draft an email and route it to a reviewer to approve and send. Record creation, record updates, and more are coming to For review.

For how drafts are routed to reviewers and what approving or dismissing one does, see How For review works.

Where to go next

• Building automations: triggers, steps, permissions, run as, and the draft-test-activate lifecycle.
• How automations work: execution model, reliability, and operational guarantees.
• How For review works: the human-in-the-loop surface for approving the drafts automations produce.