Chat, Messaging and Experience Cloud Self-Service

Why This Topic Matters

The Salesforce Advanced Administrator exam dedicates a significant portion of its Cloud Applications domain to Service Cloud and Experience Cloud capabilities. Within that domain, digital engagement channels (Chat and Messaging) and customer self-service (Experience Cloud sites) are tested because they represent how modern service organizations scale support without scaling headcount. An advanced admin is expected to know not just that these tools exist, but which tool solves which business requirement, what setup objects are involved, how routing works through Omni-Channel, and how external users are licensed and given record access.

Exam questions in this area are almost always scenario-based: a company wants to let customers reach agents from a website, continue a conversation over SMS or WhatsApp, or find answers themselves before opening a case. Your job is to pick the correct feature and the correct configuration step. Mastering the vocabulary and the decision logic is what earns the points.

Part 1: Chat (formerly Live Agent)

What it is
Chat is Salesforce's real-time, synchronous web chat channel. A visitor on a company website or in a mobile app clicks a chat button, optionally completes a pre-chat form, and is connected live to a support agent working in the Service Console. When the conversation ends, a Chat Transcript record is created and can be related to a Case, Contact, Lead, or Account.

Important context: Salesforce has announced the retirement of Chat in favor of Messaging for In-App and Web. The exam may still reference Chat terminology, so you should understand both and recognize that Messaging is the strategic successor.

Key setup components
• Enable Chat in Setup (Chat Settings).
• Skills – define agent expertise (for example, Billing, Technical) and are used by legacy chat routing.
• Chat Agent Configurations – control agent-side behavior: chat capacity, auto-greeting, sneak peek, transfer options, supervisor permissions, and Quick Text access. Assigned to users or profiles.
• Chat Deployments – define where chat appears (the website domain, branding, and the generated code snippet).
• Chat Buttons – the visitor-facing entry point. The button specifies the routing type (Omni-Channel queue, skills, or least active/most available), the pre-chat form, post-chat page, and queue overflow behavior.
• Embedded Service Deployment (Embedded Chat / Snap-ins) – the modern way to place a chat window on an external website or Experience Cloud site. It bundles the deployment, button, branding, pre-chat fields, and offline support form into one code snippet.
• Omni-Channel – the recommended routing engine. Chats are routed to agents based on presence status, capacity, and queue or skill membership.
• Supervisor Panel – lets supervisors monitor live chats, whisper to agents, and view agent status in real time. Enabled via Chat Agent Configuration supervisor settings.
• Quick Text – predefined messages agents insert into chats; must be enabled and shared via folders.
• Chat Console Settings / Lightning Console App – agents work chats from a console app with the Omni-Channel utility added to the utility bar.

How a chat flows end to end
1. Admin enables Chat and Omni-Channel, creates a queue (for example, Chat Support) with chat routing configuration.
2. Admin builds a Chat Button that routes to that queue, then an Embedded Service Deployment that uses the button.
3. The generated code is placed on the website.
4. A visitor clicks the button, fills in pre-chat fields (which can pre-populate or match Contact/Case records).
5. Omni-Channel pushes the chat to an available agent whose presence status includes the chat channel.
6. The agent responds in the console, uses Quick Text, may create or link a Case, and can transfer to another agent or skill.
7. On close, a Chat Transcript is saved with the full conversation, wait time, and visitor details.

Part 2: Messaging

What it is
Messaging is Salesforce's asynchronous conversational channel. Unlike Chat, a messaging session persists: a customer can send a message, walk away, and reply hours later, and the same conversation continues. Messaging supports SMS, WhatsApp, Facebook Messenger, Apple Messages for Business, and Messaging for In-App and Web (MIAW), which replaces Chat for websites and mobile apps.

Key objects and components
• Messaging Channel – the configured phone number, WhatsApp account, or in-app/web deployment. Channels come in Standard and Enhanced flavors; Enhanced channels support richer features like Omni-Channel Flows and the Enhanced Conversation component.
• Messaging User (Messaging End User) – the record representing the customer's identity on a channel (for example, a phone number). It is linked to a Contact, Lead, or Account.
• Messaging Session – the conversation record; it is routed via Omni-Channel and appears in the agent console. Sessions can be related to Cases.
• Messaging Templates – pre-approved outbound messages (especially required for WhatsApp) that can include merge fields.
• Omni-Channel Flow / Routing Configuration – decides which queue, skill, or agent gets the session.
• Einstein Bots – can be placed in front of Chat or Messaging to handle common questions, collect information, and hand off to an agent.
• Messaging Components in the Console – the Conversation component, Quick Text, and the Messaging Session record page.

