FAQs: Automation Studio

FAQs: Automation Studio

1. What is Automation Studio?
Automation Studio is a user-friendly, no-code automation solution in Zoho Desk that provides a visual interface to design, view, and control automation flows. It allows administrators to see the complete sequence and order of execution at a glance, making it easier to build, understand, and maintain complex automations.

It overcomes the limitations of traditional workflows by supporting:
  1. Asynchronous execution — Multiple rules and actions can run simultaneously without waiting for one to complete.
  2. Parallel execution — Using fork blocks, a flow can split into up to 5 independent branches that execute at the same time.
  3. Conditional logic — If blocks allow the flow to proceed only when specific criteria are met.
  4. Scheduled actions — Delay blocks can pause a flow for a fixed duration or until a specific date/time.
  5. Action chaining — The output of one action can be used as the input for another, enabling seamless data flow between steps.
2. How is Automation Studio different from workflow rules?
Automation Studio is designed to build and manage broader, multi-step automation processes, while workflow rules are primarily used to trigger specific actions when defined conditions are met. Workflow rules are suitable for straightforward, condition-based automations, whereas Automation Studio is better suited for processes that involve multiple steps, actions, or decision points.
3. How is Automation Studio different from custom functions?
Automation Studio is used to design and orchestrate an automation process, while custom functions are used to execute custom business logic through Deluge scripts. Custom functions can perform complex calculations, manipulate data, or integrate with external systems, and can also be used as an action within an automation process.
4. How does Automation Studio fit into overall automation execution order?
When an event occurs, automations execute in a specific hierarchy:
  1. Direct Assignment Rules
  2. Workflows
  3. SLAs
  4. Round Robin Assignment
  5. Blueprints
  6. Notification Rules
  7. Automation Studio.
Because Automation Studio runs asynchronously and executes last, it can leverage outcomes produced by all preceding automations. However, this also means it may override changes made by those earlier automations. Administrators should be mindful of this when designing rules to avoid unintended data conflicts. Additionally, if multiple Automation Studio rules are triggered by the same event, all matching rules execute simultaneously — the order between them cannot be guaranteed.
5. What are the four block types available in Automation Studio, and how do they differ?
  1. Action — Performs a specific operation such as sending an email alert, updating a field, assigning a ticket, or executing a custom function. Multiple action blocks can be chained in sequence.
  2. If — Adds conditional logic. The flow continues only if the defined criteria is met; otherwise, that path terminates. For instance, an If block can check whether a ticket's priority is High before assigning it to a senior team.
  3. Fork — Splits the flow into up to five independent branches that execute simultaneously. Each branch can contain its own logic and actions. This is useful when different teams or product lines need to be handled in parallel.
  4. Delay — Pauses the flow for a fixed duration or until a specific date and time. This enables scheduled actions, such as waiting seven days after a ticket closes before sending a satisfaction survey.
6. What is action chaining?
Action chaining allows the output generated by one action block to be used as input for a subsequent action. For example, a Generate Content action can produce an AI-powered summary of a customer's complaint, and the next action — sending an email reply — can use that summary as the email body.

This creates a seamless data flow within a single rule, eliminating the need for manual intervention or separate integrations. Traditional workflows do not support this capability; each action runs independently with no data passing between them.
7. Can Automation Studio work with custom modules?
Automation Studio supports both standard and custom modules. For example, a manufacturing organization using a custom "Site Inspections" module can create a rule that triggers when a site inspection record is updated. If the inspection status changes to "approved," the rule can automatically update the associated ticket's status in the Tickets module. This cross-module capability is achieved through dot walking, which allows fields from related modules to be accessed and updated within a single flow.
8. What does it mean that Automation Studio executes asynchronously?
Asynchronous execution means that Automation Studio rules run independently of other automation processes and do not block or wait for other rules to complete. When a ticket is created, for instance, Automation Studio can simultaneously send an email to the customer, notify a team lead, and update the ticket priority — all in parallel. This contrasts with synchronous workflow execution, where actions are processed one at a time in a fixed sequence. The practical benefit is faster, more efficient automation that can handle complex, multi-step processes without creating bottlenecks.
9. How does Automation Studio compare to Workflow Rules in terms of scheduled actions?
Workflow Rules execute all actions immediately when triggered — there is no native ability to pause or schedule a delayed action. Automation Studio, by contrast, includes a Delay block that can pause the flow for a fixed duration or until a specific date and time. This makes it possible to build time-aware processes such as sending a reminder email three days after a customer's last response, or triggering a warning alert two weeks before a contract expires — all within a single rule without requiring separate time-based rules.


