Deploying an Agentforce agent to WhatsApp and SMS

You built an Agentforce Service Agent, it tests beautifully in the preview window, and now someone asks the obvious question: can customers actually reach it on WhatsApp? Because that’s where they are. In large parts of the world WhatsApp is customer service, SMS is how a delivery exception reaches someone, and almost nobody is sitting on your website waiting for a chat bubble to appear. The demo lives in a Salesforce chat widget; the customers live somewhere else entirely.

Getting the agent from that widget onto WhatsApp and SMS is not a checkbox, and the part that trips teams up is that the agent barely changes — the deployment is almost entirely a routing problem solved in an Omni-Channel Flow, plus a set of channel prerequisites (a WhatsApp Business Account, Enhanced Messaging, a 24-hour reply window) that have nothing to do with the agent and everything to do with whether a message ever reaches it. This post is the whole build: how an agent connects to a messaging channel, the WhatsApp specifics that generate the most support tickets, the handoff to a human that most teams forget until launch day, and the three separate meters a messaging agent bills against.

The one hard prerequisite: Enhanced, not Standard

Before any of the fun, one gate decides whether this project is possible at all. Agentforce agents run only on Enhanced Messaging channels, on Enhanced Omni-Channel. Standard messaging channels support standard bots only — not AI agents. If your org is still on Standard Omni-Channel or Standard SMS/WhatsApp channels, an Agentforce agent physically cannot be routed to them.

This isn’t a footnote; it’s a migration. Salesforce has been retiring the Standard stack on a schedule: Standard WhatsApp was retired in October 2025, Standard SMS and Facebook Messenger in February 2026, and orgs on Standard Omni-Channel are being auto-upgraded to Enhanced Omni-Channel through 2026 with full Standard retirement targeted for the Summer ‘26 timeframe. Check today which you’re on — Setup tells you — because “we’ll just point the agent at our existing WhatsApp number” quietly becomes “we first have to stand up Enhanced Messaging and re-onboard the number,” and that reorders your whole plan. Verify the current retirement dates against Salesforce’s live release notes before you commit a timeline; these are exactly the dates that shift.

The mechanism: an agent is a routing target

Here’s the mental model that makes everything else click. On an Enhanced Messaging channel, the first inbound message from a customer launches an Omni-Channel Flow — an inbound flow whose job is to decide what happens to this conversation. Identify the contact. Create or find a case. Set some context. And then route the work — to a queue of human reps, or, now, to your agent. The agent is just another routing target.

That routing happens in a Route Work element inside the flow. Historically the agent reused the Einstein Bot routing plumbing, so you picked the “Bot” routing type; Salesforce has since added a dedicated Agentforce Service Agent routing type — you select it, then pick your agent by name in the Route To field, and you specify a fallback messaging queue for the conversations the flow can’t route to the agent. That fallback is not optional in practice: without it, a conversation the agent can’t take has nowhere to go.

The whole inbound flow, in order, reads like this:

Get the MessagingSession record the flow is running for.
Identify the Contact (match on the sender’s phone number / WhatsApp ID) and create a Case if your process needs one.
Map any pre-chat / channel variables you captured into flow variables, and save them to the MessagingSession with an Update Records element.
Route Work → routing type Agentforce Service Agent → your agent → fallback queue.

Once the flow is built, you activate it and then wire it to the channel: open the messaging channel’s Omni-Channel settings and set your flow as its routing flow. (The newer Agentforce Builder exposes this on a Connections tab / “Deploy Your Agent to Channels,” where the routing type is again Agentforce Service Agent, or you point it at an existing Omni-Flow you prefer to own by hand.) Two structural rules to design around: one agent can serve many channels, but a single channel routes to only one agent, and you must never build logic that routes the same conversation to both a human rep and the agent at once.

A pitfall worth pre-empting, because it burns an afternoon for almost everyone: if your agent doesn’t appear as a selectable routing target, or your flow doesn’t appear in the channel’s settings, the fix is almost always the same — activate the agent (and the flow) and refresh the builder. Inactive artifacts don’t show up in each other’s pickers.

WhatsApp is its own animal

SMS and web messaging are relatively plain. WhatsApp carries a set of Meta-imposed rules that are not Salesforce’s and won’t bend to your architecture, so design around them from the start.

A WhatsApp Business Account (WABA). Each Enhanced WhatsApp channel is linked to a WABA, and setup walks you through associating a dedicated phone number — one not already tied to a personal WhatsApp account, able to receive an international verification message. This is Meta’s onboarding, and it takes real calendar time; don’t plan a launch as if provisioning a WhatsApp number is instantaneous.

