Once a trigger starts a flow, actions and logic elements define everything that happens next. Zoho Flow goes well beyond simple app-to-app data transfer, offering outgoing webhooks for pushing data to external services, custom functions for executing Deluge code within a flow, and logic elements for controlling the path and timing of execution. Together, these capabilities allow you to build sophisticated automations that handle complex, real-world business scenarios.
An app action is the most fundamental building block of a flow after the trigger. Each action step connects to a specific application and performs a defined task within it, such as creating a record, updating a field, sending an email, adding a row to a spreadsheet, or creating a task. You can chain multiple action steps together in sequence, with each step able to use data from the trigger and all preceding steps via data mapping.
The available actions for each app are listed in the app's documentation within Zoho Flow. Not all applications support the same set of actions, so it is worth reviewing the available options before designing a flow that depends on a specific capability.
An outgoing webhook action sends an HTTP request from Zoho Flow to an external application or service. Unlike a webhook trigger (which receives incoming data), an outgoing webhook pushes data outward, enabling your flows to communicate with any system that accepts HTTP requests, including services without a native Zoho Flow connector.
When configuring an outgoing webhook, you specify the target URL, the HTTP method (such as POST, PUT, or GET), the headers required by the receiving system (for example, an authorisation token), and the body of the request, which can include mapped variables from earlier steps in the flow. The response from the external service is captured and made available for use in subsequent flow steps.
Custom functions allow you to write Deluge (Data Enriched Language for the Universal Grid Environment) code directly within a flow. Deluge is Zoho's own scripting language, used across the Zoho platform, and it gives you the ability to implement logic that goes beyond what standard action and logic steps can achieve.
Within a custom function, you can manipulate strings, perform calculations, call external APIs, construct complex data structures, and return output values that become available as variables in subsequent flow steps. This makes custom functions ideal for data transformation tasks, complex conditional processing, or interactions with services that require bespoke request formatting.
Logic elements work alongside app actions to give your flows conditional intelligence. Rather than every execution following the same linear path, logic elements let you filter data, branch the flow based on conditions, add delays, and handle repeated data in lists. The available logic elements in Zoho Flow include:
A filter checks whether specified conditions are met before allowing the flow to continue. If the conditions are not satisfied, the flow stops at that point for that particular execution, preventing subsequent actions from running. Filters are useful for ensuring that actions only take place when the data meets your criteria, for example, only creating a follow-up task when a deal stage is set to a specific value.
A delay pauses the flow's execution for a defined period before the next step runs. This is useful when an action needs time to take effect before a follow-up step is performed, or when you want to schedule a notification to be sent a set number of hours or days after a trigger event.
A decision element creates a branching path within the flow. Based on one or more conditions, the flow follows different branches, each of which can contain its own sequence of actions. This allows a single flow to handle multiple outcomes from the same trigger event, much like an if/else structure in programming.
An iterator (also known as a loop) processes a list of items returned by a previous step one at a time, executing the subsequent actions for each item in the list. For example, if a trigger returns multiple new records, an iterator can ensure that a follow-up action is performed for each individual record rather than just the first one.