Messaging for In-App
Messaging for In-App is the Salesforce Service Cloud feature that lets customers message support agents and bots from inside a company's own iOS or Android app.
Definition
Messaging for In-App is the Salesforce Service Cloud feature that lets customers message support agents and bots from inside a company's own iOS or Android app. The company adds a Salesforce-supplied SDK to its mobile app, places a chat entry point in the interface, and incoming messages route through Service Cloud to an agent in the Service Console. The conversation lives inside the app, so the customer never leaves for a browser or email.
In June 2025, Salesforce began renaming the combined Messaging for In-App and Web product to Enhanced Chat. The In-App portion is also documented as Enhanced In-App Chat. It is the modern replacement for Legacy Chat (the older Live Agent based chat), which Salesforce is retiring on February 14, 2026. Messaging for In-App supports asynchronous conversations, so a customer can send a message, close the app, and pick the thread back up hours later.
How In-App messaging fits together inside Service Cloud
The UI SDK and the Core SDK
Salesforce ships two flavors of the In-App SDK for both iOS and Android. The UI SDK gives you a ready-made messaging interface that you can restyle with your own colors, text, and icons. The Core SDK exposes lower-level APIs with no interface at all, so a development team builds its own chat screen from scratch. The UI SDK includes the Core SDK, so picking UI does not lock you out of the lower-level calls. Salesforce guidance says most companies should use the UI SDK with light customization, since that balances build effort against a branded look. On iOS the frameworks are named SMIClientUI and SMIClientCore. You install them with Swift Package Manager (the public Swift-Package-InAppMessaging repository), with CocoaPods (the Messaging-InApp-UI or Messaging-InApp-Core pods), or by downloading the frameworks manually. Out of the box the SDK supports bots, pre-chat forms, file and photo sharing, push notifications, and an estimated wait time display. Because the SDK is a real mobile dependency, app teams treat an upgrade like any other library bump, with its own QA pass and store release.
The messaging channel and the deployment
Two Salesforce-side objects make In-App work. The first is a messaging channel, which represents the In-App conversation type and links it to routing. The second is an Embedded Service deployment, which holds the configuration the SDK reads at runtime: branding, pre-chat fields, business hours, and the routing target. You build both in Setup before any mobile code runs. The mobile app then references the deployment by its identifiers, so the SDK knows which org and which configuration to talk to. Keeping configuration server-side is deliberate. An admin can change pre-chat questions, swap the routing flow, or update business hours without a new app release. That separation is one reason Salesforce Messaging scales better than a hard-coded chat widget. The deployment also controls whether the channel allows authenticated sessions, which is what lets a logged-in app user arrive with their Contact and case history already attached.
Routing through Omni-Channel flows
When a customer starts a conversation, the message becomes a work item that Omni-Channel routes. Modern setups use an Omni-Channel flow, a Flow type built for routing, to decide where the conversation goes. The flow can send the work to a queue, a skill-based group, a specific service rep, or a bot, using whatever logic you put in it. One flow can branch by topic, language, or customer tier before it ever reaches a human. This is the same routing engine that handles cases, voice calls, and other messaging channels, so an agent sees In-App conversations in the Omni-Channel widget next to everything else. A practical rule from Salesforce: assign only one object type per Omni queue, so a queue meant for Messaging Sessions should not also carry Cases. Mixing object types in one queue causes routing conflicts. Flows also drive transfers, since active flows assigned to the Messaging channel appear as transfer destinations in the rep's Conversation component.
Where the conversation is stored
Each In-App conversation produces a Messaging Session record. That standard object holds the metadata for the conversation: the channel, the start and end times, the assigned agent, and the end user reference. The individual messages are stored as conversation entries linked to the session, which is how the full transcript survives after the chat window closes. Because the session is a real Salesforce object, you report on it like any other record. Common metrics include conversation volume by channel, average handle time, and bot deflection rate. You can also add custom fields to the Messaging Session, which teams use to stamp metadata such as the reason for contact or an AI agent outcome. Persisting the transcript on-platform is what enables the asynchronous experience. When the customer reopens the app days later, the SDK loads the existing session and the customer sees the whole history, not a blank screen.
Authenticated context and identity
The SDK can run in an unauthenticated mode, where anyone using the app can message support without signing in, or an authenticated mode that passes a verified user identity to Salesforce. When the app user is logged in, the SDK forwards an identity token so Service Cloud can resolve the matching Contact and surface that person's prior cases and account history. The agent then opens the conversation with full context instead of asking who they are talking to. Authenticated sessions also keep a conversation tied to the right person across devices, which matters because Enhanced Chat lets a customer continue the same thread on another phone or tab without disconnecting. Setting this up means configuring the deployment to allow authenticated users and wiring the app's existing login to produce the token the SDK expects. For many service teams, this identity bridge is the main reason to use In-App messaging over a generic third-party chat widget bolted onto the app.
Bots, async, and push notifications
Most In-App deployments open with a bot. An Agentforce or Einstein bot greets the customer, captures the reason for contact, attempts simple self-service, and hands off to a human when the request needs one. Good bot triage deflects a meaningful share of conversations before an agent is involved, which lowers cost per contact. The asynchronous model is the other defining trait. A customer does not have to sit and wait in an active session. They can send a message, leave, and return when it suits them, and the thread is still there. Push notifications are what make async usable. When an agent replies to a dormant conversation, the SDK can fire a push notification to the customer's phone so they know a response arrived and can tap back in. Without push, customers would miss replies and the async promise would fall apart. On iOS this requires the Push Notifications capability and the matching certificate or key, plus deployment-side configuration so Salesforce knows where to send the alert.
Enhanced Chat versus Legacy Chat
Messaging for In-App is part of the Enhanced Chat generation, which Salesforce positions as the successor to Legacy Chat. Legacy Chat, the older Live Agent based product, is retiring on February 14, 2026, and Salesforce urges teams to move before then to avoid an interruption. The practical differences are real. Legacy Chat was synchronous and session-bound: when the customer closed the window, the conversation was effectively over. Enhanced Chat keeps the history in the window beyond a single interaction, so the customer and the rep can stop and resume later. Customers can also message across tabs and devices without dropping the conversation. Enhanced Chat adds conversation intelligence rules that can notify a supervisor or rep in real time when a flagged keyword appears in a session. Salesforce also offers a Chat Transition Readiness Report to help teams assess what they need to change before switching. If you are starting fresh today, you build on Enhanced Chat directly rather than touching the legacy stack at all.
Set up Messaging for In-App in your org
Standing up Messaging for In-App is mostly a Service Cloud configuration job, done before any mobile code ships. You enable messaging, create the channel and the Embedded Service deployment, and wire routing through an Omni-Channel flow. The mobile team then drops in the SDK and points it at the deployment. These steps cover the Salesforce-side setup.
- Enable messaging and Omni-Channel
Turn on Messaging settings and Omni-Channel in Setup. Omni-Channel is the routing backbone, so In-App conversations have nowhere to go without it. Grant your service reps the permissions to handle messaging work.
- Create the messaging channel
Create a messaging channel for the In-App conversation type. The channel represents the conversation surface and is what you later attach routing and the deployment to.
- Create the Embedded Service deployment
In Setup, build an Embedded Service deployment for In-App. Configure branding, pre-chat fields, business hours, and whether authenticated users are allowed. The SDK reads this configuration at runtime.
- Build the Omni-Channel routing flow
Create an Omni-Channel flow that decides where conversations land: a queue, a skill, a specific rep, or a bot. Add branching logic for topic, language, or tier if you need it, then assign the flow to the Messaging channel.
- Hand the deployment to the mobile team
Give the app developers the deployment identifiers. They install the UI or Core SDK, place the chat entry point, and connect any login so authenticated sessions carry the customer's identity.
Questions the customer answers before the conversation starts, used to capture context and help routing.
A deployment setting that lets logged-in app users pass a verified identity so Service Cloud loads their Contact and case history.
Controls when the channel offers live help versus an offline or bot-only experience.
The queue, skill, rep, or bot the Omni-Channel flow sends each conversation to.
- Omni-Channel must be enabled first; with no routing engine, conversations have nowhere to go.
- Assign only one object type per Omni queue. A queue carrying both Messaging Sessions and Cases causes routing conflicts.
- Push notifications need their own setup (the Push Notifications capability and certificate or key on iOS), or customers miss agent replies in async conversations.
- SDK upgrades are real mobile releases. Coordinate with the app team early, because a surprise version bump needs its own QA and store submission.
- Plan the Legacy Chat move before February 14, 2026. Run the Chat Transition Readiness Report to find gaps before the retirement date.
Trust & references
Cross-checked against the following references.
- Get Started with Enhanced In-App ChatSalesforce
- Replace Legacy Chat with Enhanced ChatSalesforce
Straight from the source - Salesforce's reference material on Messaging for In-App.
Hands-on resources to go deeper on Messaging for In-App.
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 is Messaging for In-App?
Q2. What's the value of conversation persistence?
Q3. Who benefits from Messaging for In-App?
Discussion
Loading discussion…