Behind the Workbench

How I Use AI Inside a Diagnostic Workbench

A behind-the-scenes walkthrough — from raw extraction to a cross-referenced findings document — using the same process every Workbench runs on.

Works with any capable AI: Claude, ChatGPT, Gemini
Runs through desktop AI tools (Cowork, Claude Desktop, or similar)
1

Starting With a Full Extraction

Every Workbench starts with a full extraction from the client's live Zoho environment, organized into a structured folder before any AI touches it. I point a desktop AI tool that can read local files directly — Cowork, Claude Desktop, or similar — at that folder, so nothing has to be copied or pasted in.

data/{your-org}/raw/ ├── workflows/ ← trigger conditions, criteria, action bindings ├── functions/ ← Deluge source code, API calls, logic ├── modules/ ← field definitions, relationships └── blueprints/ ← stage definitions, transitions

Each workflow JSON tells the AI when and why something fires — trigger type, module, field criteria. Each function file tells it what actually happens — API calls, data transformations, external HTTP requests. The analysis lives in the gap between the two.

Note: The Workbench also includes index files like all_workflows.json and functions_index.json. Those load first — they give the AI a fast lookup table so it isn't scanning every file to find what it needs.

2

Writing an Analysis Seed File

Before I prompt the AI at all, I put together a plain-text seed file — something like tempanalysis.txt — that captures what I already suspect. Related workflows and functions get grouped together. I note what I already know about how a process is supposed to work, and flag anything that already looks off.

That file does two things: it gives the AI a starting point to verify and expand rather than a blank page, and it keeps my own thinking organized as the investigation develops.

Example Seed File — tempanalysis.txt

Here's what a seed file looked like on a real engagement. I grouped functions by the external endpoint they call, then documented the invoking workflows and their trigger conditions — before opening a single file in AI.

# Functions calling the eCommerce order endpoint functions/Send Customer Order to eCommerce_[id].txt Invoked by workflows/Send Order to eCommerce_[id].json [when Deal is created and Stage = Closed Won] workflows/Send Order to eCommerce_[id2].json [when Stage is modified to Closed Won, any time] functions/Update eCommerce Customer Information_[id].txt Invoked by workflows/Update eCommerce Customer_[id].json [when Account Level, Status, or Discount is modified] # Functions calling the Flow webhook functions/Send eCommerce Customer Hook_[id].txt Invoked by workflows/Create eCommerce Customer_[id].json [any time Status → Active AND Type → Customer] workflows/Create eCommerce Customer_[id2].json [on Account create, Type IS Customer, Status IS Active]

What makes this effective: Before the AI reads a single file, I've already mapped the invocation chains by hand. Its job is to verify those groupings, fill in what I missed, and reason about whether the trigger variations are intentional — not to figure out the structure from scratch.

3

Working Directly Inside the Folder

I open a desktop AI tool and point it at the folder holding the extracted data. With direct folder access, the AI reads every JSON and text file itself — no copying, no pasting, no character limits to work around.

This is why a desktop AI tool matters for this kind of work. A web chat interface would mean pasting content by hand, which is slow and strips out the file relationships that make cross-referencing possible in the first place. Tools like Cowork and Claude Desktop can browse a folder the way I would.

Why this changes what's possible

A typical Zoho implementation has 30–80 workflows and 20–50 custom functions. Cross-referencing those by hand is a full day's work. AI with folder access maps the entire relationship graph in minutes — and surfaces connections I might not have thought to check.

4

Cross-Referencing Workflows Against Functions

This is the core analytical move. I have the AI read both sides of every workflow-to-function relationship and map them together. The workflow JSON says what should trigger; the function code says what actually runs when it does.

In that gap, I typically find:

  • Orphaned functions — code that exists but no workflow ever calls
  • Broken references — workflows pointing to renamed or deleted functions
  • Trigger inconsistencies — companion workflows with mismatched criteria (one checks a field the other ignores)
  • Hardcoded credentials — API keys or URLs buried in function code
  • Logic duplication — two functions doing the same work independently
  • Superseded integrations — external webhooks still firing to retired endpoints
What the Cross-Reference Revealed — Real Example

Analysis of one client's CRM found two separate "Send Dealer Information to WooCommerce" workflows calling the same function: one fires on Deal creation when Stage = Closed Won, the other fires any time Stage is modified to Closed Won. The function is identical — but the trigger difference creates a potential duplicate-fire condition that had never been documented.

A third workflow — "Create WooCommerce Customer" — had two trigger variants: one fires on Account creation when Type=Dealer and Status=Active; the other fires when either field is modified to those values. Both invoke the same Flow webhook. Whether this is intentional redundancy or a logic gap requires a business intent conversation — but it's now visible.

5

Trace End-to-End Business Scenarios

Once the cross-reference map exists, I pick a key business process and have the AI walk every workflow and function that participates, in sequence. This reveals what a single-file read never shows: the full chain of events, and where it breaks down.

Good scenarios to trace: Deal closed-won, new dealer onboarding, contact status change. I'll ask something like: "Walk me through every automation that fires from the moment a Deal reaches Closed Won, in order. What happens, and what could go wrong?"

What end-to-end tracing surfaces

Race conditions between competing workflows. Gaps in the chain where a record is expected to update but nothing triggers. Overlapping logic from old and new approaches that were never reconciled. These are the issues that don't appear in any dashboard — because they're about sequence, not outcome.

6

Producing a Findings Document

Once the analysis is complete, I have the AI generate a structured findings document — a Word doc, spreadsheet, or formatted markdown — that captures the workflow-to-function mapping, every issue found, and recommendations. That becomes the reference artifact for cleanup, maintenance, and onboarding.

The document is the deliverable. AI produces the first draft; I review and annotate it before it goes to a client. What would take days of manual documentation emerges in minutes — grounded in the actual configuration of the system, not memory or assumption.

What the document includes: A workflow-to-function mapping table. An issues list with severity ratings. Business questions that need stakeholder input (intent gaps). Recommendations ranked by risk.

What This Approach Produces

In a single AI-assisted session I ran against a real client's metadata — using only the structural configuration, no event logs — the following types of findings surfaced in under two hours:

Trigger Coverage Gaps

Duplicate-fire conditions Two workflows calling identical logic under overlapping conditions — one on creation, one on modification. Never documented. Never intentional.

Undocumented Intent

Ambiguous redundancy Parallel webhook trigger variants — both valid, but nobody could say whether the duplication was deliberate or an artifact of past changes.

Maintenance Risk

External endpoint exposure Functions with hardcoded external API paths — visible in code, invisible in Zoho's UI, unknown to anyone who hadn't read the source.