Salesforce WordPress Integration: Forms, Sync and SSO Options

Connecting a WordPress site to Salesforce means one of four things, and the right approach depends on which one you mean: sending form submissions into Salesforce as leads or cases, keeping data in sync both ways, letting customers log in to WordPress with their Salesforce identity, or replacing parts of the WordPress site with a Salesforce Experience Cloud portal. This guide covers each option, what it costs to maintain, and where the usual mistakes are. It is written for the person who owns the website and has been asked to “connect it to Salesforce”.

Option 1: Web-to-Lead and Web-to-Case, the built-in route

Salesforce generates an HTML form (Web-to-Lead for Leads, Web-to-Case for Cases) that posts straight to Salesforce. Paste it into a WordPress page, or map your existing WordPress form to post to the same endpoint with the same field names. It is free, it needs no plugin, and it is fine for a contact page with a few fields. Its limits: no update of existing records (every submission is a new lead), a daily cap of 500 submissions per org, no attachments, and spam protection has to be done on the WordPress side (a Turnstile or reCAPTCHA check before the form posts). Set the lead source and a campaign on the hidden fields so marketing can tell which page produced the lead, and turn on assignment rules so the lead reaches a person.

Option 2: A WordPress forms plugin with a Salesforce add-on

Gravity Forms, WPForms and Formidable each offer a Salesforce integration that maps form fields to Salesforce objects and creates or updates records through the API. This is the most common setup on business sites: you keep the form builder your team already knows, you get conditional logic and file uploads, and the add-on can update an existing Contact rather than duplicating it. Connect it with a dedicated integration user and a connected app, never with an employee’s login, and store the credentials in the plugin, not in the theme. Watch the API call budget on smaller Salesforce editions and log failed submissions somewhere a human reads.

Option 3: Two-way sync and e-commerce

When WordPress holds data Salesforce needs continuously, WooCommerce orders and customers, membership status, event registrations, form submissions are not enough. The choices, in rising order of cost: an integration platform (Zapier or Make for low volume, MuleSoft Composer or a similar iPaaS for anything a business depends on), a purpose-built plugin for the specific pairing (several exist for WooCommerce to Salesforce), or a custom integration against the Salesforce REST API with a queue and retry logic. Decide the system of record for each object before you start: if Salesforce owns the Contact and WordPress owns the order, conflicts have an answer. If both can edit the same field, they do not.

Option 4: Single sign-on, Salesforce as the identity provider

If customers or partners already have Salesforce logins (Experience Cloud users, for example), WordPress can trust Salesforce as a SAML or OAuth identity provider so nobody manages a second password. A SAML plugin on the WordPress side and a connected app or SAML configuration on the Salesforce side handle it. The marketing variant, using Account Engagement (Pardot) with WordPress, is covered step by step in Integrate WordPress with Salesforce Pardot using single sign-on.

Option 5: Replace the page with an Experience Cloud portal

Sometimes the request is really “customers should see their cases, invoices or documents”. That is not a WordPress integration; it is a Salesforce Experience Cloud site, linked from WordPress and styled to match. It saves building and syncing a customer area in WordPress that Salesforce already provides. Micronetbd builds these as customer and partner portals on Experience Cloud.

Which one should you pick?

• A contact or demo request form: Web-to-Lead, or your forms plugin with the Salesforce add-on if you need updates rather than duplicates.
• Marketing forms, email and lead scoring: Account Engagement, with its own plugin or form handlers.
• Orders, memberships or registrations that Salesforce must see: an integration platform or a purpose-built connector, with a clear system of record.
• A customer login: SSO with Salesforce as the identity provider, or an Experience Cloud portal.

Mistakes that generate support tickets

• Integration credentials tied to a person who leaves.
• Duplicates, because the form creates a new lead instead of matching on email.
• Spam leads, because the WordPress form has no bot check and Web-to-Lead accepts anything.
• Silent failures: the API rejected a record (a required field, a validation rule) and nobody was notified.
• Consent and privacy: marketing fields captured on the site without the consent text Salesforce and your privacy policy require.

Micronetbd has run Salesforce implementations since 2012 and keeps integrations like these healthy through Salesforce admin as a service. If you would rather have someone build and monitor the connection, book a working session and bring the site and the org.