Experience Cloud Consultant Interview Questions

Experience Cloud supports three primary license types: (1) Customer Community — designed for B2C customer self-service. Users can access cases, Knowledge articles, and limited object records. Low cost; suitable for high-volume, limited-access portals. (2) Partner Community — designed for B2B channel partners. Provides access to Opportunities, Leads, Campaigns, and more. Supports PRM features like deal registration and market development funds (MDF). Higher cost than Customer Community. (3) Employee Community / Employee Apps and Portals — for internal employees accessing the portal. Uses Employee Community license; users have full standard object access comparable to internal users but via the Experience Cloud site interface. License choice dictates object access, page layouts, and cost per login or named user.

Experience Cloud template types: (1) LWR (Lightning Web Runtime) — modern, fast, SEO-optimized framework using server-side rendering. Ideal for marketing-facing portals and high-performance sites where page speed and search indexing matter. (2) Aura — feature-rich framework with full Salesforce component library access. Suitable for complex internal portals or communities requiring extensive Salesforce functionality. (3) Customer Service (Aura) — pre-built for self-service with case creation, Knowledge search, and Q&A. (4) Partner Central (Aura) — PRM-focused with deal registration, lead distribution, and MDF modules. (5) Microsites (LWR) — lightweight landing pages for campaigns. (6) Help Center (LWR) — Knowledge article delivery with built-in search. LWR templates offer better SEO and performance but have a smaller out-of-the-box component library than Aura.

Experience Builder is the drag-and-drop visual editor for building Experience Cloud sites. Key features: (1) Drag-and-Drop Components — drag standard and custom components (LWC or Aura) onto the page canvas. (2) Component Properties Panel — configure each component's properties (data source, labels, visibility) in the right sidebar. (3) Theme Panel — control site-wide branding: colors, fonts, button styles, and custom CSS. (4) Page Hierarchy — manage all pages (Home, Case List, Article Detail, custom pages) in the Pages menu; set default pages and configure object-specific pages. (5) Head Markup — inject custom HTML, meta tags, analytics scripts, or CSS into the site's head section. (6) Preview Mode — preview the site as different user types (guest, authenticated, member). (7) Publish — deploy changes to the live site.

Audiences define groups of site visitors based on rules such as user attributes (profile, role, language), geographic location, or record data (e.g., Account type = Partner). Audiences enable personalization without requiring separate pages. Page Variations are alternative versions of the same page, each assigned to a specific Audience. When a member visits the page, Experience Cloud evaluates the audience rules and serves the matching page variation. Use cases: (1) Show a premium support page to Enterprise customers vs. a standard support page to SMB customers. (2) Display regional content in the appropriate language based on geography. (3) Show partner-specific call-to-action modules to Partner Community members. Default variations serve visitors who do not match any defined audience.

Reputation Management gamifies community participation to encourage engagement. Configuration: (1) Reputation Points — assign point values to community actions: posting a question (5 pts), posting an answer (5 pts), receiving a best answer mark (20 pts), liking a post (1 pt), etc. Point values are fully configurable. (2) Reputation Levels — define named levels (e.g., "Newcomer," "Expert," "Legend") each with a minimum point threshold. As members accumulate points, they advance levels. (3) Reputation Leaderboard — a community component displaying the top point earners, driving competition and visibility. Reputation levels appear on member profiles and in community posts, helping other members identify trusted contributors. Admins configure levels and point actions in the community's Reputation Settings.

Salesforce CMS is a hybrid content management system for creating and managing structured content (news articles, banners, documents, custom content types). Integration with Experience Cloud: (1) CMS Workspace — authors create and manage content in a workspace; content is organized by type and tagged for findability. (2) Channels — CMS workspaces are connected to Experience Cloud sites (channels) to make content available on the site. (3) Content Collections — group related content items for use in CMS Collection components on Experience Cloud pages. (4) Translation — content can be translated per locale and served based on the visitor's language. (5) Content is decoupled from the site, enabling the same content to be published across multiple channels (sites, mobile apps) simultaneously from a single source.

