When the form configuration lies, the Flow inventory tells the truth.
A client reported that submissions from a WordPress Gravity Forms form weren't creating Lead records in Zoho CRM. The natural first move was to open the form itself and trace how it was delivering data to Zoho.
Inside the Gravity Forms settings, the form had a webhook configured — a POST to a https://flow.zoho.com/<org id>/flow/webhook/process/… URL, which is the standard pattern for a Zoho Flow webhook trigger. The form was marked active. The webhook was marked active. On the surface, everything looked correct.
Zoho provides no API or GUI to look up a Flow by its webhook URL. The only practical way to match a URL to an actual flow is to search the extracted flow JSON files directly. A quick rg (ripgrep) search of the local flow export folder for the exact URL from the form returned nothing. No file contained that endpoint.
That result pointed to Flow itself. Opening the Flow GUI confirmed it: no flow existed with that webhook endpoint. The URL in the form was a dead reference — pointing at a trigger that had been deleted or replaced at some point, with no corresponding update to the form.
The actual mechanism in use was different: newer flows in the account were pulling Gravity Forms data using the native Gravity Forms connector in Zoho Flow — not a webhook. The form had simply been left behind, still configured for an integration approach that no longer existed.
Because all flows — active and inactive — had been extracted to local JSON files, the search was a single rg call against the full corpus — not a manual page-by-page review in the Zoho Flow GUI. When the URL returned no match, the absence was immediately trustworthy: the extraction was confirmed complete by comparing the extracted file list against the Flow GUI inventory before concluding.
Starting the investigation inside the Gravity Form was the intuitive move, and it led to a dead end that still required Flow investigation to resolve. The more direct path would have been to start with the Flow inventory: a search for any flow receiving data from that form would have shown immediately that the webhook-based approach had been retired and replaced with a native connector. The form's webhook configuration would then be readable for what it was — an outdated artifact — rather than a live suspect.
The form told a misleading story. The extracted Flow metadata told the true one.
When a form says it's sending data and no records are arriving, don't start with the form. Start with the destination. A complete, searchable inventory of your flows turns a multi-step investigation into a single lookup — and tells you immediately whether the endpoint the form is targeting actually exists.
This matters beyond form webhooks. Deluge scripts are full of hardcoded webhook URLs — called from functions, workflows, and scheduled jobs. Zoho provides no API and no GUI to look up a flow by its endpoint URL. Without extraction, the only alternative is to open every webhook-triggered flow one by one, click into its trigger configuration, and compare the URL manually. In a large org with dozens of flows, that's not a realistic diagnostic step. With a fully extracted corpus — active and inactive — it's a single search.
Most of them are invisible until you extract the metadata and look.