Configuring the Eloqua integration

In the admin: Eloqua — the screen this page documents (opens in the running app).

What/why: The lead lifecycle — what this screen manages and why it exists.

Purpose: manage the admin-editable half of the Eloqua integration — field mappings, the target form binding, tracking and hot-lead settings — and verify connectivity. Credentials are not managed here.

When to use

• Pointing lead capture at a different Eloqua form, or changing which session fields flow to which Eloqua contact fields.
• Turning tracking or hot-lead scoring on/off, or tuning the hot-lead threshold.
• Verifying the integration is correctly configured after a credentials rotation.
• Flushing queued lead submissions after an Eloqua outage.

Prerequisites

• Admin access with the edit_data capability (any data_editor or admin role).
• Eloqua credentials set as Worker secrets by ops (wrangler secret put …) — see the Eloqua integration reference. The screen only ever shows whether they resolve, never their values.

Steps

1. Open Admin → Eloqua (/admin/eloqua).
2. Settings — set the target form binding and (optionally) a contact list, then save.
3. Field mappings — add or remove rows mapping a session field to an Eloqua contact field id. Only mapped fields are sent.
4. Tracking / hot lead — toggle visitor tracking and hot-lead scoring, and save each card.
5. Click Test connection to run the connectivity/config validation: it confirms the credentials resolve and the configured form/fields exist.
6. If submissions queued during an outage, click Process retry queue to flush them.

Behavior guarantees

• Credentials never pass through this screen or D1 — they live in Worker secrets only.
• Guards are enforced server-side regardless of client state; only successful mutations are audited.

For the client architecture, credential resolution, and the downstream consumers (contact association, form sync, cookie recognition), see the Eloqua integration reference.