Experience-Cloud-Consultant Practice Test Questions (2026)

Explanation:

The Record Detail standard component in Experience Builder is designed to display details for the recordId that the page context provides (e.g., when the page is an object detail page). You can’t just drop multiple Record Detail components on a single generic page and expect each to independently show Account, Case, and Opportunity data for the logged-in user.
The component automatically binds to the current page’s recordId, not to arbitrary records or multiple objects simultaneously. That’s why all three components attempt to render the same record context, resulting in incorrect or blank data.

Why the others are incorrect:

B. "…so this component will only work on the Home page template" — ❌
It works on record detail page templates, not specifically “Home” pages.
C. The Record Detail component is a custom component and was not configured correctly — ❌
It’s a standard Experience Builder component, not custom code.
D. The Record Detail component will only show record details for the Case object — ❌
The component can display any supported object—Account, Case, Opportunity, etc.—as long as the recordId context matches.

Key takeaway:
To display multiple object records on a single page, you’d need custom Lightning components or custom queries (Apex/LWC) to retrieve and display each record, because the standard Record Detail component is context-dependent and supports only one recordId at a time.

Explanation

🟩 A. Enable “Allow External Lead Sharing” in Digital Experience settings
This setting is critical to allow partner users (external users) to access and claim shared leads.
Without enabling this, leads cannot be shared with external users via Experience Cloud sites.
Reference: Salesforce Help - Lead Sharing with Partners

🟩 D. Create Assignment Rules for Lead Distribution
Assignment rules automate how leads are routed to queues or users based on criteria like partner tier, region, or product interest.
These rules are essential for scalable lead distribution and can be configured to push leads into a Lead Inbox for partners.
Reference: Salesforce Help - Create Assignment Rules for Lead Distribution

❌ Why B and C are incorrect:
❌ B. Create Page Layouts for Lead Distribution
Page layouts control UI visibility but are not part of the lead sharing or distribution logic.
They’re useful for customizing how leads appear to users, but not for enabling sharing or routing.
❌ C. Configure Lead Creation and Lead Distribution inside PRM Workspace
The PRM Workspace is used for branding, navigation, and content setup — not for lead distribution logic.
Lead creation and distribution are configured via standard Salesforce setup, not inside the PRM Workspace.

Explanation:

The Solar Panels object has too many fields, many of which contain sensitive or irrelevant data for customers. Simply showing all fields in the customer portal could expose technical details that should not be visible. Salesforce provides a secure way to restrict access so customers only see relevant information.

✅ Correct Option (C):
Field-Level Security (FLS) ensures that only selected fields are visible to users. By configuring FLS, the administrator can hide technical and internal fields from customers while keeping them accessible to internal staff. This is the secure and recommended method to protect sensitive data.

❌ Incorrect Option (A):
CSS overrides only hide fields on the front end. The hidden fields still exist in the page’s source code or can be accessed through APIs, making this insecure. Salesforce best practices advise against this method for security reasons.

❌ Incorrect Option (B):
Page variations control layouts and personalization based on audience but do not restrict access to fields. Even if hidden in one variation, fields remain accessible if not restricted through FLS.

❌ Incorrect Option (D):
Developer Console and coding approaches are unnecessarily complex. They may visually hide fields but do not truly prevent access. Security must be enforced through configuration, not code, when possible.

Reference:
Salesforce Help: Set Field-Level Security for a Field on All Profiles

Explanation:

To make Knowledge articles available on an Experience Cloud site automatically without manual intervention, DreamHouse Realty needs to ensure the articles are accessible to site users and organized in a way that aligns with the site’s navigation. Let’s break down why B and C are correct:

B. Map topics to data categories: In Salesforce Experience Cloud, topics are used to organize and display content, like Knowledge articles, on the site. Data categories group Knowledge articles in Salesforce, and mapping topics to data categories ensures that articles assigned to specific data categories automatically appear under the corresponding topics on the site. For example, if DR has a data category called “Home Buying Tips” and maps it to a topic called “Tips for Buyers,” new articles added to that data category will automatically show up under the “Tips for Buyers” topic on the site. This setup is automatic and requires no manual work for new articles.

C. Enable "Share on Sites" setting: The “Share on Sites” setting (also referred to as enabling Knowledge articles for external access) allows Knowledge articles to be visible to Experience Cloud site users, such as guest or external users. Without this setting, articles won’t be accessible on the site, even if they’re mapped to topics. Enabling this setting ensures that new articles are automatically available to site users as long as they meet other access criteria (like data category visibility).

Why not A and D?

