
But as their automated ecosystem has grown to nearly 100 workflow rules, a new challenge has emerged for the system administrators: Are these workflows actually doing what they were built to do? Are these automations actually working day-to-day?
A workflow can be perfectly configured yet have no impact if it never runs. A webhook could be sending data to a dead endpoint, or a critical email notification might go silent without anyone noticing.
While the CRM UI allows them to click into any single workflow to see its execution details or check the status of a specific webhook, this data is trapped in dozens of individual screens. To answer strategic questions like "What's the overall health of our automation?" or "Where should we focus our optimization efforts?", they would need to manually open, check, and compile data from over a hundred different places.
This is where the Reporting APIs become indispensable. They allow Zylker to aggregate all this scattered UI data into their central dashboard, which supports proactive governance at scale.
Using Get Actions Count in Workflow Rules
During their initial audit, Zylker noticed something interesting: within the same module, some workflows had just one or two actions, while others had ten or more bundled together. While this inconsistency wasn't necessarily wrong, after years without a cleanup they wanted to review which workflows had become particularly complex and decide whether they needed updating or splitting.
To identify such rules systematically, they call:
GET {api-domain}/crm/v8/settings/automation/workflow_rules/actions/actions_count?ids={id1, id2, id3, ..}
This API returns a detailed count of how many actions each rule contains. Using the response from API, the admins can choose to work on the Workflow Rules by complexity. In the UI, this requires inspecting workflows one by one. But using this API, up to 100 Workflows can be inspected in a single API call. The entire system can be analyzed in a matter of seconds!
Here is what the response looks like:
|
{ "workflow_rules": [ { "id": "4876876000016390024", "conditions": [ { "sequence_number": 1, "instant_actions": { "actions_count": [ { "type": "field_updates", "value": 1 }, { "type": "add_tags", "value": 1 }, { "type": "email_notifications", "value": 1 }, { "type": "webhooks", "value": 1 } ] }, "scheduled_actions": [ { "actions_count": [ { "type": "tasks", "value": 1 } ] } ], "id": "4876876000016390025" } ] }, { "id": "4876876000011208001", "conditions": [ { "sequence_number": 1, "instant_actions": { "actions_count": [ { "type": "assign_owner", "value": 1 } ] }, "scheduled_actions": null, "id": "4876876000011208002" }, { "sequence_number": 2, "instant_actions": { "actions_count": [ { "type": "assign_owner", "value": 1 } ] }, "scheduled_actions": null, "id": "4876876000011208004" }, { "sequence_number": 3, "instant_actions": { "actions_count": [ { "type": "assign_owner", "value": 1 } ] }, "scheduled_actions": null, "id": "4876876000011208006" } ] } // ...other workflow rules omitted for brevity ] } |
The response is a granular breakdown, not just a simple total. For each workflow rule (id), you see every condition (sequence_number). Within each condition, the actions_count array under instant_actions and scheduled_actions lists the type of each action (email_notifications, webhooks, tasks, etc.) and the count (value) of that specific action type in that section.
In simple terms, the API tells us: For every workflow, for every condition, how many actions does it perform, and what kind are they?
Using get Workflow Rule usage report API
Identifying complex workflows is important, but Zylker’s admins also need to figure out if they are are actually working. This is a crucial part of automation governance.
A workflow might be executing regularly, but an email notification configured inside it may bounce every time. A webhook may silently fail due to a server issue. These operational issues are difficult to detect by simply knowing whether a workflow has executed.
In the CRM UI, admins can click View Usage for a workflow. But this still exposes information one rule at a time and without aggregation across rules. When you operate nearly a hundred workflows, this method does not scale.
To understand action-level outcomes inside a specific workflow, Zylker uses:
GET {api-domain}/crm/v8/settings/automation/workflow_rules/{workflow_rule_ID}/actions/usage?executed_from={from_date}&executed_till={to_date}
This API returns rich statistics, including:
how many times the workflow executed
how many times each action inside it succeeded or failed
delivery metrics for emails (open, sent, delivered, bounced, clicked)
scheduled vs. instant action performance
which conditions executed successfully
Here is a sample response:
|
{ "workflow_rules": [ { "trigger_count": 3, // Total times this workflow was triggered "name": "High Value Lead Rule", // Workflow name "id": "4876876000013248001", // Workflow ID
"conditions": [ // Usage details grouped per condition { "instant_actions": { "actions": [ //Instant actions execution details { "queue_count": 0, //Asynchronous actions pending for execution in the queue "related_details": { //Email delivery metrics for bulk email_notifications actions "bulk_mail": false, "unopened": 0, "sent_percentage": 100, "opened": 1, "delivered": 1, "unsent": 0, "bounced": 0, "clicked": 0, "sent": 1 }, "name": "High revenue Lead added", //Action name "success_count": 1, // Number of successful executions "failure_count": 0, // No failures for this action "id": "4876876000016390103", // Action ID "type": "email_notifications", // Action type "associated_time": "2025-10-16T16:19:58+05:30" // When this action was added to the workflow }, ...... //omitted for brevity
] },
"scheduled_actions": [ // Scheduled actions usage metrics { "id": "4876876000016390118", // ID of the scheduled action block "actions": [ { "queue_count": 0, //Asynchronous actions pending for execution in the queue "related_details": { //Email delivery metrics for bulk email_notifications actions "bulk_mail": false, "unopened": 0, "sent_percentage": 100, "opened": 1, "delivered": 1, "unsent": 0, "bounced": 0, "clicked": 0, "sent": 1 }, "name": "High revenue Lead added", "success_count": 1, // Number of successful executions "failure_count": 1, // Number of failures "id": "4876876000016390103", "type": "email_notifications", "associated_time": "2025-10-16T16:19:58+05:30" } ] } ],
"usage_count": 2, // The number of times this condition matched "id": "4876876000013248002" // Condition ID },
// more condition blocks omitted for brevity ],
"reset_time": "2025-10-16T16:23:04+05:30" //When usage metrics were last reset } ] }
|
This single API call provides what would take hours of manual UI investigation, i.e., a complete performance audit. By scripting this for their key workflows, Zylker transforms workflow management from a time-consuming manual task to an easy, automated process.
The workflow usage report gave Zylker deep insight into individual workflows. But they still have unanswered questions about their external integrations.
Zylker relies on webhooks to push deal data to their project management tool, sync contacts to their marketing platform, and notify their support system. A single failing webhook can break an entire business process, and these failures often happen silently.
The CRM UI provides detailed views of each webhook's activity. However, identifying patterns across all integrations, like silent failures or volume anomalies, requires manually consolidating data from multiple screens. For teams with many integrations, this consolidation becomes time-consuming to perform regularly.
Zylker solves this by using the Webhooks Actions Usage Report API to get time-series data for all integrations at once, followed by the Get Action Failures API for diagnostics.
3.1 Track volume trends and spot anomalies using Webhooks Actions Usage Report API
They call the usage report API grouped by date and resource to see daily call volumes:
GET {api-domain}/crm/v8/settings/automation/webhooks/actions/usage_reports?group_by=date,resource&type=webhooks&from_date={date}
Sample Response:
|
{ "data_usage": [ { "date": "2025-12-09", "resource": { "name": "Premium Lead Alert", "id": "4876876000016390771" }, "count": 4, "type": "webhooks" }, { "date": "2025-12-09", "resource": { "name": "Deal to Project Sync", "id": "4876876000017550012" }, "count": 4, "type": "webhooks" }, { "date": "2025-12-09", "resource": { "name": "Contact to Marketing Platform", "id": "4876876000017550018" }, "count": 8, "type": "webhooks" }, { "date": "2025-12-08", "resource": { "name": "Deal to Project Sync", "id": "4876876000017550012" }, "count": 8, "type": "webhooks" }, // ...omitted for brevity ... { "date": "2025-12-07", "resource": { "name": "Deal to Project Sync", "id": "4876876000017550012" }, "count": 1, // Anomaly: very low number "type": "webhooks" }, // ... remaining entries omitted for brevity ... ], "info": { "max_limit": 2500, "per_page": 200, "count": 12, "page": 1, "more_records": false } } |
The response provides a daily log of which webhooks fired and how often. The real insight comes from analyzing two key patterns:
Missing activities: If a webhook that typically appears daily suddenly has no entries for multiple days, it indicates the upstream workflow has stopped. This is a silent business process failure.
Volume Anomalies: If a normally steady webhook shows a 300% spike in daily calls, it could indicate system errors generating duplicate records, or legitimate business surges worth investigating.
From the response data, Zylker can instantly spot that the Deal to Project Sync webhook's execution dropped to just 1 call on a specific day, which is a volume anomaly. Meanwhile, the Premium Lead Alert webhook may be missing entirely from recent dates, which is a missing activity alert.
3.2 Investigate Webhooks failures with Get Action Failures API - Webhooks
Volume anomalies tell Zylker that something is wrong. To understand what went wrong and where, they need detailed failure diagnostics.
For this, they use the Get Action Failures – Webhooks API:
GET {api-domain}/crm/v8/settings/automation/webhook_failures?from=2025-10-15&to=2025-10-22
You can optionally filter by:
webhook_id : to focus on a specific webhook
module : to see failures only for a specific module
from and to : to restrict the date range (max 90 days).
Sample Response:
|
{ "webhook_failures": [ { "webhook": { // The webhook that failed "name": "Premium Lead Alert", "id": "4876876000016390771" }, "entity_details": { // Record that triggered the webhook "module": { "api_name": "Leads", "id": "4876876000000002175" }, "name": "Freelancer.com", "id": "4876876000016474049" }, "failure_time": "2025-10-21T17:08:07+05:30", // When the failure occurred "failure_reason": "page_notfound", // Why it failed (e.g., page_notfound, unauthorized, timeout) "id": "4876876000016474075", // Failure entry ID "workflow_rule": { // Workflow that triggered this webhook "name": "WF-C", "id": "4876876000016390881" } }, //... omitted for brevity ], "info": { "per_page": 200, "count": 17, "page": 1, "more_records": false } } |
With a single request, Zylker now has a clear picture of exactly which workflows are causing failures, which records are impacted, and the precise technical reason for the failure. With this information at hand, they can promptly fix the issues and ensure that critical integrations do not silently break.
Emails sent through workflows drive essential actions at Zylker. Sales managers get notified when high-value leads enter the system, account directors get alerted on lost deals, and service teams receive escalations. If these triggered emails are not sent consistently or begin spiking unexpectedly, decision-makers may be blind to critical updates.
To understand how workflow-triggered emails are being used over time, Zylker uses the Email Notification Actions Usage Report API.
Sample Request:
GET {api-domain}/crm/v8/settings/automation/email_notifications/actions/usage_reports?group_by=date,resource,type&type=email_notifications&from_date=2025-12-01
Sample Response:
|
{ "data_usage": [ { "date": "2025-12-09", // When the email was triggered "resource": { "name": "Lost Deal Alert", // Email notification name "id": "4876876000013500873" }, "count": 5, // Number of times it was sent that day "type": "email_notifications" }, { "date": "2025-12-09", "resource": { "name": "High Value Lead Notification", "id": "4876876000016390889" }, "count": 2, "type": "email_notifications" }, { "date": "2025-12-08", "resource": { "name": "Lost Deal Alert", "id": "4876876000013500873" }, "count": 8, // Higher usage on this day "type": "email_notifications" } // ... additional entries omitted ], "info": { "max_limit": 2500, "per_page": 200, "count": 18, "page": 1, "more_records": false } } |
By reviewing usage trends over time, Zylker can spot early signs of issues at either layer. If an email notification that normally triggers every day suddenly shows zero usage, it could mean the workflow condition has stopped matching, or it might indicate a failure due to factors like bounced addresses, inactive users, or restricted mail settings. Likewise, an unexpected spike in email executions might reveal either a legitimate business surge or a workflow repeatedly triggering because of duplicate records, import errors, or incorrect criteria.
In either case, Zylker is now in a position to take informed decisions.
Zylker began this journey wanting stronger workflow automation. Along the way, they learned how to discover, configure, update, and extend workflow rules and actions using APIs. But as their automation ecosystem grew, a new responsibility emerged regarding governing what they had built.
The Reports APIs complete that responsibility.
Action Counts reveal how complex each workflow has become
Workflow Usage Reports show whether actions are actually executing, succeeding, or quietly failing.
Webhook Usage and Failure Reports give a clear picture on the Webhook execution health.
Email Usage Reports highlight patterns in email communication actions.
With this complete toolkit, Zylker no longer just has automations. They understand them, analyze them, and continuously improve them. Their workflows have evolved from fragile scripts to managed business assets with known performance characteristics and early warning systems.
This concludes our Kaizen series on Workflow & Actions APIs. We hope this series has helped you to build, manage, and govern automation systems in your own organization.
If you have any feedback or questions, please let us know in the comments or reach out to us at support@zohocrm.com.
Until next time, Happy coding!