How Messaging works
1. Enable Messaging in Setup and accept terms.
2. Create a Messaging Channel (for example, request an SMS long code or connect a WhatsApp Business account).
3. Create an Omni-Channel queue and routing configuration (or an Omni-Channel Flow) and assign the channel to it.
4. Assign agents a presence status that includes the Messaging channel and give them the Messaging permission set license.
5. When a customer texts the number, a Messaging User is created or matched, a Messaging Session opens, and Omni-Channel routes it.
6. Agents reply in the Service Console; the session stays active until ended, and the customer can resume later on the same thread.
7. Agents can initiate outbound messages using templates where the channel allows it.

Chat vs Messaging – the core distinction
• Chat: synchronous, real-time, session ends when the window closes, Chat Transcript created.
• Messaging: asynchronous, persistent, multiple third-party channels, Messaging Session record, better for mobile customers and long-running conversations.
• Both: rely on Omni-Channel for routing, support Quick Text, Einstein Bots, and the Service Console.

Part 3: Experience Cloud Self-Service

What it is
Experience Cloud (formerly Community Cloud) lets you build branded, external-facing sites where customers, partners, or the public can find knowledge articles, ask questions, log and track cases, and interact with your data under controlled sharing rules. For self-service, the goal is case deflection: helping customers solve problems without contacting an agent.

Self-service templates
• Help Center – lightweight, public knowledge-centric site designed for unauthenticated (guest) visitors to search articles and optionally contact support.
• Customer Service (formerly Napili) – the most full-featured self-service template: Knowledge search, Topics, Chatter Questions, Contact Support/Case creation, My Cases, and Case Deflection.
• Customer Account Portal – a private, login-required site for customers to view and update their own records (cases, orders, account details) with a dashboard-style layout.
• Partner Central – designed for channel partners (leads, opportunities, deal registration); not primarily a self-service support template but frequently appears as a distractor.
• Build Your Own (Aura or LWR) – blank templates for custom builds.

Key self-service features and components
• Knowledge integration – articles are exposed via Data Categories; guest and member profiles need Data Category Visibility and read access to article types.
• Case Deflection component – as a customer types a case subject, suggested articles and discussions appear to deflect the case.
• Contact Support / Create Case – lets authenticated or guest users submit cases; guest case creation requires the Guest User profile to have Create on Case.
• Question-to-Case – lets moderators or agents escalate a Chatter question in the site into a Case.
• Topics – organize articles and discussions; Topic Catalog and Featured Topics drive navigation.
• Embedded Chat or Messaging – you can place an Embedded Service component on the site so self-service and agent channels coexist.
• Reputation and Moderation – reputation levels reward engagement; moderation rules block or flag inappropriate content.
• Audience Targeting – shows different page variations or components to different audiences (profile, location, record type, etc.).
• Self-Registration and Login – configured in Administration settings; self-registration creates Contact and User records under a designated account and profile.