The 24-hour customer care window. This is the rule that reshapes agent design. When a customer messages you, a 24-hour window opens during which your agent can reply freely with normal messages. Once it closes, you can only reach that customer with pre-approved message templates — content Meta has reviewed. Templates can go to opted-in customers any time, but free-form replies cannot. For a reactive service agent this is usually fine — the customer just messaged, so the window is open — but the moment you want the agent to follow up (“your part arrived, want me to book the install?”) a day later, you’re in template territory, and templates need approval lead time (there’s a ceiling in the low hundreds of templates per WABA, and moving them between accounts can take up to a day). Plan the templates before launch, not when the first follow-up fails to send.

Consent is a hard gate. Business-initiated WhatsApp messaging requires prior opt-in — you have to have captured that the person agreed to be messaged on WhatsApp, name the business, and offer an easy opt-out. An agent that blasts an un-opted-in number isn’t just impolite; it’s outside Meta’s rules.

One naming trap to note: Salesforce now has Unified Messaging WhatsApp channels (the Data 360–based architecture that spans marketing, sales, and service) alongside the Enhanced service channels. They’re a different setup, not an upgrade path — you can’t carry an existing number across — and the confirmed, documented path for routing an Agentforce Service Agent today is the Enhanced WhatsApp channel. If someone hands you a Unified WhatsApp channel and expects an agent on it, stop and verify against current docs before you promise it.

The handoff nobody builds until launch day

A service agent that can’t reach a human is a trap you set for your own customers. On a website widget the escape hatch feels obvious; on WhatsApp, where the customer can’t see a queue or a “talk to an agent” button, the handoff has to be built, and it’s a genuinely separate piece of configuration from the inbound routing.

Escalation runs through the agent’s outbound Omni-Channel Flow — distinct from the inbound flow that routed the conversation in the first place. The pattern:

Define an Escalation topic in the agent so it recognizes when a conversation should leave it — frustration, an explicit “get me a person,” a case type it isn’t scoped for.
On that topic, the agent invokes an action that runs the outbound flow. Use the Check Rep Availability for Routing action first, so the agent can tell the customer the truth about wait times or offer a callback instead of dumping them into a silent queue.
The flow routes the MessagingSession to a human queue, passing the Messaging Session ID and any context you captured — an EscalationReason, the case, the customer’s verified identity — so the human doesn’t reopen with “how can I help you?” The full conversation history transfers, so the rep sees everything the agent already did.

For this to land, your human reps need the Omni-Channel widget live in their Service Console; the handoff routes work to people who have to be able to receive it. This is the messaging-channel expression of the same principle behind every human-in-the-loop design: the agent handles what it’s scoped and grounded for, and the seam to a human is engineered, tested, and context-preserving — not an afterthought bolted on when QA asks “what happens when it can’t help?” It’s the same context-carrying handoff we flagged when migrating Einstein Bots to Agentforce: the Omni-Channel Flow is what carries state across the seam.

Session context: what the agent knows about the conversation

An agent on a messaging channel automatically gets context variables sourced from the MessagingSession record’s fields, including custom ones. They’re prefixed $Context and are read-only — you reference them in the agent’s instructions and actions, you don’t mutate them. This is how the agent knows the channel, the verified contact, the case, the language.

Language deserves a specific note because it’s a common miss. On a MessagingSession, EndUserLanguage controls the agent’s initial language — but for a Service Agent it doesn’t populate itself. You set it in the inbound Omni-Channel Flow: capture the language as a channel/pre-chat variable and map it into EndUserLanguage on the session. Skip that and a Spanish-speaking WhatsApp customer meets an agent that opens in English. The values you capture at the top of the flow — language, verified identity, the reason they reached out — are the grounding the agent starts from, and they’re set by your flow, not by magic.

When the routing flow is the wrong deployment

The Omni-Channel Flow path is right when you want a real service channel: native routing, human handoff, cases, queues. It is not the only way an agent meets a user, and picking the wrong one costs a rebuild.

Omni-Channel Flow (this post) — native Enhanced Messaging channels (SMS, WhatsApp, web/in-app), with routing logic and human escalation. The default for customer service.
Messaging for In-App and Web (MIAW), embedded — the fastest way to drop a chat widget on a public web or Experience Cloud page; still supports human handoff. Reach for it when the requirement is “chat on our site,” not “the agent on the customer’s own messaging app.”
The Agent API / headless — for driving the agent from your own backend or app with no Omni-Channel routing and, critically, no built-in human escalation. It’s the right call for automation and custom apps and the wrong call the moment you need a person to be able to take over.
Bring Your Own Channel (BYOC) — for connecting the agent to a channel Salesforce doesn’t natively provide: a proprietary messaging service (BYOC for Messaging) or a partner CCaaS platform bringing its own voice and digital channels into Salesforce (BYOC for CCaaS). A RoutingOwner setting decides whether Salesforce Omni-Channel or the partner platform routes the session to and from the agent.

