A WhatsApp Salesforce integration looks like a connector problem and turns out to be an ownership problem. The API call is trivial. What decides whether the project ships in a fortnight or stalls for a quarter is who holds the WhatsApp Business Account, which console your agents actually work in, and whether anyone modelled the three separate bills that arrive afterwards.
This guide covers the four ways to connect the two systems in 2026, the documented constraint that blocks the most popular route, the setup sequence in Service Cloud step by step, what the licences and messages really cost, and the decision rule for choosing between a native channel and a helpdesk-side sync. If you have not yet chosen an access method on the Meta side, start with the WhatsApp Business app versus the API — every route below assumes API access.
The Four Routes to a WhatsApp Salesforce Integration
There is no single connector. Every WhatsApp Salesforce integration follows one of four architectures, and they differ on who owns the WhatsApp Business Account, where the agent works, and what lands in Salesforce.
1. Native enhanced channel via Digital Engagement
Salesforce's own messaging stack. You enable Messaging in Setup, create an enhanced WhatsApp channel, and inbound threads become Messaging Sessions routed through Omni-Channel into the Service Console. Agents never leave Salesforce. Every conversation is a first-class record you can report on, automate with Flow, and tie to a Case.
2. AppExchange connector or BSP package
A managed package from a Business Solution Provider installs custom objects, a message composer and a webhook listener into your org. The BSP holds the WABA and relays messages. This route usually reaches features Salesforce has not shipped natively — broadcast campaigns, richer template builders, WhatsApp Pay — at the cost of a second vendor relationship and a data model you did not design.
3. Custom build on the Meta Cloud API
Named Credentials to graph.facebook.com, an Apex REST endpoint for the inbound webhook, Platform Events to fan messages out to the UI, and a custom object for the thread. Maximum control, maximum cost. You now own webhook retries, template sync, media storage, opt-out state and rate limiting. Only worth it when the conversation logic is genuinely proprietary.
4. Helpdesk-side ownership with CRM sync
A support platform owns the WhatsApp inbox and writes back to Salesforce: contact created or matched, case opened, outcome and transcript link stamped on the record. Agents work in a purpose-built messaging UI; Salesforce stays the system of record. This is the route that scales cheapest when WhatsApp volume is high and the people answering it are not full-time Salesforce users. It is also the pattern behind connecting WhatsApp to a shared team inbox.
| Route | Who owns the WABA | Agent works in | Typical time to launch | Best when |
|---|---|---|---|---|
| Native Digital Engagement | Created inside Salesforce setup flow | Service Console | 1–3 weeks | Agents are full-time Salesforce users and every thread must be a Messaging Session |
| AppExchange / BSP package | The BSP | Package UI inside Salesforce | 2–5 weeks | You need campaign, catalog or Pay features Salesforce has not shipped |
| Custom Cloud API build | You, in Meta Business Manager | Custom Lightning component | 6–12 weeks | Conversation logic is proprietary and no vendor model fits |
| Helpdesk-side sync | The support platform (or you) | Dedicated messaging inbox | Days | High WhatsApp volume, mixed support and sales pod, Salesforce as record system |
The WABA Rule That Blocks Most First Attempts
This is the part worth reading twice, because it is where a WhatsApp Salesforce integration most often dies in week one.
Salesforce documents that each enhanced WhatsApp channel is linked to a WhatsApp Business Account created during the Salesforce channel setup flow. A WABA you built earlier in Meta Business Manager, on your own or through another provider, cannot be attached to a Salesforce enhanced channel. The setup wizard walks you through creating the WABA it will then own.
The practical consequences are unforgiving:
- Your existing number is not plug-and-play. If the number your customers already message sits under a BSP's WABA, you are looking at a migration, not a connection.
- History does not travel. BSP migrations move the number and, in some cases, the templates — they do not move conversation history. Export anything you need for audit before you start.
- Templates get re-approved. Templates that moved with the WABA are frequently unusable in the destination platform and have to be resubmitted, so budget for Meta review time on every one.
- Test on a spare number. Never run a first attempt against your live support line. Verify the flow end to end on a number nobody is messaging.
Route 4 is the way around this constraint rather than through it: because the conversation is not a Salesforce Messaging Session, the WABA can stay exactly where it is and Salesforce receives structured data instead of owning the channel.
Setting Up the Native Channel, Step by Step
If the native route fits, here is the full WhatsApp Salesforce integration sequence. Do these in order — the routing steps fail silently if the queue does not exist first.
- Confirm licensing. Digital Engagement must be provisioned on your Service Cloud org. On the Agentforce Contact Center Digital add-on you must also purchase message credits before a WhatsApp channel can be created at all.
- Create the queue first. Add the Messaging Session object to a queue and assign the agents or public group who will handle inbound WhatsApp. Skipping this is why so many first setups deliver messages that route nowhere.
- Enable Messaging. Setup → Quick Find → Messaging Settings → toggle Messaging on.
- Create the channel. New Channel → Start → WhatsApp → Next. Sign in with the Facebook credentials that own the Business Manager, create the WABA in the flow, verify the phone number by SMS or voice call, and select it.
- Wire routing. Edit the channel and point it at the Omni-Channel queue you created, then set the routing configuration — capacity model, priority and, if you use them, skills.
- Configure consent. Set the intro message, opt-out keywords and opt-out confirmation. Get this right the first time: WhatsApp opt-in rules are enforced by Meta at the account level, and repeated blocks feed quality-rating downgrades.
- Set conversation messages. Auto-acknowledgement, start-of-conversation and end-of-conversation messages. Keep them short; every automated send counts against the same per-message billing as anything else.
- Add the console component. Drop the Enhanced Conversation component onto the Messaging Session Lightning record page so agents see the thread and the customer record side by side.
- Build and submit templates. Create your business-initiated templates and submit them to Meta. Enhanced channels support up to 250 templates per WABA, and you can request an increase through WhatsApp Direct Support if you manage your own WABA. Our guide to writing templates that get approved covers the category traps.
- Test the full loop. Inbound message → queue → agent accept → reply → end conversation → Messaging Session closed and linked to the Contact. Then test the same loop 25 hours after the last inbound message and confirm the template path fires.
What It Costs: Three Layers, Not One
Every quote-stage surprise in a WhatsApp Salesforce integration comes from modelling one layer and forgetting the other two.
Layer 1 — Salesforce licensing
Salesforce lists Digital Engagement at USD 75 per user per month on its public digital channels pricing page. Each licence bundles 25 SMS or WhatsApp conversations per user per month — the included allowance can now be applied to either channel — plus 25 Einstein Bot conversations per user per month. Beyond the bundle you buy add-on licences, or message credits if you are on the Agentforce Contact Center Digital add-on. Real quotes vary with edition, region, term and bot usage.
Layer 2 — Meta's per-message bill
Salesforce licensing does not include Meta's messaging charges. Since July 2025 Meta bills per delivered message at your customer's country rate, by template category. From 1 October 2026, free-form service replies inside the 24-hour window stop being free, which turns agent verbosity into a line item. The full breakdown is in our WhatsApp Business API pricing guide.
Layer 3 — build and admin time
Build time is the layer teams underestimate most. Native setup is measured in days for a simple channel and weeks once routing rules, templates and Flow automation are in scope. Custom builds are measured in months and carry permanent maintenance. Whatever the route, someone has to own template hygiene and opt-out state forever.
| Cost layer | Native Digital Engagement | Helpdesk-side sync |
|---|---|---|
| Per-seat platform fee | ~USD 75 / user / month on top of Service Cloud | Support-platform seat, typically a fraction of that |
| Included conversations | 25 SMS or WhatsApp + 25 bot conversations per user | Plan-dependent; usually not metered per conversation |
| Meta per-message charges | Billed separately, always | Billed separately, always |
| Ten-agent monthly seat cost | ~USD 750 before a single message | Materially lower; scales with agents, not CRM seats |
| Where the WABA lives | Must be created in the Salesforce flow | Stays where it is — no migration required |
Documented Limits You Should Know Before You Commit
Some constraints on a WhatsApp Salesforce integration are Salesforce's, some are Meta's, and neither vendor will surface them during a demo:
- No group chats. Group WhatsApp conversations are not supported in enhanced channels. If your field teams coordinate in groups today, that workflow does not move into the console.
- No business-to-business messaging. Meta does not support B2B messaging on the platform, regardless of which CRM sits behind it.
- 250 templates per WABA. Generous for most teams, tight for multi-brand or multi-market operations running localised variants. Increases go through WhatsApp Direct Support.
- The 24-hour window is Meta's, not Salesforce's. Free-form replies are allowed only within 24 hours of the customer's last inbound message. Outside it, template or nothing.
- Customisation ceiling. The out-of-the-box channel buys speed at the price of workflow and data-capture flexibility. Teams that need a bespoke conversation data model end up in Apex, and the time-to-value advantage disappears.
- Messaging limits still apply. Your WABA's tier caps how many unique customers you can start conversations with per day — see WhatsApp messaging limits.
Data Model: Decide This Before the First Message Lands
The most expensive failure in a WhatsApp Salesforce integration is not technical. It is dropping WhatsApp traffic into Salesforce without deciding where things live, then discovering six months later that reporting cannot be reconstructed.
Settle four questions in writing before go-live:
- Where does a conversation live? Messaging Session, a custom object, or a transcript link on the Case. Pick one and enforce it.
- What creates a Case? Every inbound thread, or only escalated ones? Auto-creating a Case per message is how a 400-message day becomes 400 open Cases.
- Where does opt-in state live? One field, one source of truth, updated by whichever system receives the opt-out keyword. Two ledgers means compliance risk.
- How is the contact matched? Phone-number normalisation rules, decided once. A UAE number stored four ways matches nothing.
Native or Helpdesk-Side? The Decision Rule
Strip away the vendor framing and every WhatsApp Salesforce integration comes down to one question: who owns the conversation?
Go native when your agents already live in the Service Console eight hours a day, when Omni-Channel routing and Salesforce reporting are non-negotiable, when WhatsApp volume is modest relative to your Salesforce seat count, and when you can create a fresh WABA without disrupting a live number.
Go helpdesk-side when WhatsApp is a high-volume front door, when the people answering it are a support or sales pod rather than licensed CRM users, when your WABA already exists somewhere you cannot easily move it, or when USD 75 per seat per month for a messaging add-on does not survive contact with the budget. This is where OmniDesk fits: the inbox, routing rules, AI auto-reply and SLA tracking sit with us, multiple WhatsApp numbers run from one dashboard, and Salesforce keeps receiving clean contact and case data.
Plenty of organisations end up running both — native for the licensed service team, helpdesk-side for the front-line pod — and that is a legitimate architecture as long as the opt-in ledger and the contact-matching rules are genuinely shared.
The Short Version
- A WhatsApp Salesforce integration has four routes, not one connector. Native Digital Engagement, AppExchange/BSP package, custom Cloud API build, or helpdesk-side sync. The choice is about who owns the conversation, not about features.
- The WABA rule decides your timeline. A native enhanced channel needs a WABA created inside the Salesforce setup flow; an existing WABA cannot be attached, and migrations leave history behind.
- Three bills, always. Salesforce seats (~USD 75/user/month for Digital Engagement, 25 conversations included), Meta's per-message charges at your customer's country rate, and implementation time.
- Known limits. No group chats, no B2B messaging, 250 templates per WABA, and Meta's 24-hour window unchanged by the CRM.
- Decide the data model first. Conversation object, Case-creation rule, opt-in field and phone normalisation — agreed before go-live, not after.