A. Map articles to Content Topics: This is incorrect because you don’t directly map individual articles to topics in Salesforce. Instead, topics are mapped to data categories (as in option B), and articles are assigned to data categories. The mapping happens at the data category level, not the individual article level, to enable automatic organization.

D. Enable "Automate Topic Assignment” setting: There is no specific “Automate Topic Assignment” setting in Salesforce for Knowledge articles in Experience Cloud. While topics can be assigned to articles, this is typically done manually or through data category mappings, not via a specific automation setting for topics in this context.

Reference:
Salesforce Help: Make Knowledge Available in Your Experience Cloud Site
Trailhead: Set Up Salesforce Knowledge

Explanation:

To allow customers to log in to an Experience Cloud site using their Google credentials and access their basic Google profile data, Salesforce provides a standard feature called an Authentication Provider. Let’s see why C is the correct choice:

C. Create an Authentication Provider by choosing Google as the provider type and add relevant parameters to access the customers' basic profile data:
Salesforce supports single sign-on (SSO) through Authentication Providers, which allow users to log in using external identity providers like Google. By setting up a Google Authentication Provider, CK can enable customers to log in with their Google credentials. The consultant can configure the Authentication Provider to request access to basic profile data (like name or email) by specifying the appropriate scopes (e.g., profile or email) in the provider setup. This is a standard, secure, and efficient way to integrate Google login and retrieve profile data without custom coding.

Why not A, B, and D?

A. Set up a login flow for communities:
Login flows in Salesforce are used to add custom logic after a user logs in (e.g., redirecting them or collecting additional data). They don’t handle the authentication process itself or integrate with external identity providers like Google. This option doesn’t address the Google login requirement.

B. Create a custom self-registration page and a custom login page by using Visualforce and Apex controllers:
While Visualforce and Apex can be used for custom login pages, building a custom solution for Google authentication is unnecessary and complex. Salesforce’s Authentication Provider feature already supports Google SSO natively, making this option inefficient.

D. Create a custom login page using Lightning components and use the Google REST API:
This approach requires custom development to integrate with Google’s REST API, which is more complex and error-prone than using Salesforce’s built-in Authentication Provider. It’s not the recommended approach for standard Google SSO integration.

Reference:
Salesforce Help: Set Up an Authentication Provider
Trailhead: Identity Basics for Experience Cloud

Explanation:

This question tests your knowledge of a specific, powerful feature in Experience Cloud that allows for dynamic branding based on user context.

Why D is Correct:
Branding Sets are the exact functionality designed for this scenario. They allow you to define multiple visual themes (including logos, colors, and fonts) and then apply them automatically based on criteria such as:
The user's profile or permission set.
The user's record data (e.g., a "Platinum" field on the Contact or Account). This means you can have a default look for regular customers and a special "Platinum" look that only appears when a user meeting that specific criteria logs in.

Why A is Incorrect:
A Theme is a single, site-wide set of styling rules (colors, fonts, logos). While you can create a separate theme for the Platinum design, a standard Theme cannot dynamically switch based on who is logged in. You would be forced to create two separate sites with two separate themes, which is inefficient and difficult to manage.

Why B is Incorrect:
A Template is the foundational structure and set of components used when you first create a site. It determines the initial page layouts and built-in functionality (e.g., a Customer Service template vs. a Partner Central template). You cannot dynamically switch the entire site template based on a user's login.
Why C is Incorrect:
CMS Connect is a feature that allows you to pull content from an external content management system (like WordPress or Drupal) into your Experience Cloud site. It is used for managing articles, blog posts, or other dynamic content, not for dynamically switching the core visual branding (logo, colors) of the site interface itself based on user type.

Key Concepts & References:
Exam Topic: Branding and Theming an Experience.

Core Concept:
Understanding the difference between a static Theme (one look for all) and dynamic Branding Sets (multiple looks for different audiences) is critical. Branding Sets are the key to personalized user experiences based on profile or data.
Salesforce Help: "Brand Your Site for Different Audiences with Branding Sets". The official documentation walks through creating different branding sets and assigning them to audiences.

Explanation:

The key requirements are:
1. A site for customers (not partners).
2. Access to knowledge articles (manuals, FAQs).
3. Secure, logged-in access to customer-specific data (Contracts object).
4. The ability for customers to update their information (billing info).

Let's evaluate the options:

A. Customer Service: This template is optimized for customer service and support cases. While it includes Knowledge and Case management, its primary focus is not on account-specific data like contracts and billing.

B. Customer Account Portal: This template is specifically designed for this use case. It provides logged-in customers with a personalized experience to view their account data, contracts, and assets, and to update their personal and billing information. It also includes access to Knowledge for self-service.

C. Partner Central: This template is designed for partner relationship management (PRM), including deal registration, lead management, and MDF requests. It is not intended for a company's end-customers.

