Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

Straight answer: Messaging for In-App and Web is asynchronous. The customer can close the tab, get on a train, come back an hour later and the conversation is still there. That single difference from Chat changes the routing model, the capacity model and how you measure the channel, and it is why Salesforce is pointing new implementations here.

The objects

  • Messaging Channel represents the channel itself, one per deployment surface.
  • Messaging End User is the person on the other end, identified either anonymously or through a verified identity.
  • Messaging Session is a conversation, and it is the record you report on.
  • Embedded Service Deployment carries the appearance and behaviour of the widget on your site or in your app.

How it differs from Chat, concretely

Persistence is the headline. The consequences are what you actually have to design around.

A session outlives the agent’s attention. A customer who stops replying does not end the conversation. The session stays open, holding agent capacity, until something closes it.

Capacity means something different. With Chat, an agent holding three chats is typing to three people. With messaging, an agent can reasonably hold more, because most of those conversations are waiting on the customer at any moment. Starting capacity higher than you would for chat is correct, and the right number comes from watching how many sessions are actually active at once.

The customer may not be there. Agents used to synchronous chat will keep sending “are you still there” messages. That is a Chat habit and it does not apply. Retrain it explicitly, because it clutters the transcript and irritates people.

Session handling, which is the real design work

Sessions do not end themselves usefully unless you configure them to. Three things need deciding:

  1. The inactivity timer. How long a session with no customer reply stays open before it ends. Too short and a customer who stepped away loses their agent. Too long and agent capacity is consumed by conversations nobody is having. Start in the tens of minutes and watch the abandon numbers.
  2. What the agent can do. Agents need a clear rule for when to end a session rather than leaving it open. Without one, capacity silently disappears over the course of a shift and the queue backs up for no visible reason.
  3. What happens at end. The session record persists regardless. Decide whether it creates a case, updates one, or does neither.
SELECT Id, Status, StartTime, EndTime, Owner.Name, MessagingEndUserId
FROM MessagingSession
WHERE Status = 'Active' AND StartTime < :cutoff
ORDER BY StartTime

Routing through a flow

Messaging routes through Omni-Channel, and the recommended route is an Omni-Channel flow rather than pointing the channel straight at a queue.

The flow runs when a conversation starts and decides where it goes. That means you can read the pre-chat answers, look up the end user against existing contacts, check whether they have an open case, and route accordingly, all in a flow you can read and change without a deployment.

Identity and pre-chat

An anonymous visitor gives you whatever they type. A verified customer, authenticated through your app or site and passed through with a signed token, arrives already matched to a contact.

Bots in front

The channel is designed for a bot to take the conversation first and escalate to a human. That is a reasonable pattern when the bot handles a small number of well-defined requests and hands over quickly.

The failure mode is a bot that tries to handle everything and makes the customer fight through three rounds of misunderstanding before reaching a person. Give the customer an obvious route to a human from the first message, and measure the escalation rate. A high escalation rate is information, not failure.

Frequently asked

Does a session automatically create a case? No. Build it if you want it, and only for conversations needing follow-up. A case per session destroys your case metrics.

Can a customer resume on a different device? With verified identity, yes. Anonymously, the conversation is tied to the browser, so a different device starts fresh.

How do I report on first response time? From the session timestamps. There is no equivalent of an email first-response convention here, so define what counts as the first agent message and calculate it consistently.