FAIR

Federated and Independent Repositories

Oddeven Lead Routing for Salesforce

Plugin Banner

Oddeven Lead Routing for Salesforce

by oddeveninfotech

Download
Description

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

Supported forms

  • Contact Form 7

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/ .

  1. Upload the plugin to /wp-content/plugins/oddeven-lead-routing-for-salesforce and activate
    it.
  2. Add an encryption key to wp-config.php. This step is required: until it is done
    the plugin stores no Salesforce credential at all, and says so on screen. Generate
    one with wp oddeven-lead-routing key:generate, which prints a line to paste:
    define( ‘LBSF_ENCRYPTION_KEY’, ‘base64 of exactly 32 bytes’ );
  3. In Salesforce, create an External Client App and enable the client credentials
    flow for it.
  4. In WordPress, go to Oddeven Lead Routing, add a connection with your consumer key and
    secret, and test it.
  5. Create a feed that binds one of your forms to a Salesforce object.
  1. 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.

    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.

  2. 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.

    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.

  3. 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.

    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.

  4. 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.

    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.

  5. 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.

    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.

  6. 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.

    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.

Why do I need to define LBSF_ENCRYPTION_KEY?

It is the key your Salesforce credentials are encrypted with, and it is required.
Until it is defined the plugin stores no credential at all and tells you so.

It does not invent a key of its own, and it never borrows one from WordPress. A key
taken from your site’s authentication salts would look convenient right up to the day
something rotated that salt — several security plugins do, on a schedule — at which
point every stored Salesforce credential would become permanently unreadable, with no
way to recover it. Being asked for one line in wp-config.php is the cheaper end of
that trade.

Generate one with wp oddeven-lead-routing key:generate.

Does this support the username-password OAuth flow?

No, deliberately. Salesforce retires it in Winter ’27 and it requires storing a
user’s password. Use the client credentials flow with an External Client App.

What happens if Salesforce is down when someone submits a form?

Nothing visible to the visitor. The submission is already saved, and the delivery is
retried in the background.

Does the plugin send any data anywhere else?

No. There is no telemetry and no phone-home of any kind.

1.0.0

First stable release.

  • Salesforce connections through External Client Apps, using the OAuth client credentials flow or a browser sign-in. The username-password flow is not implemented and never will be.
  • Contact Form 7 submissions delivered to any Salesforce object through the REST API, or to Web-to-Lead where no Salesforce administrator is available.
  • Every submission is saved before it is sent, then delivered in the background by Action Scheduler, so a slow or failing Salesforce cannot break a form or lose a lead. Failed deliveries retry with backoff and end in a dead letter list you can inspect and requeue.
  • Field mapping built from the object’s own describe, with validation that refuses a mapping Salesforce would reject on every submission.
  • Test Mode records the exact payload that would have been sent without sending it.
  • Credentials encrypted at rest with sodium, under a key you supply in wp-config.php.
  • Ten capabilities, so the person who watches the queue need not be the person trusted with the client secret.
  • Configuration export and import for moving a setup between sites, and WP-CLI commands for everything that does not need a browser.
  • Registered with WordPress’s own privacy exporter and eraser, plus a configurable retention sweep.
  • No telemetry, no upsells, and no admin notices except for something that is actually wrong.
Back to top