Skip to main content

React to a Zoho CRM Event

Not every flow starts with a conversation. This one starts inside your CRM: whenever a record is created, edited, or deleted in Zoho, Flowera can wake up a flow, inspect the change, and act on it. In this tutorial you'll trigger a flow on a new Zoho Lead, then use a Condition to take different actions depending on the record.

What you'll build: an automation that runs when a Lead is created in Zoho CRM and branches based on the record's data.

Nodes you'll use:

Concepts to know:

Connect Zoho first

This flow assumes your Zoho CRM connection (OAuth) is already set up in Flowera. See the Zoho trigger page for the connection prerequisites. Flowera auto-subscribes to the events you pick using Zoho's watch API.

Step 1 — Add the Zoho trigger​

Create a new AgentFlow. On the Start node, add a Zoho CRM webhook trigger and configure it:

  1. Webhook Name — give it a clear name like zoho-leads. This name is how you reference the event's data in variables ({{$webhook.zoho-leads.*}}), so set it now and keep it consistent.
  2. Zoho Connection — pick your connected Zoho account.
  3. Module — choose the record type to watch. Zoho exposes many modules (Leads, Contacts, Deals, Accounts, Tasks, and more); for this tutorial choose Leads.
  4. Zoho Events — choose which changes fire the flow: create, edit, or delete. Enable create.

Step 2 — Understand the event payload​

When a Lead is created, the flow starts with a Zoho-specific payload. These fields live under the webhook's name (zoho-leads), so you reference them as {{$webhook.zoho-leads.<field>}}:

  • {{$webhook.zoho-leads.module}} — the module that changed (e.g. Leads)
  • {{$webhook.zoho-leads.operation}} — create, edit, or delete
  • {{$webhook.zoho-leads.ids}} — the affected record IDs
  • {{$webhook.zoho-leads.record}} — the record's fields
  • {{$webhook.zoho-leads.serverTime}}, .affectedFields

You'll read these to decide what to do. (The full payload list is on the Zoho trigger and Variables pages.)

create / edit / delete share one trigger

The operation value tells you which happened. If you enable more than one event, branch on {{$webhook.zoho-leads.operation}} early so create, edit, and delete each get the right handling. (Payload fields are under {{$webhook.<name>.*}}, not {{$flow.state.*}} — the flow-state form resolves empty.)

Step 3 — Branch on the record​

Add a Condition node and connect the Start node to it. Unlike the AI-powered Condition Agent, a plain Condition checks the rules you set and gives you one output handle per rule, plus a trailing Else for records that match none of them.

Set up a rule on a field from the record — for example, route high-value leads differently:

  • Condition: the record's Lead_Source (or a score field) matches a target value.
  • Rule 0 branch → the "hot lead" path.
  • Else branch → the standard path (the rule didn't match).
Condition vs Condition Agent

Use a Condition for a clear, rule-based check (a field equals X). Use a Condition Agent when the decision needs judgment about unstructured text. For CRM fields, a plain Condition is usually the right, predictable choice.

Step 4 — Act on each branch​

Wire an action to each output.

  • Rule 0 (hot lead): add an Agent that drafts a personalized outreach, or an HTTP node that posts a Slack/webhook alert to your sales team (see Calling an external API).
  • Else (standard): add a lighter action, or an HTTP node that writes the lead into a nurture list.

Reference the record's fields inside these nodes with {{ }} variables so each action is tailored to the actual record.

Step 5 — Save and test​

Save the flow. Then, in Zoho CRM, create a test Lead that matches your rule — the flow should fire and take the hot-lead path (branch 0). Create another that doesn't match, and confirm it takes the Else path.

Every run is recorded — inspect the trace and node outputs under Executions to confirm the branch and actions behaved as expected.

What you learned​

  • A Zoho trigger starts a flow on create / edit / delete for a chosen module.
  • The event payload carries operation, ids, and the record fields for you to read.
  • A Condition node gives one branch per rule plus an Else, taking the first rule that matches — ideal for rule-based CRM logic.
  • Each branch can act with an Agent, an HTTP call, or any other node.

Next steps​