Messaging Settings
Messaging Settings is the Salesforce Setup page where administrators create and manage the channels behind Messaging for In-App and Web, Salesforce's customer messaging product in Service Cloud.
Definition
Messaging Settings is the Salesforce Setup page where administrators create and manage the channels behind Messaging for In-App and Web, Salesforce's customer messaging product in Service Cloud. From this one page you add a channel, pick its type (a web deployment, an in-app mobile deployment, or a third-party channel such as WhatsApp or Apple Messages for Business), give it a developer name, and connect it to the routing and automation that move conversations to the right place.
A channel created here is the link between a customer touchpoint and the rest of your org. It ties an inbound conversation to an Omni-Channel queue or flow, to an optional bot, and to the standard objects that record the chat (Messaging Session and Conversation Entry). Because every live conversation runs through these settings, a change made here can reach real customers immediately, which is why the page sits near the center of any messaging rollout.
How the Messaging Settings page is wired
What you actually create on the page
The Messaging Settings page is reached in Setup through Quick Find. Its main action is New Channel, which starts a short wizard. You choose a channel type first, because that decision drives every field that follows. Messaging for In-App and Web is the type for chat that you embed in a website or a mobile app, and it is the most common starting point. The same page also hosts third-party channels such as WhatsApp, Apple Messages for Business, Facebook Messenger, LINE, and SMS, each of which needs its own provider account before the channel can go live. Each channel record carries a Channel Name that people read, a Developer Name (the API name used by automation and metadata), and a channel-specific configuration block. For a web channel you supply the domain where customers will chat. The channel record is what the rest of Salesforce references, so naming it clearly matters more than it looks. Treat the channel as a long-lived object: deployments, routing, and bots all point at it.
Channel types and provisioning
Not every channel is self-service. Web and in-app channels can be stood up entirely inside Salesforce, since you control the website or the mobile app. Third-party channels depend on an outside platform, and that platform owns the identity of the customer endpoint. WhatsApp needs a WhatsApp Business account and a phone number approved through the WhatsApp Business Platform. Apple Messages for Business needs registration through Apple Business Register. Facebook Messenger needs a connected Facebook Page. SMS needs a provisioned long code or short code. This split changes your project plan. A web channel can be tested the same afternoon you enable the feature. A WhatsApp channel can take days, because number approval and business verification sit with the provider, not with you. Build the dependency into the schedule and start the external requests early. Inside Messaging Settings the steps look similar across channels, but the lead time, the credentials, and the people who can grant them differ a lot from one channel to the next.
Routing through Omni-Channel
A channel does nothing useful until inbound conversations reach an agent. Messaging for In-App and Web routes through Omni-Channel, and the recommended path is an Omni-Channel flow. In the flow you add a Route Work action, set the service channel to Messaging, and choose where the conversation goes: a queue, a specific user, a bot, or skills-based assignment. The flow can branch on pre-chat answers, on the channel itself, or on data you look up, so two customers entering the same web chat can land in different queues. Before any of this works the org needs Omni-Channel enabled, a service channel that supports the Messaging Session object, and at least one queue that holds messaging work. Capacity and presence settings then decide how many conversations an agent can hold at once. Routing is where most go-live problems show up. A queue with no members, a flow that never assigns, or a presence configuration that blocks new work all produce conversations that sit unanswered, so test the full path with a real session before you publish.
Bots and the handoff to a human
Many deployments put a bot in front of the agent. With Agentforce or an Einstein Bot you can answer common questions, collect details, and hand off only the conversations that need a person. The routing target in your Omni-Channel flow can be the bot itself, and the bot decides when to escalate to a queue. The Messaging Settings channel is the surface all of this hangs from, since the channel is what the flow and the bot both reference. Plan the handoff with the customer in mind. A bot that drops the customer into a queue with no summary forces the agent to ask for information the customer already gave. Carry the transcript and any collected fields across the handoff so the agent picks up mid-thread. Decide up front which intents the bot owns and which it must escalate, because an over-eager bot frustrates people while an under-used one wastes the investment. The split between bot and agent is a design decision, not a setting you flip once and forget.
Deployments, components, and the customer experience
A channel describes where messages come from. A deployment describes how the chat looks and behaves at the customer end. For a web channel you generate an Embedded Service deployment that produces the snippet your web team adds to the site. For a mobile channel you wire the deployment into the Salesforce mobile SDK. Branding, the pre-chat form, and business hours are configured against the deployment, not the raw channel. Inside conversations you can send more than plain text. Enhanced messaging components include buttons, list pickers, time selectors, forms, a secure form for sensitive data, payment requests, and authentication requests. These components are shared assets, so a bot and a live agent can both use the same list picker. That sharing is convenient and also a coordination point: editing a component changes it everywhere it appears. Keep an inventory of which components each channel and bot relies on, so a quick edit for one team does not quietly reshape a flow another team owns.
Data model, retention, and reporting
Every conversation writes records. A Messaging Session represents one conversation, and Conversation Entry rows capture the individual messages and events inside it. These objects connect to the rest of Service Cloud, so a session can be linked to a Case, a Contact, or a Lead, and reports can be built on volume, response time, and resolution rate. Messaging Settings does not generate the reports, but the channels you create here are what populate the objects those reports read. Retention deserves a deliberate decision. Conversation data can include personal information, and many regulations expect you to keep it no longer than needed. Set retention against your compliance and business requirements rather than accepting whatever the default happens to be. Because the session and entry objects are standard, the same reporting, sharing, and field-level security tools you already use apply to messaging data. Get an agent into a permission set that grants Messaging access early, since without it the conversation simply will not appear in their Omni-Channel widget.
Stand up a Messaging channel end to end
Create a Messaging for In-App and Web channel and connect it to routing so a real conversation can reach an agent. This assumes you have a Service Cloud org with Messaging available and a user who can edit Setup.
- Enable the foundation
Turn on Omni-Channel, then create or confirm a service channel that supports the Messaging Session object and a queue that will hold messaging work. Without these, a channel has nowhere to route conversations.
- Create the channel
In Setup, open Messaging Settings, click New Channel, choose Messaging for In-App and Web, and give it a clear Channel Name and Developer Name. For a web channel, enter the domain where customers will chat.
- Build the routing flow
Create an Omni-Channel flow with a Route Work action. Set the service channel to Messaging and choose the target: a queue, a user, a bot, or skills. Attach the flow to the channel so inbound sessions follow it.
- Generate the deployment
Create an Embedded Service deployment (or wire the mobile SDK) tied to the channel. Configure branding, the pre-chat form, and business hours here, then publish the snippet for your web or app team.
- Grant access and test
Assign agents a permission set that includes Messaging, set their Omni presence to available, and run an end-to-end test conversation to confirm it routes and appears in the agent widget before going live.
Pick Messaging for In-App and Web for embedded chat, or a third-party type such as WhatsApp or Apple Messages for Business, which each require an external provider account first.
In the Omni-Channel flow, route to a queue, a single user, a bot, or skills-based assignment depending on how your team is staffed.
Optionally place an Agentforce agent or Einstein Bot as the first responder, escalating to a human queue only when needed, and carry context across the handoff.
Decide how long Messaging Session and Conversation Entry data is kept, aligned to your compliance requirements rather than the default.
- A channel without a working routing flow and a staffed queue leaves conversations unanswered, so always test the full path before publishing.
- Third-party channels like WhatsApp need provider approval that can take days; start those external requests well before your go-live date.
- The Developer Name is referenced by metadata and automation, so changing it later can break dependent flows and integrations.
- Enhanced messaging components are shared between bots and agents; editing one changes it everywhere it is used.
Prefer this walkthrough as its own page? How to Messaging Settings in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Messaging Settings.
- Set Up Routing for Messaging ChannelsSalesforce
- Plan for Messaging for In-App and WebSalesforce
Hands-on resources to go deeper on Messaging Settings.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the Messaging Settings page in Setup control?
Q2. What does enabling WhatsApp through Messaging Settings additionally require beyond flipping the toggle?
Q3. Which routing options does the Messaging Settings page expose for inbound messages?
Discussion
Loading discussion…