Explanation:

Zephyrus Relocation Services (ZRS) wants to build a partner portal that includes company information and branding on the Account Management page. The best Experience Cloud templates for this use case are:

1. Partner Central ✅
Purpose-built for Partner Relationship Management (PRM).
Includes components for lead distribution, deal registration, and account management.
Supports sharing CRM data with partners and customizing branding.
Ideal for channel sales and partner collaboration.
2. Build Your Own (LWR or Aura) ✅
Offers maximum flexibility for custom branding and layout.
Allows ZRS to design a fully tailored Account Management page.
Best suited for organizations with specific UI/UX requirements or custom data models.

❌ Incorrect Options
A. Help Center
Designed for customer self-service, FAQs, and case deflection.
Not suitable for partner collaboration or account management.
C. Customer Service
Focused on support interactions and case management.
Lacks built-in PRM features and partner-specific components.

References
Salesforce Help: Which Experience Cloud Template Should I Use?
Salesforce Help: Partner Relationship Management Template Requirements
Salesforce Help: Manage Partner Relationships with Experience Cloud Sites

Explanation:

When you create a public Experience Cloud site, Salesforce automatically performs a number of setup actions to manage guest user access.

A. Creation of a guest role: A role is automatically created for the guest user to facilitate sharing via the role hierarchy. While roles are typically for authenticated users, a guest role is created to ensure data can be shared with the guest user via sharing rules, which is necessary for a public site.
C. Creation of a guest profile: A dedicated guest user profile is automatically created to define the permissions for unauthenticated users accessing the public site. This profile controls which objects, fields, and pages the guest user can see.
E. Creation of a guest user record: A special guest user record is automatically created and assigned to the guest profile. This record acts as the user for anyone who is not logged in, and it's what you use to configure site-wide access and sharing.

Why other options are incorrect
B. Creation of moderation criteria that are applied only to guest users: Moderation criteria are not created automatically. These are custom settings that an administrator must configure manually to manage content on the site.
D. Creation of sharing mechanisms that are available only to guest users: While a guest user's profile and record are created, and sharing rules can be used to grant them access, the specific sharing mechanisms themselves are not automatically created. The admin must set up sharing rules to grant guest users access to specific records.

Explanation:

Why internal Salesforce licenses are the right fit for CK’s employee sites
Because Cloud Kicks’ employees already work in Sales and Service, they are internal users with standard Salesforce user licenses (e.g., Salesforce, Sales Cloud, Service Cloud, Platform). Salesforce explicitly states that internal users primarily access the platform via Lightning/Classic and can also access Experience Cloud sites—you don’t purchase external “community” licenses for them. You simply add their profiles or permission sets as site members so they can authenticate with their normal org credentials and see the social intranet and HR help experiences you build. This approach centralizes identity, preserves existing permission models, and avoids duplicative licensing.

Why option C (Customer Community) is not appropriate
Customer Community (and other Experience Cloud external licenses like Customer Community Plus or Partner Community) are designed for external audiences—customers, partners, or prospects—who do not otherwise have access to your core Salesforce org. They’re licensed and governed differently (login- vs. member-based models, different sharing features), and Salesforce lists them as licenses for external users, not for employees who already have internal access. Assigning such licenses to employees would add cost and complexity without benefit.

Why option A (Salesforce Authenticated Site) is not the right choice
“Authenticated Website/Authenticated Site**” refers to a legacy Sites license family intended for public websites with optional login, not for modern employee access to Experience Cloud. It’s unrelated to granting your internal workforce access to an intranet or HR portal and isn’t how you should license employees on Experience Cloud in 2025.

How to grant employees access in practice (what CK’s admins will do)
In Experience Builder → Administration → Members, add the profiles or permission sets used by Sales and Service staff. After you add a profile or permission set, all users assigned to it become site members automatically. This lets CK target the intranet and HR help experiences (pages, audiences, permissions) to the right employee groups using the same identity and governance model they already use in Salesforce.

Bottom line
Keep CK’s workforce on their existing internal Salesforce user licenses (your org may be on the Unlimited edition, but the key is “internal license,” not an external Experience Cloud license). That gives seamless, compliant access to the social intranet and HR help site—no Customer Community or legacy Authenticated Site licensing needed.

Explanation:

The process for creating an external (partner or community) user is tightly coupled with the Contact record. A user must be associated with a single Contact, and that Contact must be associated with an Account that has been enabled for partner collaboration.

Here is the standard, step-by-step process, with the final step being the one the question asks for:

