Agent Triggers

Most of the time, an agent waits to be asked. Someone opens a chat, types a question, or calls the API, and the agent responds. Triggers flip that around. A trigger lets a deployed agent act on its own the moment something happens in your business, no human in the loop, no button to press. A lead gets created, an invoice is raised, a ticket comes in, and the agent is already at work.

This solves one of the harder parts of putting an agent to work: connecting it to the product where the action actually happens. Before triggers, wiring an autonomous agent into a Zoho service meant writing a workflow or a script inside that product to call the agent at the right moment. Triggers replace all of that. You point the agent at an event, and it starts responding automatically. No custom code, no per-product setup.

How triggers work

A trigger sits on top of two things working together: a publisher and an event.

A publisher is the connection between Zia Agents and a Zoho service, the source that watches for things happening and reports them back. You set up publishers once, at the organization level, in Settings. Think of a publisher as the pipe; it knows how to listen to a service like Zoho CRM or Zoho Books and pass along what occurs there.

An event is the specific thing you're listening for: a lead created, a deal updated, an invoice approved, a ticket closed. A trigger is the rule that ties them together. It says: when this event happens on this publisher, run this agent, and hand it this data.

Publishers are powered by Zoho Signals, which is why you'll see the term "publisher" used consistently across the setup. The practical upshot is that Zia Agents can listen to a growing list of Zoho services directly, without each product team having to build a separate integration.

Before you begin

Two things need to be in place before you can add a trigger.

The agent must be deployed. The Triggers tab only appears on the agent details page after the agent is deployed. This isn't an arbitrary gate. Deployment is where the agent's tools get their parameter mappings and connections, and a trigger needs those mappings to know how to act. Before deployment, there's nothing for a trigger to hook into, so the tab stays hidden. If you don't see Triggers, deploy the agent first. See Deploying Agents.

You need a publisher for the service. The trigger has to know which service and account to listen to, and that's what a publisher provides. You can set publishers up ahead of time in Settings > Publishers, or create one inline while adding the trigger. See Publishers for the full setup.

Adding a trigger

Open the Triggers tab on your deployed agent's details page and click Add Triggers. The setup runs in two steps.

Step 1: Choose the service and publisher

Pick the service you want the agent to respond to from the list, then select a publisher for it under Select Publisher. If you haven't created a publisher for that service yet, the dropdown shows + Create New, which opens the publisher setup so you can create one without leaving the flow. Once a publisher is selected, click Next.

Step 2: Configure the trigger

This is where you define exactly what the agent listens for and how much it sees.

Choose the event. Open the Trigger dropdown and pick the event that should set the agent off. Events are grouped by module, so for Zoho CRM you'll find them under Leads, Accounts, Deals, and so on, with events like Lead Created, Account Updated, or Deal Approved. The search box at the top helps you find one quickly.

Filter which events qualify. Under Filter, you decide whether every occurrence of the event should run the agent, or only the ones that meet certain conditions.

• All Events: The agent runs on every occurrence. Every new lead, every update, no exceptions.
• Only events matching conditions: The agent runs only when the record meets a condition you define. This opens a criteria builder where you choose a module, a field, an operator, and a value, for example, run only when Lead Source is Online Store. You can add multiple conditions with + Add Filter and combine them using the Criteria Pattern expression.

Set the session key. Under Execution Settings, the Session Key controls how trigger data is grouped before it's handed to the agent. By default it's the record ID, so each record produces its own session, but you can group by other fields instead. Grouping decides what the agent treats as one unit of work versus separate runs.

Choose how much data to send. The Fields to Pass setting determines how much of the record reaches the agent, and this choice matters more than it first appears.

• Pass all fields: The agent receives the complete record. Simple, but a full record can be large.
• Select specific fields: You hand the agent only the fields it actually needs, per module, with + Configure more fields to add selections from related modules.

Sending fewer fields has real benefits. It reduces token consumption and cost, speeds up the agent's response (a trimmed payload can be processed in seconds, while a large one takes longer), and gives you control over privacy, you can simply withhold sensitive fields the agent has no reason to see. When in doubt, send only what the task requires.

Adding more than one trigger

An agent can have several triggers. Use + Add Trigger to configure additional events on the same publisher, each with its own filter, session key, and field selection. If you've already built triggers on another version of the agent, Copy from Another Version brings them over so you don't have to rebuild them by hand.

When you're done, click Save. The trigger goes live immediately, the agent will start responding to matching events from that moment on.

What happens when a trigger fires

Once a trigger is live, the next matching event runs the agent automatically. The event data, filtered down to the fields you chose, becomes the agent's input, and the agent works through it using its configured instructions and tools, exactly as it would for a manual run, just without anyone kicking it off.

You can watch these runs on the Observability tab. A trigger-fired run shows up as a new session, and in its execution details the Execution Source reads Triggers, which is how you tell an automatic run apart from one started manually or through the API. From there you can open the step timeline to see exactly what the agent received, which tools it called, and the response it produced. See Observability for the full breakdown.

Managing triggers

The Triggers tab lists your triggers grouped under the service and publisher they belong to. Each trigger shows its event, filter summary, and session key at a glance. For each one you can:

• Enable or disable it with the toggle. Disabling stops the agent from responding to that event without deleting the configuration, useful when you want to pause automation temporarily.
• Edit or remove it from the actions menu.

Limits and considerations

Trigger creation is subject to limits at two levels: an overall cap per organization, and a separate cap per service. The per-service limit is shared with any triggers created directly through Zoho Signals for that service, so existing Signals usage counts against what's available in Zia Agents. These limits exist on the Signals side and may change as the feature evolves; the product will let you know if you reach one.

A few more things worth knowing as you plan:

• An agent can be deployed to more than one target, and triggers are configured independently of where the agent is deployed.
• Support is expanding. Custom third-party signals (bring-your-own events from your own apps or websites) and Zoho Flow's broad catalog of Zoho and external services are on the way, which will let a trigger originate from a source outside the native Zoho list.

Triggers vs. integrations

It's easy to confuse triggers with the integrations on the Integrate tab, since both make a deployed agent usable in the real world. The difference is direction. An integration gives people a way to talk to the agent, a chat widget, a Cliq bot, a WhatsApp number. A trigger lets an event tell the agent to act, no conversation required. Reach for triggers when the agent should run autonomously in response to what's happening in your data, and for integrations when a person needs to start the interaction. See Integrating Agents.