Experience Cloud search has two modes: (1) Global Search — searches Salesforce records and Knowledge articles that the user has access to (respecting sharing and data category visibility). Results display in the Search Results page, which can be customized in Experience Builder. (2) Federated Search — extends search to external systems (external databases, SharePoint, etc.) using a configured search provider (via Salesforce Connect or custom Apex). Results from external systems appear alongside Salesforce results. Additional capabilities: Promoted Searches boost specific articles or records to the top of results for defined search terms. Spell Correction handles minor typos. Search Indexing Delay: newly created records may take up to 15 minutes to appear in community search results due to indexing latency.

Experience Cloud supports multiple SSO options: (1) SAML 2.0 — enterprise SSO where an external Identity Provider (IdP such as Okta, Azure AD) authenticates the user and passes a SAML assertion to Salesforce. Configuration requires: IdP metadata (Entity ID, SSO URL, certificate) in Salesforce, and Salesforce SP metadata exported to the IdP. (2) Social Sign-On — authenticate via Facebook, Google, or Microsoft using OAuth 2.0. Configured via Auth Provider records in Setup; each provider requires a Client ID/Secret from the social platform's developer console. (3) Auth Provider + Registration Handler — when a new user authenticates via Social Sign-On for the first time, an Apex Registration Handler class is invoked to create or match a Salesforce user record, assign a profile, and optionally link to an existing Contact/Account.

Experience Cloud uses two key sharing mechanisms for external users: (1) Sharing Sets — grant Read or Edit access to records by matching a field on the record to the external user's profile-associated account or contact (e.g., Account lookup on Case matches the user's Account). Sharing Sets are the primary way to give Customer Community users access to their own records. (2) Share Groups — a public group containing all users of a specific community profile; used with manual or criteria-based sharing rules to expand record access beyond sharing sets. Standard Salesforce sharing rules, role hierarchy (communities have a limited role hierarchy), and Apex Sharing also apply. External users cannot own records in Customer Community licenses; Partner Community users can own records (Opportunities, Leads).

The Guest User Profile controls what unauthenticated (public) visitors can see and do. Security best practices: (1) Apply the Minimum Access Principle — grant only the specific object and field permissions required for public pages. (2) Enable Secure Guest User Record Access (in Digital Experiences Settings) to prevent guest users from accessing records they don't own via URL manipulation. (3) Avoid granting guest users access to sensitive objects (Contacts, Accounts) unless strictly required. (4) Use Guest User Sharing Rules cautiously — sharing records with guest users makes them publicly accessible. (5) Restrict Apex class access — only expose Apex classes that are needed for guest-accessible functionality. (6) Regularly audit the Guest User Profile permissions during org security reviews.

Self-Registration allows external visitors to create their own community accounts. Configuration: (1) Enable Self-Registration in the community's Administration settings. (2) Assign a default Profile that new self-registered users receive. (3) Specify a default Account to associate new users with (required for Customer Community); alternatively, use a custom Apex Registration Handler to assign accounts dynamically. (4) Optionally, build a custom Self-Registration Apex class (implementing the Auth.RegistrationHandler interface) to validate registration data, match existing Contacts/Accounts, or integrate with external identity systems. (5) Configure the Self-Registration page in Experience Builder, adding fields such as name, email, and company. Upon registration, a Community User record and the associated Contact are created (or linked) in Salesforce.

Experience Cloud provides layered moderation capabilities: (1) Member Moderation — community members can flag posts and comments for review; moderators then approve or remove flagged content. (2) Pre-Moderation — all new posts from members are held in a queue pending moderator approval before appearing publicly. Useful for new or untrusted members. (3) Keyword List Management — define lists of blocked or flagged keywords; posts containing blocked words are automatically removed or flagged. (4) Moderation Rules — automated rules that trigger actions (freeze member, block content, flag for review) based on member behavior (e.g., posting a keyword or posting too frequently). (5) Moderators access the Moderation Queue from the community management console to review and action flagged content in bulk.

