Skip to content

2026-05-05 Zoho automation audit

Snapshot date: 2026-05-05.

Data files

  • zoho_flow/snapshots/2026-05-05/live_flows.json
  • zoho_flow/snapshots/2026-05-05/sample_flows.json
  • zoho_desk/snapshots/2026-05-05/webhooks.json

Findings

  • Zoho Flow has 25 visible live flows. Disabled flows are out of scope.
  • The client onboarding form flows look cloned. The general model and Archos sample use the same visible CRM upsert pattern; the main variation is the source/client value.
  • The current client form pattern is not a good long-term system for tracking active seats. It spreads source-specific behavior across Flow clones and connections.
  • The Desk Onboarding to Business Recurring flow is source-driven by Zoho Desk ticket updates. It updates CRM after an onboarding ticket reaches closed.
  • Desk already has webhooks pointing to Zoho Flow. Those are the source-side cutover points for Desk-origin automation, but the replacement must call middleware directly, not Flow.

Assessment

  1. Disconnect onboarding forms from Zoho Flow. Handle the integration through CRM, using update_source and a new onboarding_plan field in CRM so the active-seat flow is driven by CRM data instead of Flow clones.
  2. Rewrite the Desk automation that moves contacts to onboarding/business recurring so Zoho Desk webhooks call the middleware directly.

End goal: keep active seat counts reliable through onboarding form submissions and ticket actions. The current Flow-based system is too hard to audit, duplicates logic, and hides key behavior behind Flow connections and webhook callbacks.

Replacement rules

  • Middleware must be triggered by the source system, not by Zoho Flow.
  • Client onboarding form variants should differ only by source/client configuration.
  • Desk ticket automations should validate ticket type/status before writing to CRM.
  • Callback URLs remain redacted because webhook URLs are bearer-like secrets.