Explanation:

To help users easily search and browse content on an Experience Cloud site, Cloud Kicks should use a combination of topics and visual organization tools. These features improve discoverability, structure, and relevance of content across the site.

🟩 A. Navigational Topics
Navigational Topics are used to organize content into browsable categories. They appear in the site’s navigation menu and help users explore articles, discussions, or posts grouped by subject. Admins can assign content to these topics manually or automatically.
Example: “Returns & Exchanges,” “Product Setup,” or “Warranty Info” as top-level categories.

🟩 B. Content Topics
Content Topics are tags applied to articles, posts, or discussions. They help improve search relevance and allow users to filter or locate content based on specific keywords. Unlike navigational topics, content topics are more granular and flexible.
Example: A knowledge article tagged with “solar panel maintenance” or “installation tips.”

🟩 D. Featured Topic
Featured Topics allow admins to highlight specific topics on the homepage or landing pages. This draws attention to trending or important content and helps guide users toward high-value information.
Example: Promoting “Holiday Shipping Guidelines” during peak season.

❌ Why the Other Options Are Incorrect
C. Content Graph
This is not a standard Experience Cloud feature. It may refer to backend data relationships or be a distractor.
E. Navigation Tree
Salesforce does not use the term “Navigation Tree” as a feature. Navigation is handled through menu components and navigational topics, not a tree structure.

Explanation:

Data Category Visibility is the most effective way to control which Knowledge articles users can access in Salesforce. It allows administrators to assign visibility rules based on roles, profiles, or permission sets, ensuring that users only see articles relevant to their function or group. For example, support agents working in the “Solar Panels” division can be restricted to articles tagged with that category, while agents in “Battery Storage” see a different set. This keeps content targeted and secure.
The visibility settings are dynamic — if a user’s role or profile changes, their access updates automatically. This is especially useful in Experience Cloud, where external users like partners or customers need tailored access. Data Category Visibility also supports hierarchical structures, so you can nest categories and manage access at multiple levels. For Ursa Major Solar, this means they can confidently segment content for different user groups across portals without needing complex sharing rules or Apex logic. It’s scalable, declarative, and built for multi-audience Knowledge delivery.

❌ Incorrect Option: B. Content Management
Content Management in Salesforce is all about organizing and publishing content — not controlling who sees it. It helps teams create articles, manage versions, translate content, and push updates to Experience Cloud sites. However, it does not restrict visibility based on user roles or permissions. You can use it to structure and deliver content, but not to restrict who sees what.
For example, you might use Content Management to publish an article about solar panel maintenance, but without Data Category Visibility or sharing rules, that article could be visible to all users with access to Knowledge. This makes Content Management a publishing tool, not a security or access control feature. If Ursa Major Solar relied solely on Content Management, they’d be missing the ability to tailor article visibility for different user groups. So while it’s critical for content lifecycle management, it doesn’t solve the problem of restricting article access based on user attributes.

❌ Incorrect Option: C. Automatic Topic Assignment Automatic Topic Assignment is a helpful feature that tags articles with relevant topics based on their content. This improves search relevance and helps users discover articles more easily. For instance, an article about “solar panel installation” might automatically be tagged with “Installation” or “Solar Panels,” making it easier to find through search or topic filters.
However, this feature does not restrict access to articles. It’s purely about enhancing discoverability, not managing visibility. Whether a user can view an article still depends on Data Category Visibility or sharing rules. Automatic Topic Assignment is useful for organizing content and improving the user experience, but it doesn’t offer any security or permission-based filtering. It’s a useful tool, but not the right answer when the goal is to restrict article access.

❌ Incorrect Option: D. Org-Wide Defaults
Org-Wide Defaults (OWDs) are a foundational part of Salesforce’s record-level security model. They define the baseline level of access users have to records they don’t own, such as Accounts, Opportunities, or Cases. For example, setting the OWD for Accounts to “Private” means users can only see records they own unless sharing rules grant additional access.
However, Knowledge articles don’t follow the same ownership model. Their visibility is managed through Data Categories, channel settings, and publication status, not OWDs. You can’t use OWDs to say “Only support agents can see these articles.” That’s not how Knowledge works. So while OWDs are essential for securing standard and custom objects, they’re not relevant for controlling Knowledge article visibility — making this option incorrect.

📘 References
Salesforce Help: Control Access to Knowledge Articles Using Data Categories
Salesforce Help: Data Categories Best Practices
Salesforce Help: Topics for Knowledge Articles
Salesforce Help: Org-Wide Defaults Overview
Salesforce Help: Content Management in Experience Cloud

Explanation:

Northern Trail Outfitters has 1,000 articles in an external system, many over two years old and likely outdated or low-value. The goal is a public Knowledge base that’s fast, relevant, and easy to maintain. The consultant should recommend bulk-importing only the top-performing articles—those with high views, positive ratings, or current relevance—into Salesforce Knowledge using the Knowledge Article Import tool or Data Loader. After import, each article must be published and the "Visible in Public Knowledge Base" checkbox selected to make it available to unauthenticated guests. This approach keeps the site lean, improves search performance, and avoids overwhelming users with stale content. The admin can later add more articles as needed, but starting with proven winners ensures immediate value and a clean user experience.

Why Option A Is Incorrect
Manually adding top articles and selecting Authenticated Sites as the channel restricts access to logged-in users only. The requirement is public access, so guests must see the articles without any login. This option defeats the purpose.

Why Option B Is Incorrect
Bulk-importing all 1,000 articles and then archiving duplicates and outdated ones is a bad strategy. It bloats the Knowledge base, slows down search indexing, and creates a messy user experience. Cleaning up afterward is time-consuming and risks deleting good content by mistake. Start small and scale smart.

Why Option C Is Incorrect
Manually adding top articles one by one is impractical. Even with 50 or 100 high-value articles, manual entry takes hours or days, increases errors, and delays launch. Bulk import with a CSV file and field mapping is faster, more accurate, and supports versioning and metadata.

References:
Salesforce Help – Import Articles into Knowledge
Salesforce Help – Make Articles Public
Trailhead – Set Up a Public Knowledge Base

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:

Customer Community Plus License:
This license is designed for users who need access to cases, knowledge, and reports/dashboards, but not the full features of a partner license. It is suitable for business-to-business (B2B) use cases where the external user is an extension of the internal team or a trusted partner.

Key features include:

Delegated Administration: Agents can manage specific user accounts or groups.
Roles and Sharing: A user role hierarchy allows for more complex sharing settings and visibility control within the portal.
Advanced Features: The ability to access reports and dashboards, which is often a requirement for third-party agents managing performance metrics.
Case Creation: The license provides the ability to create, edit, and view cases, which directly addresses the requirement for third-party agents to create tickets.
Role Hierarchy: The Plus license's support for a role hierarchy allows UMS to set up a role structure for the third-party agents, ensuring that they can only access the cases they are supposed to manage.

Why other options are incorrect:
A. Partner Community:
This license is intended for channel partners (e.g., resellers) who manage opportunities, leads, and quotes. It provides a different set of object access and is not the most cost-effective or appropriate license for agents focused solely on case management.
B. Customer Identity:
The Identity license is a basic license for single sign-on (SSO) and is often included with other licenses. It does not provide access to standard objects like cases, so it is insufficient for the agents' needs.
D. Customer Community:
This is the most basic external user license, primarily intended for business-to-consumer (B2C) use cases. It typically offers read-only access to a limited set of objects and does not support a role hierarchy, making it unsuitable for the more complex needs of a third-party agent.