Product build / Security / Eloqua / Cloudflare
Building a secured review layer for Eloqua form protection
From form spam problem to Cloudflare-protected review workflow, with controlled routing into Eloqua.
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 proof of concept was to build a review layer between the public form and Eloqua. The layer had to validate the interaction, hold exceptions, show review reasons, and forward 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 proof of concept an operational evidence layer. It can store pending review records, preserve simulation metadata, support review status, support forwarding status, and become 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 POC visibility before switching to production exception-only routing.
- Make the database useful as evidence, not just storage.
What comes next
- 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.
- Product page positioning on pl8ypus and protected client-area direction later.
Related pages
For the product positioning, see the form protection solution page. For the portfolio milestone, read the latest Tanya Review 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?
It is a secured proof of concept moving toward pilot-ready product shape. Production rollout still needs client-specific routing, access, governance, and retention decisions.
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.