And voice is its own thing again — an agent answering the phone has a sub-second latency budget and no buttons, which rewrites topic and confirmation design. Text channels are more forgiving, but the deployment surface — pick the right one — is the same kind of decision.

The three meters — because there are three

The cost question everyone asks — “does WhatsApp cost more than the web widget to run the agent?” — has a cleaner answer than expected on one axis and a messier one overall. Agentforce consumption is channel-agnostic: a WhatsApp session is billed the same as a web session, under the same model you already reasoned about for Agentforce pricing — conversations (a conversation being a 24-hour interaction session, regardless of message count) or Flex Credits per action. The channel doesn’t change that meter.

What surprises teams is that there are three meters, not one, and only the first is Agentforce:

Agentforce consumption — conversations or Flex Credits, as above. The reasoning and actions.
Digital Engagement licensing — Enhanced Messaging (SMS, WhatsApp, and friends) is a separate, additive Service Cloud add-on, licensed per user, with its own included allotment of messaging conversations. The agent runs on top of a licensed messaging channel; it doesn’t replace the need for one.
Meta / carrier pass-through — WhatsApp and SMS are paid channels underneath. Each customer-initiated WhatsApp conversation consumes an allowance, and outbound template messages are metered by Meta on a zone basis (a single notification to some countries can consume multiple outbound messages). SMS carries carrier costs. None of this is Salesforce’s meter, and all of it hits your bill.

The practical consequence: forecast the agent’s Agentforce cost the same way on any channel, then add Digital Engagement licensing and the Meta/carrier line separately. A messaging agent’s true run-rate is the sum of three invoices, and the two that aren’t Agentforce are the ones a pilot budget usually forgets. Confirm all current list prices with Salesforce and Meta before you commit a number — the published rates move, and this post won’t be your rate card.

What to actually do

Confirm you’re on Enhanced Omni-Channel and Enhanced Messaging first; if you’re not, that migration is the project’s real first phase, not a preflight check. Build the inbound Omni-Channel Flow as the actual deliverable — identify the contact, set context (including EndUserLanguage), Route Work to the agent with a real fallback queue — and remember to activate everything so it shows up in the pickers. For WhatsApp, start the WABA onboarding and template approvals early, and design for the 24-hour window and opt-in consent from day one rather than discovering them when a follow-up won’t send. Engineer the human handoff as a first-class outbound flow that carries the session ID, the reason, and the history, and make sure your reps actually have the Omni-Channel widget to receive it. Then budget for three meters, not one.

Do that and the agent you built for a chat widget becomes an agent your customers reach where they already are — which, for most service organizations and especially in retail and consumer channels, is the difference between a demo and a deployment. If you’re standing up an agent on WhatsApp or SMS and want the routing, the handoff, and the three-meter cost picture designed deliberately, talk to us — putting a governed agent on the channels your customers actually use is exactly the work we do.

Understanding the basics

How do you connect an Agentforce agent to WhatsApp?

You route to it from an Omni-Channel Flow. On an Enhanced WhatsApp channel, the first inbound message launches an Omni-Channel Flow; inside it you add a Route Work element, choose the Agentforce Service Agent routing type, select your agent, and set a fallback messaging queue. You activate the flow and set it as the channel’s routing flow (or use the Agentforce Builder Connections tab). The channel itself must be an Enhanced Messaging channel linked to a WhatsApp Business Account — Standard channels support only standard bots, not agents.

Does an Agentforce agent cost more to run on WhatsApp than on web chat?

The Agentforce consumption itself is channel-agnostic — a WhatsApp session bills the same as a web session, by conversations or Flex Credits. But a messaging agent bills against three meters, not one: Agentforce consumption, the separate Digital Engagement licensing for Enhanced Messaging, and the Meta/carrier pass-through costs of WhatsApp or SMS themselves (customer-initiated conversation allowances and zone-based outbound template charges). The two non-Agentforce meters are the ones pilots usually forget.

What is the WhatsApp 24-hour window and why does it matter for an agent?

When a customer messages your business on WhatsApp, a 24-hour customer care window opens during which the agent can reply with normal free-form messages. After it closes, you can only reach that customer with pre-approved message templates. For a reactive service agent the window is usually open (the customer just wrote in), but any proactive follow-up sent later must use an approved template — and templates require Meta review and opt-in consent, so plan them before launch rather than discovering the limit when a follow-up silently fails.

Putting a governed Agentforce agent on the channels your customers actually use — WhatsApp, SMS, in-app — with a real human handoff and an honest cost model? Talk to us. Designing the routing flow, the escalation seam, and the three-meter budget is the work we do.

Deploying an Agentforce agent to WhatsApp and SMS: the routing flow is the whole build