[object Object]

Trigger Types

Create, edit, field update (specific field changes), record conversion (Lead → Contact + Account + Deal), time-based (X days after Y date field), and scheduled (run on cron without an event trigger). The “edit” trigger fires on every save, which is broad — narrow it to a specific field-change condition wherever possible. Time-based triggers reference a date field and an offset, so “renewal_date - 60 days” produces a renewal-warning workflow. Each module has its own trigger limits — CRM Enterprise allows 10 active workflow rules per module; Ultimate raises this.

Actions

Field updates, tasks, notifications (email or in-app), email templates, webhooks, custom functions (Deluge), tag assignment, and convert-to-record. Multiple actions per workflow execute in defined order; ordering matters when later actions depend on earlier field updates. The Webhook action posts a JSON payload to your configured URL with HMAC signature for verification. Custom Function action passes the triggering record as the input map.

// Custom function action — assign deal owner based on territory
deal_id = input.deal_id;
deal = zoho.crm.getRecordById("Deals", deal_id);
state = deal.get("Billing_State");
owner_map = Map();
owner_map.put("CA", "[email protected]");
owner_map.put("NY", "[email protected]");
owner_map.put("TX", "[email protected]");
new_owner = owner_map.get(state);
if (new_owner != null) {
    zoho.crm.updateRecord("Deals", deal_id, {"Owner": {"email": new_owner}});
}

Scheduled Workflows

Run on field-date conditions — “renewal_date = 30 days from today” fires daily and matches any record where the condition evaluates true. Useful for renewal reminders, no-touch alerts, contract expiry warnings, and aging follow-ups. Schedule resolution is daily, not hourly, so anything time-sensitive within the day needs a different mechanism (Zoho Flow scheduled flow or Catalyst cron). Scheduled workflows count against the per-module workflow rule limit.

Testing

Test with a sample record that matches your trigger condition. Confirm the trigger fires (visible in the record’s Timeline and the Workflow Audit Log). Confirm each action executes — emails delivered, webhooks received with 2xx response, custom functions logged success. Function Logs under Setup → Functions show inputs, outputs, and any caught exceptions. Sandbox testing before production deployment is mandatory for any workflow with destructive actions (mass field updates, convert-to-record, delete).

Maintenance

Disable stale workflows quarterly. A workflow firing 10x expected volume usually indicates a broken trigger condition (e.g. an “edit” trigger that should have been “field update on Status”). The Workflow Audit Log shows execution counts per workflow per day; spikes are the early signal. Document each active workflow with purpose, owner, and last-reviewed date in a shared register — orphan workflows accumulate as admins rotate.

Common Failure Modes

Recursive triggers: Workflow A updates Field X, which fires Workflow B, which updates Field Y, which fires Workflow A. Set “Recursion: do not re-trigger” on edit-based workflows that update fields. Email action without a verified sender domain: emails go to spam. Webhook action without retry logic: a single 500 from your endpoint loses the event permanently.

What to do this week

Pull the Workflow Audit Log for the last 30 days, identify any workflow firing more than expected, and add a recursion-prevention check on every edit-triggered workflow that updates fields.

[object Object]
Share