Prerequisite: Ensure a Contact record exists and is associated with an Account that is enabled as a Partner Account.
Navigate to the Contact: The administrator goes to the specific Contact record for the person who needs partner access.
Final Action: On the Contact detail page, the administrator clicks the "Manage External User" button. From the dropdown that appears, they then select "Enable Partner User". This action opens the new user form, pre-populating the Contact and Account information.
Provide User Details: The administrator then fills in the remaining user details (like username, email, and profile) and saves the record.

The question asks for the step performed right before providing user details and saving. This is precisely the action described in Option D.

Why the Other Options are Incorrect
A. Click "Manage Partner User” on the Contact detail page, then click “Enable Customer User”. This is incorrect for two reasons. First, the button is named "Manage External User," not "Manage Partner User." Second, "Enable Customer User" is used for creating Customer Community users, not Partner users.
B. Click "Manage Partner User” on the Account detail page, then click “Enable Partner User”. This is incorrect because the process is initiated from the Contact record, not the Account record. While the Account must be a partner account, the user creation itself is done per Contact.
C. Click "New" on the User Setup page in Lightning Experience. While it is technically possible to create any user from the User Setup page, this is not the standard or recommended method for creating external users. Doing it this way requires manually linking the correct Contact and selecting the correct external user license, which is error-prone. The prescribed, foolproof method is to start from the Contact record, which ensures all the necessary associations are made automatically.

Reference
Salesforce Help: Create Experience Cloud Users
This documentation outlines the standard process, which is to navigate to the Contact record and use the "Manage External User" button. It emphasizes that this is the primary method for creating users with Customer Community, Partner Community, or External Identity licenses.

Explanation:

Ursa Major Solar (UMS) wants authenticated Experience Cloud site users to see cases, quotes, contracts, and Knowledge articles in search results, but the current Search Results component only returns Knowledge articles. To achieve the desired outcome, UMS needs to configure the search functionality in Experience Cloud to include multiple objects in the results.

Let’s evaluate the options:

A. In Salesforce Setup, under the Experience Site users’ profile, adjust the system permissions to allow for multiple objects in search results:
This is incorrect. While user profile permissions control access to objects (e.g., Read access to Cases, Quotes, Contracts, and Knowledge), there is no specific system permission in Salesforce Setup that directly controls which objects appear in Experience Cloud search results. Search result configuration is managed within the Experience Builder, not via system permissions in Setup.

B. On the Search page, switch the Search Results component with Global Search Results and select the appropriate objects in the property editor:
This is the correct answer. The Search Results component in Experience Cloud is limited to displaying results from a single object (e.g., Knowledge articles, as in UMS’s case). To display results from multiple objects (e.g., Cases, Quotes, Contracts, and Knowledge), UMS must replace the Search Results component with the Global Search Results component on the Search page in Experience Builder. The Global Search Results component allows administrators to select multiple objects (via the property editor) to include in search results, provided the authenticated users have the necessary object permissions.

C. On the Search page, select the appropriate objects in the property editor for the Search Results component:
This is incorrect. The standard Search Results component in Experience Cloud does not support selecting multiple objects in its property editor. It is designed to display results from a single object type (e.g., Knowledge articles). To include multiple objects like Cases, Quotes, Contracts, and Knowledge, the Global Search Results component must be used instead, as described in option B.

D. On the Home page, in the property editor for the Hero component, adjust the Hero Type to "Call to Action” instead of "Search":
This is incorrect. The Hero component on the Home page is used for visual banners or calls to action, not for controlling search functionality or search result objects. Modifying the Hero component’s properties has no impact on the search results displayed on the Search page.

How This Applies to UMS’s Scenario:
UMS’s issue is that the Search Results component on their Search page is configured to show only Knowledge articles. To include Cases, Quotes, Contracts, and Knowledge in the search results, UMS needs to:
Open the Search page in Experience Builder.
Remove the existing Search Results component.
Add the Global Search Results component to the page.
In the property editor for the Global Search Results component, select the desired objects (Cases, Quotes, Contracts, and Knowledge).
Ensure that authenticated users’ profiles or permission sets grant Read access to these objects to make them searchable and visible in results.

This configuration ensures that searches performed by authenticated users return results across the specified objects, aligning with UMS’s requirements.

Reference:
Salesforce Help, “Configure Search in Experience Cloud” (Winter ’26): “Use the Global Search Results component to display search results from multiple objects in Experience Cloud sites. In Experience Builder, add the component to the Search page and select the objects to include in the property editor.” Available at: Salesforce Help - Customize Search in Experience Cloud.

Explanation:

