How to integrate Unify with Zoho Flow
To integrate Unify with Zoho Flow, create a Webhook trigger, choose JSON, and copy the generated URL into a Unify Play’s Webhook action. Send a sample to expose the incoming variables, then map them to the actions you need. Webhook acknowledgement and downstream completion are separate checks.[1][3]
- Connection
- Via webhook
- Automation
- Tool
- Zoho Flow
- Zoho Flow Webhook trigger
- Data flow
- Unify → Zoho Flow
- JSON payload
At a glance
- Choose the action and its required prospect fields
- Use representative JSON and keep the needed context available
- Decide whether one request should cause one run or multiple runs
When this workflow makes sense
Start with the decision your team needs to make, then choose the connection that supports it.
A useful cross-application handoff starts with the destination action, not with the webhook URL. Agree which fields the receiving application needs and what should happen to an incomplete record. Payload extraction can simplify later steps, but it can also hide the context a team needs to investigate an exception.
A good fit when
Teams already using Zoho Flow and its connected applications for operational tasks.
Reconsider the plan when
If the process needs custom authentication beyond the documented trigger setup, confirm the receiving design before relying on it. Avoid enabling per-entry processing without deciding how many actions one request should cause.
Design the handoff
Use this framework to agree on the input, the next action, and who owns the result.
Suggested workflow design, based on the documented capabilities below.
| Stage | Decision to make |
|---|---|
| Destination | Choose the action and its required prospect fields |
| Shape | Use representative JSON and keep the needed context available |
| Cardinality | Decide whether one request should cause one run or multiple runs |
| Outcome | Inspect the destination separately from webhook acknowledgement |
Explore the scenarios
Choose the situation that fits your team and work through the proposed plan.
Open a scenario to explore its plan. Checklists track your selections in this page only.
Route a prospect into an existing process
A connected application already holds the team’s operational queue.
Map to the destination’s required fields and preserve a review path for incomplete records.
- Capture the fictional payload
- Map its fields into the selected action
- Test both a complete and an incomplete record
Control the effect of payload extraction
The team plans to send nested or multi-entry data later.
Changing the payload shape can change both visible fields and the number of runs.
- Document the proposed shape
- Review extraction and per-entry settings
- Send a controlled sample and count the destination results
Illustrative workflow, not a preconfigured automation. Complete these checks in your own account.
Define success before launch
Inspect the data and the intended outcome separately. Connection status is only the first check.
Expected, not tested
The flow receives one fictional prospect and the selected action creates the intended destination result.
Inspect the flow history and destination. A configured webhook acknowledgement confirms receipt, not that every later action succeeded.
Documentation-based reference. This workflow has not been tested end to end. Use a record or event you control before enabling live activity.
Questions answered
Common decisions when connecting Unify and Zoho Flow.
How does Unify start a Zoho Flow?
Use POST with JSON to the generated Webhook trigger URL and map the captured variables into subsequent actions.[3]
Should I use a Zoho Flow outgoing webhook?
No. For this Unify-to-Zoho Flow direction, choose the incoming Webhook trigger. Outgoing webhooks send data from Zoho Flow to another service.[3]
Can I use only part of the JSON payload?
Yes. Advanced settings can extract a specified key. Check that the selected portion includes every field your later actions need.[3]
Does acknowledgement mean the flow finished?
The documented acknowledgement is a response after receipt. Inspect the actual run and destination result before treating the process as complete.[3]
Will the acknowledgement body return data to Unify?
No. The Unify Webhook action does not pass response bodies into downstream Play steps.[2]
Limits & decisions
Check these boundaries before designing a live workflow around the connection.
- Use the generated URL rather than constructing a regional endpoint by hand
- The cited trigger setup does not specify an additional header-based authentication scheme
- Destination application permissions and action requirements still apply
- No live flow or destination action has been executed
What the connection supports
Understand the connection, the data involved, and the behavior that matters for a Unify + Zoho Flow workflow.
POST / JSON
| Decision | What to know |
|---|---|
| Trigger | A generated webhook URL starts a flow when it receives data[3] |
| Formats | JSON, form data, and plain text are supported by the trigger[3] |
| Extraction | Advanced settings can select a nested key or expose request headers[3] |
| Multiple entries | An optional setting triggers a flow for each payload entry[3] |
| Acknowledgement | The trigger can send a configured receipt response[3] |
Technical setup reference
References and requirements for the Zoho Flow connection.
Connection requirements and setup checklist
Before connecting
- A Unify Play with a Webhook action
- A Zoho Flow account with permission to configure and enable a flow
- Connected destination applications and their required fields
- A fictional prospect for the trigger test
Create a JSON receiver
Create a flow, choose Webhook as the trigger, and select JSON. Copy the unique URL generated for that flow.[3]
Choose the extraction scope
Keep the full payload for this flat example. Advanced settings can extract a selected key or run once per entry in a multi-entry payload; enable those options only when that is the intended behavior.[3]
Request configuration
- Method
POST- URL pattern
Paste the generated Zoho Flow webhook URL- Headers
Content-Type: application/json- Authentication
- Use the complete URL copied from the trigger, including its generated parameters. The cited trigger setup does not prescribe an additional authentication header; this example adds none. Keep the URL private and confirm the actual receiver requirements with a sample request.
Choose JSON as the body format. Unify sets Content-Type automatically. The receiver must respond within Unify’s 8-second timeout; request responses are not passed to later Play steps.[2]
Replace URL placeholders with the actual receiver URL from your account or deployed application. These example URLs are not working endpoints.
Example handoff payload
Start with a fictional prospect. Validate the resolved values before using a real record.
Inspect the sample payload and field mapping
{
"event": "prospect_handoff",
"prospect_name": "Alex Morgan",
"prospect_email": "alex@example.com",
"company_name": "Example Company",
"company_domain": "example.com"
}Fictional data. Replace sample values before using a real Play.
The keys are an example handoff format, not required Unify field names. Use the field mapping to distinguish record data from fixed settings. Select available fields in your Play and inspect Expand preview; do not replace configuration values with prospect data.[2]
| Payload field | Value to send |
|---|---|
event | A fixed label you choose for this workflow |
prospect_name | Use {{ person.first_name }} and {{ person.last_name }} for the prospect name |
prospect_email | Use {{ person.email }}; decide how to handle missing values |
company_name | Use {{ company.name }} |
company_domain | Use {{ company.domain }} |
Map the trigger variables from the flat sample into the destination’s actual fields. Extracting only a nested key changes which fields later actions can see; this sample does not require a nested-key extraction.
Troubleshooting
Start with the stage where the expected data or action stops appearing.
Expected fields are missing
Retest with representative JSON and check whether Advanced settings extracts only one portion of the payload.[3]
One request starts several runs
Check Trigger flow for each entry. It is intended for multi-entry payloads and can start separate runs for their entries.[3]
Receipt succeeds but the destination is unchanged
Review the flow’s enabled state, run history, action mapping, and destination connection. Check the failed action before replaying the whole handoff.[4]
Sources & review
Official documentation reviewed on September 15, 2026.
Technical claims link to primary documentation from Unify and the destination tool. Scenarios, field choices, and recovery plans are editorial implementation examples. Documentation review is separate from execution testing.
Documentation reviewed; end-to-end execution not tested. No named technical reviewer has signed off on these articles yet.
Content updated: . Report a correction to Unify with the tool name, source URL, and behavior you observed.
Keep exploring
