Product build / Security / Eloqua / Cloudflare
Building a secured review layer for Eloqua form protection
From form spam problem to accepted and deployed Cloudflare-protected review workflow, now in use for enterprise Eloqua marketing forms.
Enterprise marketing forms need more than a basic block or allow decision. Teams need visibility into suspicious submissions, reviewers need to understand why a record was held, and approved records need a controlled path back into Eloqua.
The opening problem
Eloqua forms are business-critical. They sit at the edge of campaign response, sales follow-up, and marketing attribution. Spam handling creates an awkward trade-off: let too much through and CRM or marketing data gets polluted, block too aggressively and valid leads can be lost.
The goal of this enterprise Eloqua POC was to build a review layer between the public form and Eloqua. The POC was accepted, deployed, and is now in use by a large enterprise. The layer validates the interaction, holds exceptions, shows review reasons, and forwards approved records without changing the shape of the original form submission.
The secured architecture
The workflow starts with a website form and a Cloudflare Turnstile widget. A Cloudflare Worker performs server-side Turnstile verification, applies review routing, and stores failed or suspicious records in a Cloudflare KV-backed review queue.
A Cloudflare Access secured dashboard gives reviewers a protected place to see captured submissions, review reasons, and available actions. Reviewers can accept, reject, or forward approved records into Eloqua.
Forwarding preserves the exact captured HTML field names from the original form submission.
Architecture flow
Website form
Cloudflare Turnstile
Worker verification
KV review queue
Access secured dashboard
Approved Eloqua forwarding
What made the build hard
- The Turnstile widget alone is not the full protection layer.
- The Worker must validate Turnstile server-side before trusting the submission.
- The dashboard needed Cloudflare Access protection.
- The API also needed to be protected, not just the page.
- Same-domain Worker routing had to serve the protected API cleanly.
- CORS and OPTIONS preflight handling had to be correct.
- Eloqua forwarding needed exact submitted HTML field names, not generic replacement names.
- The review layer had to stay honest about what Turnstile caught versus what review rules caught.
The secured dashboard
The dashboard sits behind Cloudflare Access. The reviewer does not enter a dashboard secret into the page. Instead, the protected API route accepts Access-authenticated users and keeps operational details out of static HTML.
The dashboard shows captured submissions, review reasons, and actions. Reviewers can accept, reject, or forward approved records. The public article does not expose live dashboard URLs, Worker URLs, API paths, or policy details.
The spam simulation lab
A controlled defensive testing tab was added so the workflow could be tested without pretending test data was real traffic. The lab can simulate missing Turnstile token, invalid token, unknown form ID, malformed email, URL-heavy message, honeypot-style fields, and repeated submissions.
The simulation lab is not an offensive testing tool. Some scenarios are Cloudflare Turnstile verification failures. Some are intended review-layer scenarios. The dashboard shows both the scenario intent and the actual Worker reason so the evidence stays honest.
Database and evidence
Cloudflare KV gives the deployed workflow an operational evidence layer. It can store pending review records, preserve simulation metadata, support review status, support forwarding status, and provide a history layer for later reporting.
That does not mean the database is a finished compliance system. It means the build has a practical path toward summary reporting, CSV export, review evidence, and cleaner operational handoff.
The AI-assisted build process
Greg acted as product owner and tester. Tanya helped structure architecture, prompts, QA, scope control, and debugging logic. Codex helped implement controlled changes. Cloudflare and Eloqua provided the technical platform.
The useful part was not generic prompting. The useful part was the controlled workflow: keep secrets out of public files, reason about routing carefully, test the review path, avoid overbuilding too early, and keep product claims grounded.
Lessons learned
- Protect the page and the API.
- Do not put Worker secrets in static HTML.
- Do not change Eloqua field names when forwarding to Eloqua.
- Keep simulation data clearly labelled.
- Show actual reasons honestly.
- Keep accepted, deployed, and in-use status honest without exposing private client implementation details.
- Make the database useful as evidence, not just storage.
What comes next
- Continue operating production routing where clean passed submissions can forward directly.
- Richer KV history and review evidence.
- CSV or evidence export.
- Client-specific access policies.
- Stronger Access JWT validation if needed.
- Multi-form configuration.
- Document the Forward Deployed Engineer journey with anonymised enterprise adoption evidence.
Related pages
For the product positioning, see the form protection solution page. For the portfolio milestone, read the latest Tanya Self-Assessment milestone.
FAQ
Does Cloudflare Turnstile replace Eloqua form processing?
No. Turnstile verifies the interaction. Eloqua remains the destination for approved marketing records.
Why use a review dashboard?
The review layer gives teams visibility into suspicious submissions, review reasons, and accept or reject decisions.
Are all suspicious submissions caught by Turnstile?
No. Some records fail Turnstile verification. Others are routed by review-layer rules.
Does the solution normalize Eloqua fields?
No. Forwarding preserves the exact captured HTML field names from the original form submission.
Is this production-ready?
Yes. The enterprise POC was accepted, deployed, and is now in use. Public pages describe the pattern without exposing private client routes, secrets, or configuration details.
Talk about a pilot
If your Eloqua forms need better spam review, data-quality controls, or a secured exception workflow, the next useful step is a scoped architecture conversation.