The most appropriate and secure way to grant guest users access to custom object records in Salesforce Experience Cloud is by using Guest User Sharing Rules. These rules are designed specifically for unauthenticated users who access public sites. When the Organization-Wide Defaults (OWD) for an object are set to Private, guest users cannot see any records unless explicitly granted access. This is where Guest User Sharing Rules come into play.
These rules allow administrators to define criteria-based or owner-based sharing that exposes selected records to the Guest User Profile associated with the Experience Cloud site. For example, CK can create a rule that shares all VolunteeringEvent records where the status is “Open” with the guest user. This ensures that only relevant and safe data is exposed publicly.

🔐 Why Guest User Sharing Rules Are Essential
Salesforce has tightened guest user access controls in recent years to improve security. Guest users:

Do not have roles, so role hierarchy sharing doesn’t apply.
Cannot use Sharing Sets, which are reserved for authenticated community users.
Rely on explicit sharing rules to access records when OWD is private.

By using Guest User Sharing Rules, CK can maintain data security while still enabling public visibility for volunteering opportunities. These rules are configured in Setup → Sharing Settings, and must be targeted to the site’s guest user.

❌ Why Other Options Are Incorrect
A. Guest User Roles
Guest users do not have roles in Salesforce. Roles are part of the internal user hierarchy and are used for record-level sharing among authenticated users. Since guest users are not part of the role hierarchy, this option is invalid.
B. Guest User Sharing Sets
Sharing Sets are used to grant access to records based on the user’s profile and related objects. However, they only apply to authenticated community users, not guest users. CK’s site is public, so this mechanism doesn’t apply.
C. Guest User Organization-Wide Defaults (OWD)
OWDs define the baseline access level for all users, including guests. If the OWD for VolunteeringEvent is set to Private, guest users will not see any records unless additional sharing is configured. OWD alone does not grant access — it must be paired with sharing rules.

🔗 References
Salesforce Help: Secure Guest User Record Access
Salesforce Help: Best Practices for Guest User Access
Salesforce Help: Create and Manage Sharing Rules

Explanation:

The Delegated External User Administrator permission is a specific permission that is typically included in a Permission Set or Profile for authenticated external users (like Customer Community Plus or Partner Community users).

When a user is granted this permission, they gain the ability to:
Create and edit other users associated with their account.
Deactivate users associated with their account.
Reset passwords for those users.

This permission is essential for self-service account management where a primary customer contact needs to manage access for other employees or authorized individuals (the "authorized users") to view their organization's data (usage, billing, payment history).

❌ Incorrect Answers
B. View and Manage Users
This is an internal, high-level permission often associated with standard Salesforce administrators. It would grant access to all users in the Salesforce org, including internal users, which is a major security risk and provides excessive access. The more focused external permission is Delegated External User Administrator.
C. Modify All for Usage, Billing, and Payment History
Modify All is a data-level permission that controls the ability to edit or delete records on the specified objects. It has nothing to do with creating, managing, or assigning users.
D. View Content in Portals
This is a very basic permission that allows a user to see content (like articles or documents) within the Experience Site. It does not include any administrative or user management capabilities.

References
Salesforce Help Documentation: The concept of allowing external users to manage other users under their account is explicitly covered by the "Delegated External User Administrator" permission.
Salesforce Trailhead: The permission is covered in modules related to external user management and security in Experience Cloud (formerly Communities).

Explanation:

🚀 Scenario Overview
Universal Containers needs to move an Experience Cloud site from one production org to another — and these orgs are not directly connected. This rules out standard deployment tools like Change Sets, which require a direct connection between source and target orgs. The goal is to package and transfer the site, including its templates, components, and configuration, in a portable format.

🧩 Why “Lightning Bolt Export and Installation” Is Correct
The Lightning Bolt Solution is Salesforce’s recommended method for packaging and distributing Experience Cloud sites across unrelated orgs. It allows admins to:

Export the site as a Bolt Solution, including:
Page templates
Themes
Branding
Custom components
Data models and objects

Install the solution into another org via the AppExchange or manually through Setup.

This method is ideal for cross-org deployment, especially when orgs are not connected via a deployment pipeline.

❌ Why Other Options Are Incorrect

A. Deployment via Metadata API
While powerful, the Metadata API is not ideal for full Experience Cloud site migration. It lacks support for certain site-specific configurations and UI elements like page variations and audience targeting.
B. Publication via Experience Builder
Publishing a site only makes it live within the current org. It does not transfer the site to another org.
C. Deployment via Change Set
Change Sets require a direct connection between source and target orgs (e.g., sandbox to production). They cannot be used between two unrelated production orgs.

References
Salesforce Help: Create and Export a Lightning Bolt Solution
Salesforce Help: Install a Lightning Bolt Solution
Salesforce Developer Guide: Lightning Bolt Solutions Overview