Building Blocks

10. What role do events play in an Automation Studio rule, and can a single rule have multiple events?
Events are the triggers that initiate an automation flow. They determine when a rule begins execution — for example, when a ticket is created, when a field is updated, or when a comment is added.

A single rule can be triggered by multiple events, which is particularly useful when the same set of actions should apply regardless of how the trigger occurs. For instance, a rule designed to assign escalated tickets to a support manager can use two events: "Ticket Created" with the criteria that the status is Escalated, and "Field Updated" with the criteria that the status changed from Open to Escalated. Both events share the same action, ensuring consistent handling without duplicating rules.
11. Is it possible to apply criteria to an event?
Yes. Criteria can be attached to each event to ensure the flow executes only under specific conditions. For example, if an event is set to "Ticket Created" with the criteria "Product Name is zPad," the rule will only trigger when a ticket for the zPad product is created — not for every ticket. This keeps automations targeted and prevents unnecessary execution.
12. What is dot walking, and how does it simplify automation configuration?
Dot walking is a technique that allows you to access fields from related modules directly within a rule configuration, without needing to create additional queries or actions. For example, while configuring a workflow on a Ticket record, you can access the contact's email address or the account's name from the related Contacts or Accounts module.

This makes it easier to use related data in conditions, actions, and notifications without manually fetching records from another module. In practice, this means a rule triggered by a change in a custom module like "Site Inspections" can update a field in the standard Tickets module by walking the relationship between the two.
13. How does action chaining works?
When multiple action blocks are added to a flow, they execute in the order configured. Action chaining goes a step further — it allows the output generated by one action to be passed as input to a subsequent action. Every action block is automatically assigned a unique identifier (such as 1, 2, or 3) during configuration.

This identifier is prefixed to the action's output variables, making it easy to distinguish data generated by different actions within the same workflow. For example, if Action 1 generates an AI summary of a ticket, Action 2 can reference that summary by its prefixed variable name when composing an email reply. Without action chaining, each action would run independently with no ability to share data.
14. How many Generate Content (Zia) action can be used in a single rule?
The Generate Content action, which uses Zia to produce AI-generated content such as ticket summaries — can only be configured once per rule. If multiple AI-generated outputs are needed, separate rules would need to be created.
15. What happens when an If block's condition is not met?
When an If block evaluates its criteria and the condition is not satisfied, that specific path within the flow terminates. The rest of the rule — including other branches created by Fork blocks — continues to execute independently. This allows for precise control over the automation flow, ensuring that actions only occur when the appropriate conditions are met, without affecting parallel paths that may have different criteria.
16. Can a Fork block split a flow into more than two branches?
Yes. A Fork block can split the flow into up to five independent branches, each executing simultaneously. Each branch can contain its own combination of If conditions, Action blocks, and Delay blocks. For example, a single rule triggered by ticket creation could fork into three paths: one checking if the product is zPad and assigning to the zPad team, another checking if the product is zPhone and assigning to the zPhone team, and a third handling all other products with a default assignment.
17. Who can create rules in Automation Studio, and where do I access it?
Rules in Automation Studio can be created by users with Administrator privileges in Zoho Desk.
18. How to decide which block types to add to the rule?
The choice of blocks depends on the complexity of the process you are automating:
  1. Use an Action block when you need to perform a specific task, such as sending an alert, updating a field, or calling a custom function.
  2. Use an If block when the flow should continue only if a certain condition is met — for example, only proceed if the ticket priority is High.
  3. Use a Fork block when multiple independent paths need to run simultaneously — for example, routing to different teams based on product type.
  4. Use a Delay block when the flow should pause before executing the next action — for example, waiting three days before sending a reminder email.
Blocks can be combined freely, and multiple blocks can be added to a single rule up to a maximum of 50.
How to create an automation studio rule?
  1. Navigate to Setup > Automation > Automation Studio.
  2. Select the module and department if required, then click Create Rule.
  3. On the Rule information page, do the following:
    1. Enter the rule name and description.
    2. Select a module from the Module drop-down.
  4. On the Rule configuration page, choose an event to trigger/execute the rule. The events will differ based on the module selected.
  5. If required, specify a criteria for the event.
  6. Click + and select any of the following the block types based on your requirement:
    1. Action - Executes a specific task such as sending alerts, updating fields, or calling a custom function.
        
    2. If - Adds conditional logic to decide whether the flow should continue.
    3. Fork - Splits the flow into parallel branches, each running independently.
    4. Delay - Pauses the flow for a specific duration before executing the next action.
  7. Once you are done with all the required criteria, click Save Rule.