Oddeven Lead Routing connects your WordPress forms to Salesforce and keeps the connection
working through the 2026 and 2027 authentication changes.
Built for the auth Salesforce actually supports. Salesforce restricted new
Connected App creation in Spring ’26 and retires the OAuth username-password flow in
Winter ’27. Oddeven Lead Routing is built on External Client Apps with the client credentials
flow, so a connection you set up today is still a supported configuration afterwards.
The username-password flow is not implemented, and never will be.
A submission is saved before it is sent. Every submission is written to the
database with a pending status before any outbound call, then delivered by a
background worker through Action Scheduler. A Salesforce outage, a slow API or a
validation error cannot break your form or lose the lead. Failed deliveries are
retried with backoff and, if they keep failing, land in a dead letter list you can
inspect and requeue.
Credentials are encrypted at rest. Client secrets and tokens are protected with
libsodium authenticated encryption, keyed from a constant you define in
wp-config.php.
No phoning home. The plugin talks to your Salesforce org and nothing else. No
telemetry, no analytics, no licensing service.
Features
- Map form fields to any Salesforce object over the REST API
- Web-to-Lead and Web-to-Case as alternatives when you cannot use the API
- Per feed conditional logic
- Delivery log with retry, dead letter handling and manual requeue
- Ten granular capabilities, so watching the submission queue does not require the
right to edit Salesforce credentials
Combining fields
A mapping row can send several fields as one value, with fallbacks: {first} {last}
sends the name; {company}||{first} {last}||Individual sends the company when the
form has one, the person’s name when it does not, and a fixed word when it has
neither. That is what Salesforce’s mandatory Company field needs from a form most
people fill in as individuals.
Supported forms
- Contact Form 7
- Formidable Forms
- Custom forms — any form your theme or a developer built, connected with one line of code
Formidable Forms
A Formidable form connects the same way a Contact Form 7 one does: choose Formidable
Forms as the source, enter the form’s ID from its Forms list, and map its fields. Fields
are identified by Formidable’s field ID — the number the form itself posts — with the
field’s label shown beside it, so nobody has to remember that “Last name” is field 7.
A Name field is offered part by part — 82.first, 82.last — and so is an Address
field, because Salesforce wants FirstName and LastName apart; the field itself is
still available as one value. Entries are captured the moment Formidable saves them,
before its own actions run, so a
form whose email action is switched off still delivers. The free plugin is enough;
repeater sections from Formidable Pro are handled as one submission, not one per row.
Start from a live form
Paste the address of a page that shows a form and the plugin reads the form from it,
tells you whether it can deliver from that form plugin, and hands you a mapping CSV
with the form id and every field already filled in — the obvious Lead fields
suggested, the rest left for you. Complete the Salesforce column and import it. No
viewing page source, no typing field ids.
Using Web-to-Lead? Upload the form Salesforce generated under Setup Web-to-Lead as
well, and the CSV comes back with both sides filled in: each Salesforce field —
including custom fields by their 00N… id — paired with the matching form field by
label, the org id set, and hidden values such as the record type carried as fixed
values.
Custom forms
A form the plugin has never heard of can still reach Salesforce. From inside the code
that already handles the submission, after it has decided the submission is good:
do_action( 'lbsf_custom_form', 'quote-request', array( 'first_name' => $first_name, 'email' => $email ) );
Everything after that is identical to a Contact Form 7 lead: saved first, queued,
retried, and visible in Activity. Declare the form and its fields under Forms Custom
forms so the mapping can be built before the form has ever been submitted. Fields that
turn up in real submissions are recorded and offered there too, so a field added in code
and forgotten in configuration shows up as something to click rather than as silence.
It is a hook rather than an address the browser posts to, deliberately: your form keeps
its own nonce, spam handling and redirect, and this plugin adds nothing new that faces
the public internet.
Requirements
- WordPress 6.8 or newer
- PHP 8.0 or newer with the sodium extension
- The ability to add one line to
wp-config.php, which holds the encryption key - A Salesforce org where you can create an External Client App
External services
This plugin connects to Salesforce, and to nothing else. It contacts no service
operated by us, sends no telemetry, and transmits nothing at all until you have
configured a connection and connected a form to it. A visitor loading a page never
causes an outbound request.
Your Salesforce org
The Salesforce org you connect, at the My Domain address you supply, for example
https://yourcompany.my.salesforce.com. It is used to obtain an OAuth access token, to
read the object and field list so you can map fields to it, and to create records from
form submissions.
What is sent, and when:
- Your External Client App’s consumer key and secret, when an access token is requested
— when you connect, when you use “Test connection”, and when a token expires. - The name of the Salesforce object you chose and a field list request, when you open
the mapping editor. - The form field values you have mapped, when a queued submission is dispatched. Only
the fields named in your mapping are sent; nothing else from the submission is.
Salesforce Web-to-Lead and Web-to-Case
Used only if you choose that delivery method for a form, instead of the API.
- https://webto.salesforce.com/servlet/servlet.WebToLead for production orgs
- https://test.salesforce.com/servlet/servlet.WebToLead for sandboxes
Your Salesforce organisation id and the mapped form field values are sent when a
queued submission is dispatched.
Salesforce sign-in
Used only if you choose the browser sign-in method when creating a connection. Your
browser is sent to https://login.salesforce.com, https://test.salesforce.com or your
own My Domain address to authorise the plugin, and the resulting authorization code is
exchanged there for an access token.
All three are provided by Salesforce, Inc. Terms of service:
https://www.salesforce.com/company/legal/agreements/ . Privacy policy:
https://www.salesforce.com/company/legal/privacy/ .
Screenshots
The dashboard answers "is it working" before it offers anything to configure: one plain sentence about the last seven days, then any problem with the fix beside it, then the latest submissions and what became of each.
Activity, with a status in words for every submission. A delivered lead carries the Salesforce record id it created; anything else says plainly what it is, and nothing is coloured without also being labelled.
A failure explains itself in terms you can act on. Salesforce's own validation message is quoted, the cause is attributed to the org rather than to the plugin, and the record can be sent again once the cause is fixed.
Field mapping built on your org. The destination list comes from the object itself, required fields come first and are flagged, and fields Salesforce would never accept on create are not offered at all.
Connection health, one row per thing that can be wrong. An expired token reads OK because it renews itself; an unrecorded app type reads Unknown rather than being guessed. The retirement panel links to this org's own schedule instead of printing a date it cannot know.
Choosing how to connect, framed by outcome rather than by protocol. The basic method says before you pick it that Salesforce will not confirm delivery.