
Welcome back to another week of Kaizen!
Over the last couple of weeks, we’ve joined Zylker Cloud Services as they review and improve their workflows. In Part 1, we discovered and audited their sprawling workflow landscape. In Part 2, we learned how to use the Configuration API to understand valid triggers and actions, preventing errors before they happen.
Now, it is time to take action. Zylker has identified the "VP Alert - High Value Deal" workflow as a prime candidate for an update. It is old, has never run, and its logic might be too narrow. We will also explore how to create a new workflow from scratch to handle a new business requirement.
STEP 5: Update an Existing Workflow
From our audit in Step 2, we know that the existing ‘VP Alert - High Value Deal’ workflow (id: 4876876000016390024) hadn’t triggered even once. The original $50,000 threshold missed many valuable deals. Most winning opportunities actually land above $30,000. It has never executed, suggesting the criteria are too strict.
Let us use the Update Workflow Rule API to fix it. We'll change the criteria to trigger for deals greater than or equal to $30,000 and add an additional email notification.
What you can and cannot update
When working with the Update Workflow Rule API, not every field in a workflow is open for modification. Think of it like editing an existing automation blueprint. Some foundations are fixed, while others are flexible.
You can update:
Name and Description
Trigger : You can update triggers, but only within the same trigger type. For example, you can change a Record Action trigger from create to edit, but not from a Record Action trigger to a Score-based trigger. For more details on this, please refer to our detailed help documentation here.
Conditions and Criteria : add, remove, or refine them.
Actions : add new ones, remove existing ones, or update their configuration.
Status : activate or deactivate a workflow rule.
What cannot be updated
There are a few key restrictions to remember:
You cannot change the module associated with the workflow.
You cannot switch trigger categories (e.g., from Record Action to Email Trigger).
You cannot retain unsupported actions when changing to a trigger that doesn’t support them. For instance, if you change a trigger from Edit to Delete, but keep an Assign Owner action, the update will fail, because “Assign Owner” isn’t valid for Delete triggers.
Updating an existing workflow is not about replacing everything. it is about editing precisely what needs to change.
Here is how to do it:
Fetch the workflow details using the Get Workflow Rule API. This gives the full structure, including condition IDs, action IDs, and trigger details.
Identify what needs to change.
In this case, to fix the “VP Alert - High Value Deal” workflow, we can update the Workflow rule to:
lower the threshold to $300,000
change the comparator to greater_than.
To make the workflow more useful, Zylker has also decided to add a few new actions.
But before doing that, the developers needed to confirm which actions are supported for this workflow’s trigger type. That is where last week’s Configuration API comes in handy. Since we already know this is a Record Action trigger (create_or_edit), we can refer to the configuration response we explored in Part 2 to see which actions are valid.
{ "api_name": "create_or_edit", "deprecated": false, "name": "CreateorEdit", "scheduled_actions_supported": true, "actions": [ "field_updates", "assign_owner", "add_tags", "remove_tags", "email_notifications", "tasks", "create_record", "create_connected_record", "add_meeting", "webhooks", "functions", "circuits", "flow" ] }, |
The response clearly shows that email notifications, field updates, and tags are all supported for this trigger type. With that confidence, in addition to updating the condition, we can also add a 'Priority' tag to those records that trigger the Workflow. This makes the workflow more visible and actionable across the sales hierarchy.
Sample Request:
PUT {{api-domain}}/crm/v8/settings/automation/workflow_rules/4876876000016390024
{ "workflow_rules": [ { "description": "Notify sales leadership and track strategic opportunities", "name": "VP Alert - High Value Deal.", "conditions": [ { "sequence_number": 1, "criteria_details": { "criteria": { "group_operator": "AND", "group": [ { "comparator": "greater_than", // change in comparator operator "field": { "api_name": "Amount" }, "value": "300000" // Lowered threshold }, { "comparator": "equal", "field": { "api_name": "Stage" }, "value": "Negotiation/Review" } ] } }, "instant_actions": { "actions": [ { "type": "add_tags", "module": "Deals", "details": { "tags": [ { "name": "Priority" } ], "overwrite": true } } ] }, "id": "4876876000016390025" // id of the condition to be updated } ] } ] } |
After this update, the workflow now triggers for any deal worth more than $300,000 in the Negotiation/Review stage. Apart from sending the email notifications and adding the follow up task, it also tags these deals as Priority.
Edit vs Add:
To edit an existing condition or action, include its existing id in your update payload. Zoho CRM will recognize it as an update to that object.
To add a new condition or action, simply omit the id. CRM treats any object without an ID as a new addition.
STEP 6: Create a new Workflow Rule
With the “VP Alert - High Value Deal” workflow now fixed and performing as expected, Zylker’s sales team quickly began to see results.
But their sales team noticed that deals often stall after proposals are sent, with no systematic follow-up. Zylker has hence refined the requirements for a new Workflow.
They want to automatically trigger follow-up actions when a high-value deal (above ₹30,000) is marked “Closed Lost” due to pricing reasons. This workflow must ensure that every lost opportunity is reviewed, tagged, and re-engaged after a cooling-off period. To achieve this, they want to create a workflow to be triggered whenever a deal’s Stage is updated to Closed Lost. It must perform the following actions:
Add tags Lost due to Pricing and Re-engagement Pending.
Send an email alert to the Sales team, with the details of the failed Deal, so they can look into the reasons.
After 30 business days, automatically create another “Lost Deal - Feedback” task to remind the owner to re-contact the customer for feedback, and for future opportunities.
Before proceeding, Zylker makes an API call to the Workflow Configuration endpoint. This ensures that their chosen trigger type and actions are supported. From the response snippet below, it is clear that a field_update trigger supports scheduled actions and the required action types.
{ "api_name": "field_update", "deprecated": false, "name": "FieldUpdate", "scheduled_actions_supported": true, "actions": [ "field_updates", "assign_owner", "add_tags", "remove_tags", "email_notifications", "tasks", "create_record", "create_connected_record", "add_meeting", "webhooks", "functions", "circuits", "flow" ] } |
With these details validated, we can now move on to adding a new workflow for Zylker using the Create Workflow Rule API request.
Understanding the input JSON structure
Every workflow definition follows the same hierarchy - defining when the rule runs, what conditions it checks, and which actions it performs.
The top-level input object contains a workflow_rules array. You must include just one workflow rule object per request. Each workflow rule defines its name, trigger type, and one or more condition blocks, each with its own criteria and actions.
Here is a breakdown of what is inside a single workflow rule:
{ "workflow_rules": [ { "name": "VP Alert - High Value Deal.", //name of the workflow rule "description": "Notify leadership when high-value deals are lost due to pricing.", "module": { "api_name": "Deals" }, //module to which the workflow applies "execute_when": { ... }, //trigger configuration (e.g., on record edit, field update, etc.) "conditions": [ { "sequence_number": 1, // order of execution. this is the first condition "criteria_details": { ... }, // condition logic (criteria group) "instant_actions": { "actions": [ ... ] }, //instant actions executed instantly cheduled_actions": [ // schedules actions executed after a delay { "execute_after": { ... }, // delay period for the scheduled action "actions": [ ... ] } ] }, { "sequence_number": 2, // second condition "criteria_details": { ... }, "instant_actions": { "actions": [ ... ] } } ] } ] } |

Every workflow rule performs one or more actions like sending an email, creating a task, or updating a field, etc. These actions fall into two broad categories: associative and non-associative.
Type | Description | Example Actions |
Non- Associative Actions | These are defined inside the workflow rule itself. They do not need to exist beforehand. You can configure their details directly within the workflow payload. | Create record, schedule a call, add a meeting, convert records, social actions, create record on email received, assign owner, |
Associative Actions | These are reusable actions created separately in CRM and referenced by their IDs. They can be used across multiple workflows and other automation tools. | Field updates, Email notifications, tasks, Webhooks, Add/Remove tags |
When you create or update a workflow via API, the associative actions require you to pass their existing action IDs. These IDs can be fetched using the corresponding Actions APIs : Field Updates, Email Notifications, Webhooks, and Tasks. In the coming weeks of Kaizen, we will take a closer look at each of these Actions APIs. We will see how to create, manage, and delete them within your workflow automation strategy.
Sample Request:
POST {{api-domain}}/crm/v8/settings/automation/workflow_rules
{ "workflow_rules": [ { "execute_when": { "details": { "trigger_module": { "api_name": "Deals", "id": "4876876000000002181" }, "criteria": { "comparator": "equal", "field": { "api_name": "Stage", "id": "4876876000000002565" }, "type": "value", "value": "Closed Lost" }, "repeat": false, "match_all": false }, "type": "field_update" }, "module": { "api_name": "Deals", "id": "4876876000000002181" }, "description": "Triggers tasks, tags, and follow-up reminders for high-value deals lost due to pricing", "name": "Lost Deal due to Pricing - Follow Up", "conditions": [ { "sequence_number": 1, "instant_actions": { "actions": [ { "name": "Lost Deal - Feedback", "id": "4876876000016794047", "type": "tasks" }, { "details": { "module": { "api_name": "Deals", "id": "4876876000000002181" }, "over_write": false, "tags": [ { "name": "Lost due to Pricing", "id": "4876876000016794071", "color_code": "#658BA8" }, { "name": "Re-engagement pending", "id": "4876876000016794075", "color_code": "#879BFC" } ] }, "type": "add_tags" }, { "name": "Deal Lost Alert", "id": "4876876000016794062", "type": "email_notifications" } ] }, "scheduled_actions": [ { "execute_after": { "period": "business_days", "unit": 30 }, "actions": [ { "name": "Lost Deal - Feedback", "id": "4876876000016794047", "type": "tasks" } ] } ], "criteria_details": { "criteria": { "group_operator": "AND", "group": [ { "comparator": "greater_equal", "field": { "api_name": "Amount", "id": "4876876000000002557" }, "type": "value", "value": "30000" }, { "comparator": "equal", "field": { "api_name": "Reason_For_Loss__s", "id": "4876876000002440001" }, "type": "value", "value": "Price" } ] } } } ] } ] } |
The execute_when defines when the workflow should fire.
type = field_update means this rule runs when a field’s value changes.
criteria : Stage = Closed Lost so the rule triggers whenever the Stage field is updated to Closed Lost.
repeat = false ensures it will not trigger multiple times for the same record.
In simple terms: “Whenever a deal is marked as Closed Lost, run this workflow.” The criteria_details section refines the trigger. The workflow only runs when the Amount ≥ ₹30,000 AND Reason for Loss = Price.
The instant_actions section inside the conditions array has the actions to be executed immediately when the criteria are met.
Add Tags : labels the record for easy filtering and reporting.
Send Email Alert : notifies the sales team instantly about the lost deal.
The scheduled_actions defines what happens after some time has passed. In this case, after 30 business days. Here, the workflow automatically creates a “Lost Deal - Feedback” task, reminding the deal owner to follow up with the customer to get feedback, and for future opportunities.
By combining these elements, this workflow achieves a full closed-loop follow-up system.
Conclusion:
Zylker’s updated and new workflows make their automation smarter and more responsive. They are now able to spot key deals and ensure lost opportunities are revisited.
We hope you are now well on your way to mastering Workflow APIs. Share your thoughts in the comments or write to us at support@zohocrm.com.