D. Help Center: This is a public-facing template primarily for unauthenticated Knowledge access. It does not support the requirement for logged-in users to access their specific contract and billing data.

Reference: The "Templates" module in the Experience Cloud Consultant exam guide differentiates the use cases for each standard template. The Customer Account Portal is explicitly noted for scenarios involving customer account management and personalized data access.

Explanation:

Salesforce PRM (Partner Relationship Management) is built on the Experience Cloud platform and is designed to automate and streamline business processes with a network of partners.

A. Automating partner onboarding process: This is a core function of PRM. The lifecycle management mentioned in the question includes onboarding. PRM can automate the process from application to approval, training, and activation, reducing manual effort.

C. Providing reports and dashboards access to partners: This is a key feature of PRM. It allows partners to see their own performance metrics, lead status, pipeline, and marketing performance through tailored reports and dashboards within their partner portal, fostering transparency and alignment.

D. Preventing channel conflict: PRM helps prevent channel conflict through features like lead registration and deal registration. These processes ensure that partners get credit for the leads and opportunities they generate, preventing conflicts between different partners or between direct and indirect sales channels.

B. Helping partners manage their payments and file taxes: This is not a standard function of Salesforce PRM. While PRM might track influenced revenue or MDF funds for reporting, it is not an accounting, payment processing, or tax filing system. These functions are handled by dedicated financial systems.

Reference: The "Partner Relationship Management (PRM)" section of the Salesforce Help documentation and the PRM Trailhead modules cover these core capabilities, including partner onboarding, deal registration, and partner performance analytics.

Explanation:

A. Select the appropriate topics on the Knowledge tab within Lightning Experience
Salesforce allows administrators and content managers to associate Knowledge articles with topics directly from the Knowledge tab in Lightning Experience. This helps organize content and improves search relevance in Experience Cloud sites.

D. Manually add one or more topics to each article within Workspaces
Within Experience Workspaces, you can manually assign topics to individual articles. This ensures that articles appear under the correct topic pages and are discoverable through topic-based navigation.

Incorrect Option: B.
Allow guest users to tag displayed articles with relevant topics on a public page
Salesforce does not allow guest users to tag articles with topics. Topic assignment is a moderated and admin-controlled process.

Incorrect Option: C.
Establish automatic topic assignment of topics to specified data categories within WorkSpaces
Salesforce does not support automatic topic assignment based on data categories. Topics and data categories are distinct classification systems and must be managed separately.

References:
Salesforce Help: Organize Articles with Topics
Salesforce Help: Experience Workspaces Overview
Salesforce Help: Data Categories vs Topics

Explanation:

This question tests the understanding of hierarchical and inherited permissions within the Data Category security model.

Here’s a detailed breakdown of each correct statement:

A. Child roles cannot see more data categories than their parent role. If the parent role’s visibility changes, the child role’s category visibility is reset to its parent's category visibility.
This statement accurately describes the hierarchical nature of data category assignments for internal Salesforce roles. Data category visibility is inherited down the role hierarchy. A subordinate (child role) can only see a subset of the data categories visible to their manager (parent role). If the parent's visibility is updated, all child roles are automatically reset to inherit from the new parent visibility, ensuring the hierarchy is never broken.

B. Customer Portal users and partner portal users inherit data category visibility settings of the role assigned to their account (owner) managers by default.
This statement is true for the standard sharing model used in Partner Communities. Partner users can be associated with an Account and a Contact. The data category visibility for these users can be controlled by the role of the Account Owner. This is a key mechanism for managing external user access at a group level based on the internal user who owns the partner relationship.

Why the other options are incorrect:

C. When a category is made visible to a user through custom settings or is made visible by default, its child and parent categories are not included.
This statement is false. Data categories are organized in a hierarchy. When you grant access to a parent category, access is automatically granted to all of its child categories. The visibility is inclusive of the entire branch of the hierarchy below the granted category.

D. Translated articles will not follow the master article data category. Therefore, translated articles can be assigned to a different data category.
This statement is false. A translated article is a version of the master article, not a separate record. It inherits the data category assignments from the master article. You cannot assign a translated article to a different data category than its master. The security and categorization are controlled at the master article level.

Reference
Salesforce Help: "Assign Data Categories to Roles" - Explains the hierarchical inheritance of data category visibility.
Salesforce Help: "How Partner Users Get Data Category Access" - Details how partner users can inherit access from their account owner's role.
Salesforce Help: "About Data Categories" - Confirms that access to a parent category includes access to all its children.
Salesforce Help: "Translate Knowledge Articles" - Clarifies that translations are part of the same article record and share its properties, including data categories.