Funding Onboarding Without Data Leakage
A business funding consultant was running client onboarding through Zapier, but concurrent automations could leak one client's financial data into another's document. We rebuilt the workflow with atomic isolation so every run is completely independent.
Business Impact
Clients go live in days instead of weeks, accelerating time to first revenue
Business Impact
Executive Outcomes
Clients go live in days instead of weeks with fully automated intake
Automated pipeline handles triple the volume without adding headcount
Clone-per-run architecture makes cross-client leakage structurally impossible
Team processes triple the grant applications per funding cycle
The Challenge
“The client's onboarding pipeline for business funding clients relied on Zapier. The critical flaw: concurrent runs could mix data between clients. Sensitive financial information was at risk of appearing in the wrong client's documents.”
Zapier automations could mix one client's financial data into another client's documents during concurrent runs
GoHighLevel form field mappings broke every time the intake form was updated, requiring manual remapping
Sensitive financial information appeared in wrong documents with no automated detection or prevention
PDF assembly was manual and inconsistent across different client funding packages
No input validation or security verification on incoming webhook data from GoHighLevel
The Transformation
What changed after we built the system
Zapier automations could mix one client's financial data into another client's documents during concurrent runs
Every run clones a fresh Google Sheet, making cross-client data contamination structurally impossible
GoHighLevel form field mappings broke every time the intake form was updated, requiring manual remapping
Dynamic field resolver fetches GHL metadata at runtime, surviving form revisions automatically
Sensitive financial information appeared in wrong documents with no automated detection or prevention
227 passing unit tests with 97.5% statement coverage verify data isolation across every code path
PDF assembly was manual and inconsistent across different client funding packages
Automated PDF assembly with width-aware text wrapping and masked sensitive fields
No input validation or security verification on incoming webhook data from GoHighLevel
HMAC signature verification and Zod schema validation enforced at every integration boundary
Why clone-per-run was the only safe architecture
The original Zapier setup shared a single Google Sheet across all concurrent runs. When two clients triggered onboarding at the same time, the faster run could overwrite cells that the slower run was still reading.
The fix was not adding row-level locking or timestamps. The fix was removing shared state entirely. Every run creates its own Google Sheet clone, writes only to that clone, and never reads from any other run's sheet.
This is more expensive in API calls, but it makes cross-client data leakage structurally impossible. You cannot mix data between sheets that do not reference each other. The 227 tests verify this isolation holds across every code path.
How We Built It
Technical architecture for the curious
Orchestration
Single durable task with per-step metadata tracking. Final-attempt notifications alert operators before giving up.
Intake
Runtime field resolution fetches GHL custom field metadata and normalizes names. A hardcoded fallback provides safe degradation.
Storage
Every run creates its own Sheet clone. All downstream operations pin to that new ID only, eliminating shared state.
AI
AI generates business profiles and industry codes. Failures flag for manual review instead of blocking the pipeline.
Security
Timing-safe HMAC checks, schema validation at every boundary, and URL checking before any document fetch.
Engineering Decisions
Tradeoffs we made and why
Clone-per-run Google Sheets instead of a shared database table
Benefit
Complete state isolation per client with zero risk of cross-contamination
Cost
Higher Google API usage and slower initial setup per run
Dynamic field resolution with a hardcoded fallback map
Benefit
Survives GHL form changes without manual remapping, degrades safely when the API is unavailable
Cost
Two code paths to maintain, and the fallback map can drift from actual field definitions
Trigger.dev v3 over Zapier for orchestration
Benefit
Code-first control over concurrency, state isolation, and failure handling
Cost
Requires engineering skill to maintain, unlike Zapier's visual interface
SSRF protections on all document fetching
Benefit
Prevents server-side request forgery when assembling PDFs from external URLs
Cost
Blocks legitimate internal URLs that require special allowlisting
Certain client names, proprietary workflows, screenshots, and internal assets referenced in this case study are protected under a non-disclosure agreement and have been anonymized or omitted to comply with our confidentiality obligations.
Running automations with client data at risk?
Book a free 30-minute call. We will audit your current workflow, identify data isolation gaps, and design a system that makes contamination structurally impossible.
30 minutes with Apurva. Not a sales call.
Book Your Free Audit