To make an LWC component available in Experience Builder, configure the component's metadata: (1) In the *.js-meta.xml file, set isExposed to true. (2) Add the appropriate targets — for Experience Cloud, use lightning__CommunityPage (appears on any community page), lightning__CommunityDefaultPage, or lightning__CommunityThemeLayout for theme layout components. (3) Define targetConfigs per target to specify which component properties can be configured in the Builder properties panel. (4) Audience Targeting can be applied to LWC components in Experience Builder — by enabling audience visibility on the component placement, different audiences see different component instances with different configurations.

Delegated External User Administration allows a designated Partner Community user (typically a partner admin) to manage other users within their own account without needing Salesforce system administrator access. With DEAU: (1) The delegated administrator can create, edit, deactivate, and reset passwords for other external users associated with their Account. (2) They can assign profiles from a pre-configured list of permitted external profiles. (3) This eliminates the need for internal admins to manage routine partner user provisioning, scaling partner onboarding efficiently. DEAU is configured in Setup by enabling "External User Management" on a Community user's profile and granting the appropriate delegated admin permissions. It is particularly valuable in large partner ecosystems with hundreds of partner companies.

Super Users are trusted community members granted elevated permissions without full moderator access. Super User capabilities include: (1) Viewing all questions and answers posted within the groups they are Super Users of, even private group content. (2) Moderating content in their designated groups — flagging, editing, and removing posts. (3) Being recognized on the community leaderboard as expert contributors. Super Users are assigned per-group by community managers, making them ideal for subject-matter experts who should have authority within their area of expertise but not site-wide moderation rights. Super User status is different from the Community Moderator role, which grants broader moderation across the entire community. Super Users do not have access to the Community Management console.

Custom domains give Experience Cloud sites a branded URL (e.g., support.company.com) instead of the default Salesforce subdomain. Configuration: (1) In Setup, configure the Custom Domain for the org (My Domain), then add the community path. (2) Create a CNAME DNS record pointing the custom domain to the Salesforce community URL. (3) SSL Certificates — Salesforce can provide a free SSL certificate via Let's Encrypt or you can upload a custom certificate for the domain. (4) After DNS propagation, activate the domain in the Digital Experiences settings. CSP Trusted Sites — Content Security Policy rules must be configured for any external URLs (fonts, scripts, images, analytics) that components on the community pages load; without CSP entries, browsers block these external resources as a security measure.

Experience Cloud provides built-in analytics accessible from the community management console. Key metrics: (1) Unique Visitors — distinct users (logged in and guest) who visited the site over a period. (2) Page Views — total page loads. (3) Logins — number of authenticated user sessions. (4) New Members — self-registered or admin-provisioned users over time. (5) Top Pages — most visited pages. (6) Content Performance — most viewed/liked Knowledge articles. These metrics are surfaced in the built-in community dashboards and can be exported. For deeper analysis, Experience Cloud integrates with CRM Analytics (Tableau CRM) via the Einstein Analytics for Communities app, enabling advanced community health dashboards with member engagement scores and retention cohorts.

Salesforce Identity provides identity and access management features that Experience Cloud builds upon. Key capabilities: (1) Connected Apps — OAuth 2.0-based integrations that control which external apps can access community user data. (2) Identity Verification — multi-factor authentication (MFA) for community users, including time-based OTP and push notifications via the Salesforce Authenticator app. (3) Login Discovery — a custom login page that routes users to the appropriate authentication method based on their identifier. (4) Centralized Identity — Salesforce acts as an Identity Provider (IdP) for other systems, enabling SSO from the community to external applications using SAML or OpenID Connect. (5) Named Credentials — securely store authentication details for callouts from community Apex code to external APIs.

Headless Experience Cloud decouples the front-end presentation layer from Salesforce, using Salesforce purely as a back-end data and identity platform. Developers build the UI with external frameworks (React, Vue, Angular) and use Salesforce APIs to fetch and update data. Key APIs: (1) Connect API (Chatter REST API) — access community feeds, groups, cases, Knowledge. (2) Experience Cloud API (Sites REST API) — create/update community records, manage users, and access community metadata. (3) User Management API — provision and manage external community users programmatically. (4) OAuth 2.0 / OpenID Connect — handle authentication and token management for the headless front-end. Use cases include custom mobile apps, progressive web apps (PWAs), and integrations where the full Experience Builder UI is too constraining.

