Explanation:

When No More Homelessness (NMH) launched their public Experience Cloud site, they enabled unauthenticated (guest) user access so anyone on the internet could view knowledge articles without logging in. However, the Support team discovered that some articles are missing from search results for guest users — even though they appear for authenticated users. This is a common issue in public Knowledge bases, and the root cause is article-level visibility settings, not profiles, permission sets, or organization-wide defaults (OWDs). Salesforce Knowledge uses a dual-layer access model:
Org-level enablement (Knowledge must be turned on and public access enabled in the site).
Article-level sharing via the "Visible in Public Knowledge Base" checkbox.
For an article to appear in guest user search, topic pages, or recommendations, this checkbox must be selected on the individual article record (or via Data Categories with public visibility). Without it, the article is treated as internal-only, regardless of OWDs or profiles. This setting is the only direct, Salesforce-supported method to expose specific articles to unauthenticated users. NMH should audit all articles, bulk-edit via Data Loader or List Views, and ensure this field is checked for any article intended for public consumption. This approach gives granular control — perfect for organizations that publish both public and internal/support-only content.

Why Option B is Incorrect: "Create a custom permission set for Public access."
Permission sets control user capabilities (e.g., "Edit Articles," "Manage Topics"), but they do not govern record-level visibility for guest users. Even if a permission set grants "Knowledge User" access, guest users do not use permission sets — they operate under the site’s guest user profile, which has extremely limited, hardcoded permissions. Moreover, record sharing for guest users cannot be extended via permission sets. This option misunderstands how Salesforce isolates guest access for security. Permission sets are powerful for authenticated external users (e.g., partners, customers), but irrelevant and ineffective for public Knowledge visibility.

Why Option C is Incorrect: "Select 'Public' organization-wide default for the article type at the org level."
This option is technically impossible — Knowledge article types do not have organization-wide defaults (OWDs). OWDs apply to standard and custom objects like Account, Case, or custom objects — but not Knowledge articles. Article sharing is controlled exclusively through:

"Visible in Public Knowledge Base" checkbox
Data Category visibility
Channel settings (e.g., Public, Partner, Customer)

Setting OWD to "Public" has no effect on Knowledge. Attempting this would result in confusion, as admins would search in vain for an OWD setting that doesn’t exist. This is a frequent exam trap based on misunderstanding Knowledge’s unique sharing model.

Why Option D is Incorrect: "Create a custom profile for Public access."
While the guest user profile is indeed critical (and auto-generated when public access is enabled on the site), you cannot create or modify a custom profile for guest users. The guest profile is system-managed, read-only, and restricted to minimal permissions (e.g., Read on Knowledge object, CRED on public custom settings). You cannot assign custom profiles to guest users or use them to control article visibility. Profiles define object and field access, but record-level sharing for guest users is governed solely by the "Visible in Public Knowledge Base" setting. Creating a custom profile would be a futile exercise with zero impact on the reported issue.

Step-by-Step Fix for NMH
Enable Public Access in Experience Cloud Site → Site Settings > Public Access > Allow guest users to view Knowledge articles
Go to Knowledge Articles → Open articles not showing in search
Edit Article → Check "Visible in Public Knowledge Base" → Save
Bulk Update (Optional) → Use List View + Inline Editing or Data Loader to update multiple articles
Verify Data Categories (if used) → Ensure categories are marked Visible in Public Knowledge Base Republish Articles (if draft)
Test as Guest User → Use Preview as Guest or incognito browser

References:
Salesforce Help: Make Articles Visible to Guest Users
→ States: "To make an article visible to guest users, select Visible in Public Knowledge Base on the article."
Knowledge Base Setup for Public Sites → Confirms no OWD, no profiles/permission sets for guest article sharing.
Trailhead: Set Up Knowledge for Experience Cloud → Walks through enabling public access and article-level checkbox.
Experience Cloud Guest User Security → Explains guest profile is system-managed and cannot be customized for sharing.

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:

For external users, such as partner users in a Partner Digital Experience (formerly Partner Community), to participate in a Salesforce Approval Process, they must have the following two components:
A Digital Experience (Partner Community): This provides them with a secure external interface and access to the necessary records (installation projects/deals). This is explicitly mentioned in all the correct options (A and C).
Assignment as an Approver: External users can be designated approvers in an Approval Process in one of two standard ways:
Assign External Users as Approvers (Option A):
This is the direct and most common way. An Approval Step can be configured to assign the approval request to a specific User (the external partner user). This typically relies on a User lookup field on the record (e.g., a custom Partner Approver lookup field on the Project/Deal object) or by explicitly selecting the user in the approval step.
Add External Users to Approval Queues (Option C):
Approval steps can be assigned to a Queue. External users (partner users) can be members of a Queue, and any member of that Queue can then approve or reject the request. This is a common way to distribute approval workload among a group of partners.