Licensing for external users
• Customer Community – high-volume customers; no roles, cannot use sharing rules or role hierarchy. Record access is granted through Sharing Sets (access to records related to the user's Account or Contact) and Share Groups (sharing records owned by Customer Community users with internal users).
• Customer Community Plus – adds roles, sharing rules, reports and dashboards, and delegated admin; appropriate when customers need role-based access or to see all cases for their account via the role hierarchy.
• Partner Community – for partners who need leads, opportunities, campaigns, and full sharing capabilities.
• Channel Account – priced per partner account rather than per user.
• Member-based vs Login-based – member-based is per named user per month; login-based is a pool of logins consumed per login, better for infrequent users.

Sharing and security concepts
• External Organization-Wide Defaults – separate OWD settings for external users; they can be equal to or more restrictive than internal defaults, never more permissive.
• Guest User Profile – controls what unauthenticated visitors can see and do. Guest users cannot be granted record access via OWD; access comes only through guest user sharing rules, and guest users never own records by default (records they create are reassigned to a default owner).
• Super User Access – available to Customer Community Plus and Partner users to see records owned by users below them in the account.
• Site Activation and Publishing – changes in Experience Builder must be published; the site must be Active for members to log in; members are added by profile or permission set.

How a self-service site is built
1. Enable Digital Experiences in Setup and choose a domain name.
2. Create a new site and select a template (for example, Customer Service).
3. Configure Knowledge: enable Lightning Knowledge, create Data Categories, and grant visibility to member and guest profiles.
4. In Experience Builder, add or configure components: Search, Featured Topics, Case Deflection, Contact Support, My Cases, Embedded Chat.
5. In Administration settings, add member profiles, configure login, self-registration, and the Guest User profile permissions.
6. Set External OWDs and create Sharing Sets or sharing rules so customers see only their own cases.
7. Preview, publish, and activate the site. Send welcome emails if required.

Part 4: Exam Tips – Answering Questions on Chat, Messaging and Experience Cloud Self-Service

Tip 1: Match the keyword to the channel.
• Real-time, live, immediate, website visitor is waiting, pre-chat form, transcript → Chat (or Messaging for In-App and Web if the question emphasizes the modern approach).
• SMS, text message, WhatsApp, Facebook Messenger, asynchronous, resume the conversation later, mobile customers → Messaging.
• Deflect cases, find answers without contacting support, FAQ, knowledge articles, public help → Experience Cloud Help Center or Customer Service template with Knowledge and Case Deflection.
• Customers view and update their own account, orders, and cases behind a login → Customer Account Portal.
• Partners, deal registration, leads, opportunities → Partner Central with Partner Community licenses.

Tip 2: Omni-Channel is the routing answer.
Whenever a question asks how to distribute chats or messaging sessions based on agent availability, capacity, or skills, the answer involves Omni-Channel (queues, routing configurations, presence statuses, skills-based routing, or Omni-Channel Flows). Legacy chat-button routing exists but Omni-Channel is the best practice.

Tip 3: Know which setup object controls which behavior.
• Agent-side behavior (capacity, sneak peek, auto-greeting, supervisor rights) → Chat Agent Configuration.
• Where the chat window lives and how it looks → Deployment or Embedded Service Deployment.
• Visitor entry point, routing, and pre-chat form → Chat Button.
• Canned responses → Quick Text.
• Monitoring live conversations and whispering to agents → Supervisor Panel.
• Customer identity on a messaging channel → Messaging User.
• The conversation record → Chat Transcript (Chat) or Messaging Session (Messaging).

Tip 4: Licensing questions hinge on roles and sharing.
If customers need to see cases from other contacts on the same account via role hierarchy, use reports and dashboards, or need sharing rules → Customer Community Plus. If they only need their own records or records tied to their account via a Sharing Set, and volume is high → Customer Community. Infrequent visitors → login-based licenses. Partners → Partner Community or Channel Account.

Tip 5: Guest users have strict limitations.
Unauthenticated visitors get access only through the Guest User profile and guest user sharing rules. They cannot see records through OWD, cannot be record owners, and need explicit Create permission (and sometimes a Flow or Web-to-Case alternative) to submit cases. If a scenario says customers must see their case history, the answer requires authentication.

Tip 6: Knowledge visibility is a two-part answer.
If users cannot see articles on the site, check both object/article permissions and Data Category Visibility on the profile or permission set. Also confirm the article is published and the channel includes Public Knowledge Base or Customer/Partner as appropriate.

Tip 7: Remember the publish and activate steps.
A classic trick question: an admin made changes in Experience Builder but members do not see them. The fix is to Publish. Members cannot log in at all? The site may not be Active, or their profile may not be added as a member.

Tip 8: External OWDs can only be equal or more restrictive.
If a question tries to set external sharing more open than internal, it is wrong. Use Sharing Sets for Customer Community users because sharing rules do not apply to them.

Tip 9: Eliminate distractors by scope.
Web-to-Case and Email-to-Case are case intake channels, not conversational channels. Service Cloud Voice is telephony, not Chat. Chatter Groups are internal collaboration, not self-service. Partner Central is not a customer self-service template. Recognizing out-of-scope options quickly narrows the choices.

Tip 10: Prefer the declarative, Salesforce-recommended path.
The exam rewards answers that use standard features: Embedded Service Deployment over custom code, Omni-Channel over manual assignment, the Case Deflection component over custom search, Sharing Sets over custom Apex sharing, and Messaging for In-App and Web where the question signals forward-looking design.

Quick Review Checklist
• Chat = synchronous; Messaging = asynchronous and multi-channel.
• Both route through Omni-Channel and surface in the Service Console.
• Chat Transcript vs Messaging Session; Chat Button vs Messaging Channel; Chat Agent Configuration controls agent behavior.
• Experience Cloud templates: Help Center (public knowledge), Customer Service (full self-service), Customer Account Portal (login-based account management), Partner Central (partners).
• Case deflection relies on Knowledge, Data Categories, Topics, and the Case Deflection component.
• Licenses: Customer Community (Sharing Sets, no roles) vs Customer Community Plus (roles, sharing rules, reports) vs Partner Community; member-based vs login-based.
• External OWDs are separate and can only be as open or more restrictive than internal.
• Guest users rely on the Guest User profile and guest sharing rules; publish and activate the site before testing.

Understanding these building blocks and the decision logic behind them will let you confidently answer any Chat, Messaging, or Experience Cloud Self-Service scenario the Advanced Administrator exam presents.