Explanation:

The External Apps License is a very limited, free license designed for a specific purpose: to grant users access to a single, custom-built Lightning application. It provides extremely restricted object permissions.

Key Limitation: By default, the External Apps license only grants access to a few standard objects (like User, Feed, Content, and a couple of others) and NO custom objects. Any access to standard objects like Cases or custom objects like UC's purchase registration object must be explicitly granted by the administrator.
The Problem for UC: One of the core requirements is that customers can "register their recent purchases," and purchases are stored in a custom object. Since the External Apps license does not natively allow access to any custom objects, this requirement would be blocked unless UC undertakes a complex and non-standard configuration to grant access, which is not the intended use of this license.

This limitation makes the External Apps license a poor fit for UC's comprehensive self-service site, which requires access to multiple standard objects (Cases, Knowledge) and at least one custom object.

Why the Other Options are Incorrect
A. External Apps license does NOT allow self-registration. This is not a definitive limitation. Self-registration can be configured for sites using External Apps licenses. The barrier is not the registration process itself, but the object permissions granted to the user once they are created.
C. External Apps license does NOT allow access to cases. This is misleading. While the External Apps license does not grant access to Cases by default, an administrator can manually enable Read, Create, and Edit permissions for the Case object on the profile associated with the External Apps license. This is a standard configuration task. The same is not true for custom objects, which are far more restricted.
D. External Apps license does NOT download documents out-of-the-box. This is incorrect. The External Apps license does include permissions to view Files and Content, which would allow users to download documents like warranties. This functionality is available and would not block UC's requirement.

Reference
Salesforce Help: External Apps License
The official documentation for the External Apps license details its permissions. It explicitly states that it provides "minimal access to standard objects" and that "access to custom objects isn't available." This directly confirms that the requirement to access the purchase (custom) object is the critical failure point for using this license type. A Customer Community or Customer Community Plus license would be the correct, licensed choice for this use case.

Explanation:

Business Context
Universal Containers (UC) collaborates with regional partners and is running a partner referral program that collects sensitive data in application forms.
UC must ensure that:
Sensitive partner application data is securely handled (not public).
The list of existing partners is not visible to the general public.
Only authorized regional partners can refer new potential partners.

Why Option D is Correct
Creating an authenticated Experience Cloud site (Partner Digital Experience) ensures:
Controlled Access:
Only logged-in, verified partner users can access the referral feature and submit sensitive referral applications. This ensures that confidential information stays protected under authenticated sessions.
Data Privacy:
Sensitive partner data and referral details remain behind authentication, complying with Salesforce’s data security standards. You can use profile-based access, sharing rules, and record-level security to make sure data visibility is restricted by region.
Regional Targeting:
The Experience Cloud site can be configured to only allow referrals for the appropriate region by using Audience Targeting, Record-Level Access, or custom logic tied to the user’s Account/Region field.
Partner-Centric Workflow:
Existing partners log in → Access referral form → Submit potential partner details → Internal UC team reviews and approves → Sensitive data stays private throughout.

Why the Other Options Are Incorrect
A. Create an app for the internal business development team and allow them to generate token-based referral links.
This limits scalability and bypasses the partner self-service model. It forces internal users to act as intermediaries, which isn’t what UC wants — the partners themselves should refer others.
B. Create a public site for existing partners and allow them to generate referral links.
Public sites expose data to unauthenticated visitors, risking leakage of partner details. Since partner information is sensitive, a public site is inappropriate.
C. Create a public site for prospect partners with an NDA and application form.
Even with an NDA message, public forms are not secure enough for sensitive data. Anyone could access or attempt to submit fake or malicious information.

Key Salesforce Concepts Referenced
Authenticated Experience Cloud Sites (Partner Central Template): Designed for B2B collaboration and partner management.
Sharing Rules / Record-Level Security: Ensure sensitive regional data stays restricted.
Custom Lightning Components / Flow Forms: Allow flexible referral forms and workflows.
Experience Cloud Access Control: Authenticated users only, enabling secure handling of sensitive data.

Summary
For UC’s referral program, where sensitive information is collected and existing partner data must remain private, the authenticated Experience Cloud partner site is the best-fit solution.

Explanation:

AW Computing aims to create an Experience Cloud site that provides customers with access to Knowledge articles and peer-to-peer conversations to reduce the number of support calls. The solution should leverage Salesforce Experience Cloud features to support self-service and community engagement.

Let’s evaluate the provided options:

A. Give access to its internal orgs using Chatter groups:
This is incorrect. Chatter groups are primarily designed for internal collaboration within a Salesforce org among employees or specific external users (e.g., partners with Partner Community licenses). Granting customers access to internal orgs via Chatter groups is not a secure or practical solution for a customer-facing site, as it risks exposing internal data and does not provide a public or controlled self-service experience for Knowledge articles or peer-to-peer conversations.

B. Open its Slack implementation to all customers:
This is incorrect. While Slack can be used for customer communication in some contexts (e.g., Slack Connect for external collaboration), it is not a Salesforce Experience Cloud solution and does not natively integrate with Salesforce Knowledge articles or provide a structured peer-to-peer community for customers. Additionally, opening Slack to all customers could create security and management challenges, and it does not align with the goal of reducing support calls through a self-service site.

C. Create a site with the Customer Service template:
This is the correct answer. The Customer Service template in Salesforce Experience Cloud is specifically designed for self-service use cases.
It includes out-of-the-box features for:
Knowledge articles: Customers can search and view Knowledge articles to find answers to common questions, reducing the need for support calls.
Peer-to-peer conversations: The template supports community features like discussion forums, Q&A sections, or Chatter feeds, enabling customers to engage with each other and share solutions.
This template aligns perfectly with AW Computing’s goal of decreasing support calls by empowering customers with self-service tools and community interaction. The site can be configured with appropriate user licenses (e.g., External Apps Starter/Plus or Customer Community Plus) to ensure customers have access to these features.

D. Create a site with the Marketing Microsite template:
This is incorrect. The Marketing Microsite template is designed for lightweight, public-facing sites focused on marketing content, such as product promotions or landing pages. It is not optimized for self-service features like Knowledge article access or peer-to-peer community interactions, making it unsuitable for AW Computing’s goal of reducing support calls through a robust customer support portal.

How This Applies to AW Computing’s Scenario:
To achieve the goal of reducing support calls, AW Computing should:
Create an Experience Cloud site using the Customer Service template in Experience Builder.
Configure the site to include:
A Knowledge component to display searchable Knowledge articles, allowing customers to find answers independently.
A Community or Q&A component (e.g., Discussion Forum or Questions component) to enable peer-to-peer conversations where customers can post questions, share solutions, and interact.
Assign appropriate licenses (e.g., External Apps Starter/Plus or Customer Community Plus) to customers to access the site.
Set up permissions to ensure customers have Read access to Knowledge articles and appropriate access to community features (e.g., create and view posts).
Optionally, add moderation rules to manage peer-to-peer conversations and ensure content quality.
Use analytics (e.g., Experience Cloud dashboards) to monitor engagement and measure the reduction in support calls.

This approach leverages the Customer Service template’s built-in features to create a self-service portal that reduces the burden on AW Computing’s support organization.

Reference:
Salesforce Help, “Customer Service Template” (Winter ’26): “The Customer Service template is ideal for self-service sites, providing components for Knowledge articles, case management, and community discussions to reduce support inquiries.” Available at: Salesforce Help - Customer Service Template.
Salesforce Help, “Set Up Self-Service in Experience Cloud” (Winter ’26): “Enable Knowledge articles and discussion forums to empower customers to find answers and engage in peer-to-peer conversations.” Available at: Salesforce Help - Self-Service in Experience Cloud.

Explanation:

Salesforce imposes a limit on the number of Experience Cloud sites that can exist within a single org. This is a critical consideration for any organization managing multiple sites.
Inclusive Count: The total number of sites in an org, up to the 100-site limit, includes all sites regardless of their status. This means sites that are currently active, sites that are in a preview state (e.g., in a draft or under construction), and sites that have been deactivated or set to an inactive status all count toward the maximum.
Deletion Required for Cleanup: Simply inactivating a site does not free up a slot. To remove a site from the count and make room for a new one, it must be permanently deleted. This is an important detail for an organization like Cloud Kicks that is actively retiring old sites.
Impact of Limits: If Cloud Kicks reaches its 100-site limit, it will be unable to create any new sites until old, inactive ones are permanently removed from the org.

Why the other options are incorrect?
A. Each org can have up to 100 Experience Cloud sites; preview sites don't count toward that limit: This is incorrect. Preview sites are a form of an Experience Cloud site and are counted toward the limit.
B. Each org can have up to 100 Experience Cloud sites; preview sites count toward that limit but inactive sites do not: This is also incorrect. Both preview and inactive sites are counted toward the limit. Inactivation does not remove a site from the total count.
D. Each org can have up to 100 Experience Cloud sites as long as they are active: This is false. The limit applies to all sites, not just active ones, as described above. A mix of active, inactive, and preview sites can exist, but the total cannot exceed 100.