❌ Incorrect Answers
B. Assign external users as the co-owners on records and create a digital experience for those users.
Reason: Record ownership or co-ownership primarily controls data visibility and edit access, not the approval flow itself. While it may grant them access to the record, it does not automatically make them an approver in a standard Salesforce Approval Process. The approval must be explicitly assigned via a User field or a Queue.

D. Assign external users Super User access on records and create a digital experience for those users.
Reason: Super User Access is a specific feature in Salesforce Experience Cloud (specifically for Partner/Customer Community users) that grants a user elevated privileges to view and manage data for their entire account or partner group. While they must have a Digital Experience, "Super User" status does not, by itself, grant them an approval assignment in a standard Approval Process. The approval assignment still needs to be made through the Approval Step configuration (User or Queue).

References
Salesforce Help - Set Up Approvals for External Users in Your Experience Cloud Site: Confirms that external users must be part of an Experience Cloud site and can be assigned as approvers in a standard approval process.
Salesforce Help - Identify Assigned Approvers for an Approval Step in a Classic Approval Process: Lists User (individual external user) and Queue (which can contain external users) as valid options for assigned approvers in an approval step.
Salesforce Help - Considerations for Creating Partner Users (Experience Cloud): Confirms that partner users are a type of external user that uses a digital experience and requires specific licensing and permissions to access records and functionality like approvals.

Explanation:

This question tests your knowledge of integrating Salesforce's live agent chat (Embedded Service) into an Experience Cloud site using the standard, declarative tools.

Why A is Correct:
The Embedded Service component is a standard, out-of-the-box component provided by Salesforce specifically for this purpose. An administrator can simply drag and drop this component onto any page in the Experience Builder. This is the recommended, no-code method for embedding a chat window directly into an Experience site, making it the fastest and most straightforward approach.
Why B is Incorrect:
While it is technically possible to create a custom component using the Embedded Service Deployment API, this is a programmatic and complex solution. The question asks what an administrator should do, implying a declarative approach. Using the standard component (Option A) is always the preferred and simpler method when it meets the requirement.
Why C is Incorrect:
The "Embedded Service connector" is not a standard term for a component or tool used to place the chat window on a page. This is a distractor. Configuration of the underlying Embedded Service (like setting up the deployment, pre-chat forms, and routing) is a prerequisite, but it is not the final step of embedding the visual chat window onto the site itself.
Why D is Incorrect:
A Quick Action is a feature used within the Salesforce Lightning Experience (the internal org), typically on a record page, to perform a specific task like logging a call. It is not used to embed a public-facing chat window into an Experience Cloud site for customer use.

Key Concepts & References:
Exam Topic: Integrating Services and Components into an Experience.
Core Concept: Knowing the standard, declarative tools available in Experience Builder is key. The Embedded Service component is the primary tool for this task.
Salesforce Help: You can search for "Add Embedded Messaging to Your Experience Site" in the Salesforce documentation, which will guide you through using the component in Experience Builder.

Explanation:

Salesforce PRM is a set of features on the Experience Cloud platform designed to manage business relationships with a channel of partners.

✅ A. Automating partner onboarding process:
This is a primary benefit of PRM. The "lifecycle management" mentioned directly refers to the partner journey from recruitment and application to training, approval, and activation. PRM automates this with tools like automated welcome emails, task assignments, and required training checklists before granting access.

✅ C. Providing reports and dashboards access to partners:
Transparency is a key tenet of PRM. By providing partners with dedicated reports and dashboards on their performance (e.g., leads converted, opportunities influenced, marketing fund usage), DF can align incentives and help partners focus on the most productive activities.

✅ D. Preventing channel conflict:
This is solved through deal registration. This process allows a partner to formally claim credit for an opportunity they are working on. Once registered, the deal is protected for that partner, preventing other partners or the internal sales team from pursuing the same customer and causing conflict. This builds trust in the partner ecosystem.

❌ B. Helping partners manage their payments and file taxes:
Salesforce is a CRM (Customer Relationship Management) platform, not an ERP (Enterprise Resource Planning) or accounting system. While PRM can track metrics used for calculating commissions or funds (e.g., influenced revenue), it does not handle the actual processing of payments, payroll, or tax calculations and filings. These functions require integration with a dedicated financial system.

Reference:
The core capabilities of Salesforce PRM are outlined in the "Partner Management" Trailhead modules and Salesforce Help documentation, focusing on onboarding, enablement, performance management, and conflict resolution—not financial operations.