Partner Central is the Experience Cloud template designed for Partner Relationship Management (PRM). Key PRM features: (1) Deal Registration — partners submit potential deals through the portal; internal teams review and approve, preventing channel conflict. (2) Lead Distribution — internal sales teams distribute leads to partners through the portal for follow-up. (3) Market Development Funds (MDF) — partners request and track co-marketing funds, with approval workflows. (4) Channel Analytics — partner-facing dashboards showing their pipeline, deal registration status, and certification progress. (5) Partner Learning Camp — training and certification tracking. Partner Community license is required for users to access Opportunities and Leads. DEAU allows partner admins to manage their own users within Partner Central.

Experience Cloud provides a branded login page hosted on the community URL. Features: (1) Custom Login Page — customized in Experience Builder with brand colors, logos, and custom components. (2) Forgot Password — sends a reset email to the community user's email address; the password reset link follows the community's URL (not the Salesforce login URL). (3) Login Policies — configured on the community profile: login hours, trusted IP ranges, session settings, and MFA requirements. (4) Custom Login Flows — a Salesforce Flow can be invoked after login to perform additional steps (e.g., prompt for Terms of Service acceptance, complete a profile). (5) Social Login Buttons — Auth Providers configured for the community appear as social login buttons on the login page automatically.

Sharing Sets grant external (community) users access to records based on a field relationship — for example, if a Case's Account field matches the user's Account, the user gets access (Read or Edit) to that Case. Sharing Sets are defined in Community settings and apply automatically without creating individual sharing records. They are scoped to specific profiles and objects. Share Groups are public groups that automatically include all users with a specific community profile. A Share Group can then be used in a standard sharing rule to grant those users access to records — for example, "Share all Cases in Status=Open with the Share Group of all Partner users." Share Groups offer more flexibility since they work with the full sharing rule engine, but they grant access to all matching records rather than just records related to the user's account.

Multilingual Experience Cloud sites serve content in users' preferred languages. Configuration: (1) Enable Translation Workbench in Setup and add supported languages. (2) In Experience Builder, enable the site for multiple languages via Language Settings. (3) Component labels and static text are translated via Translation Workbench or by uploading translation files. (4) CMS Content — each CMS content item can have translated variants per locale; Experience Cloud serves the appropriate variant based on the visitor's language setting. (5) Knowledge Articles — each article can be translated; data category visibility by language controls article access. (6) Language Switcher Component — add this component to the community header to let users switch languages manually. The community automatically defaults to the authenticated user's Salesforce language preference.

LWR (Lightning Web Runtime): Server-side rendering (SSR) for fast initial page loads and SEO indexability. Uses modern JavaScript ES modules without a heavy client-side framework. Limited to LWC components; Aura components are not supported. Component library is smaller but growing. Supports static site generation for pure marketing pages. Best for customer-facing, SEO-critical, high-performance sites. Aura: Client-side rendering with a richer component library including legacy components. Supports both Aura and LWC components. Heavier initial payload but more feature-complete out of the box. Supports all Salesforce data UI components (record pages, related lists) natively. Best for feature-dense internal portals or communities requiring full Salesforce functionality. Salesforce's long-term direction is LWR; Aura sites remain supported but new template development focuses on LWR.

Experience Cloud site metadata can be deployed using Salesforce CLI (sf) or Change Sets. Key metadata types: (1) Network — the site's core configuration (name, URL path, status). (2) CustomSite — site settings and guest user configuration. (3) ExperienceBundle — the full Experience Builder layout, pages, components, and theme settings (deployed as a bundle via sf project deploy). (4) Profile — the associated community member profiles and guest profile. (5) SiteDotCom — legacy site metadata. Best practices: deploy ExperienceBundle using the Salesforce CLI for reliable transfer of Builder customizations; use Change Sets only for simple metadata. After deployment, the site must be published in the target org via the Experience Builder Publish button — deployment alone does not activate/publish the site.