COMMUNITY-CLOUD-CONSULTANT Practice Questions

The most efficient and standard method to control field visibility in Salesforce is through Field-Level Security (FLS). By modifying the profile assigned to community customers, the administrator can revoke read access to the new custom fields on the Knowledge object. This declarative approach ensures the fields are hidden from customers wherever they access the article, without requiring custom code (Visualforce/Lightning Components) or inefficient content duplication. This is the most scalable, maintainable, and secure solution, aligning with Salesforce best practices.

A. Create separate articles without these custom fields for the Customer channel and include in the Community: This is highly inefficient as it creates redundant content, doubling the effort for content creation and maintenance.

C. Override the article detail page with a custom Visualforce page and hide these custom fields for customers: This is a code-based solution that is unnecessarily complex and less efficient than using the standard FLS feature for a simple visibility requirement.

D. Modify the article detail page with custom Lightning Components that hide these custom fields for customers: Similar to Visualforce, this requires custom development, which is more time-consuming and harder to maintain than the declarative FLS option.

1. Salesforce Help

"Control Access to Articles with Field-Level Security": This document explicitly states

"You can make a field on an article type visible

read-only

or hidden... Field-level security settings override page layouts and templates." This confirms FLS is the correct mechanism for hiding specific Knowledge fields from certain users.

2. Salesforce Help

"Field-Level Security": This guide provides the foundational concept: "Field-level security—or field permissions—control whether a user can see

edit

and delete the value for a particular field on an object." This applies directly to hiding the custom fields from the customer profile.

3. Salesforce Help

"Set Field-Level Security for a Field on All Profiles": This page details the administrative steps. An admin would navigate to the Knowledge object's fields

select the custom field

and adjust its visibility for the specific customer profile(s) used by the community

making it the most direct and efficient administrative action.

The official Salesforce Community Roll-out framework is structured around four key pillars that guide the entire lifecycle of a community, from initial strategy to long-term growth. These stages are:

1. Establish: Define the community's vision, strategy, goals, and key performance indicators (KPIs).

2. Manage: Handle the day-to-day operations, including content creation, moderation, and user administration.

3. Measure: Analyze community data and metrics against the established KPIs to assess health and ROI.

4. Engage: Implement tactics to foster member participation, interaction, and value, driving adoption and growth.

A, B, C, D: These options describe generic software development or project management lifecycles. They are not the specific, officially defined framework for Salesforce Community management and continuous engagement.

1. Salesforce Trailhead

Community Management Module

"Community Management Strategy and Tactics" Unit: This unit explicitly introduces the framework: "Let’s look at the four pillars of community management: Establish

Manage

Measure

and Engage." It then details the activities within each of these four stages.

2. Salesforce Trailhead

Community Rollout Strategy Module

"Develop a Community Rollout Strategy" Unit: This unit reinforces the concepts of the four pillars by discussing the phases of a rollout

which align with Establishing

Managing

Measuring

and Engaging the community for a successful launch and sustained adoption.

Visibility to Salesforce Knowledge Article Types is fundamentally controlled by a user's profile. The profile settings determine which Article Types (or Record Types in Lightning Knowledge) a user has "Read" access to. For Experience Cloud (Community) members, their assigned community profile must be granted explicit read access to the specific Article Types intended for them. While Data Categories further refine which individual articles are visible, the initial access to the entire type of article is managed at the profile level.

A. Community Settings: These settings enable or disable Knowledge for the entire site but do not provide granular control over which specific Article Types are visible.

B. User Record: The User Record assigns a user to a profile but is not the direct mechanism for controlling object-level permissions like Article Type visibility.

C. Community Manager: This is a user role responsible for administering the community; it is not a configuration setting that controls visibility for members.

E. All Articles Types within the shared data categories and visible to Community Members: This is incorrect. Data Categories filter articles, not Article Types. A user must first have profile-level access to the Article Type before Data Category visibility is applied.

1. Salesforce Help - Give Users Access to Article Types: "You can grant 'Read

' 'Create

' 'Edit

' or 'Delete' permissions to users for a specific article type through their profiles or permission sets." This document explicitly states that profiles are the mechanism for granting access to article types.

2. Salesforce Help - Set Up and Manage Salesforce Knowledge: Under the "Set Up Knowledge Users" section

the documentation guides administrators to "Give your Salesforce Knowledge users access to the articles and the Knowledge base. [...] Assign article actions to users in their user profile." This reinforces the role of the user profile in managing Knowledge access.

3. Salesforce Help - Control Access to Articles: "You control access to articles on the article type. [...] For each user profile

you can provide Create

Read

Edit

or Delete permission on a specific article type." This directly links profile permissions to Article Type access control.

To create a new community user, an administrator must perform two key steps in sequence. First, the profile intended for the new user must be added to the community's membership list. This authorizes any user with that profile to access the community. Second, the administrator navigates to the specific Contact record that will be converted into a user and uses the "Enable Customer User" action. This action creates the user record, links it to the contact and its parent account, and assigns the appropriate license and profile.

A: This step is necessary but insufficient. Adding a profile only grants access permission; it does not create any actual users for the community.

C: User enablement is performed on the Contact record, not the Account record. While the contact is related to an account, the action to create the user is on the contact.

D: This action will fail if the user's assigned profile has not been added to the community's membership first. The profile must be authorized before a user can be created with it.

1. Salesforce Help

Create Experience Cloud Site Users: "Before you can enable a contact as a customer or partner user

you must first add the profile or permission set that you want to use to your site... From the contact record for the person you want to add to a site

open the action dropdown menu and select Enable Customer User." This confirms the two-step process in option B.

2. Salesforce Help

Add Members to Your Experience Cloud Site: "You add members to a site by associating their profiles or permission sets with the site. When you add a profile to a site’s membership

users with that profile can log in to the site." This document details the first required step: adding the profile to the community.

3. Salesforce Help

Experience Cloud User Licenses: This documentation clarifies that Customer Community Plus licenses are for contacts. The user creation process is initiated from the contact record

which is tied to an account

making the action on the contact record itself the correct procedure.

The Topic Management area within Experience Workspaces (formerly Community Manager) provides a comprehensive suite of features for organizing site content. Administrators can perform lifecycle actions on topics, including creating new topics, merging redundant ones, renaming them for clarity, and deleting obsolete ones (Option A). Additionally, this area is used to curate the user experience by assigning specific topics to be "Navigational," which builds the site's primary navigation menu, and "Featured," which highlights key content on the home page or other specified pages (Option C). Both sets of functionalities are core to managing topics in an Experience Cloud site.

B. Define Knowledge Articles that will be displayed against each topic: This is incorrect. Topics are assigned to articles on the article record page itself or via automatic assignment rules, not managed from the central Topic Management section.

D. Assign Featured Topics Only: This is incomplete. The Topic Management section allows for the assignment of both Featured and Navigational topics, making this option too restrictive.

E. Assign Navigational Topics Only: This is incomplete. The ability to assign Featured topics is also a key feature, so this option only represents part of the functionality.

1. Salesforce Help

"Manage Topics in Your Experience Cloud Site": This document outlines the full scope of topic administration in Experience Workspaces. It explicitly details the processes for creating

merging

renaming

and deleting topics

as well as setting up navigational and featured topics. This single source validates both correct answers (A and C).

2. Salesforce Help

"Create

Edit

and Delete Topics in Your Experience Cloud Site": This document provides specific instructions for the actions listed in option A. It states

"From the Topics tab in Experience Workspaces

you can create

merge

rename

and delete topics."

3. Salesforce Help

"Set Up Navigational and Featured Topics": This document confirms the functionality described in option C. It instructs users to go to Content Management | Topics in Experience Workspaces to "Add topics to your site’s navigation menu" (Navigational) and "Showcase popular topics on your site’s home page" (Featured).

Salesforce Experience Cloud (formerly Communities) allows for a structured topic hierarchy to organize content. This hierarchy is limited to three levels. The maximum number of navigational topics you can create is 25 at the top level (Level 1). Each of these top-level topics can have a maximum of 10 second-level topics (Level 2). Subsequently, each second-level topic can have a maximum of 10 third-level topics (Level 3). This structure helps in creating a clear and manageable navigation system for site members.

A: The limit for Level 2 topics is 10, not 15.

B: The limits for all three levels are incorrect. The structure is not a uniform 20 across all levels.

C: The limits for all three levels are incorrect and do not reflect the official Salesforce topic hierarchy limits.

E: The limits for Level 1 (25) and Level 3 (10) are incorrect in this option.

1. Salesforce Help. (2023). Set Up Navigational and Featured Topics in Your Experience Cloud Site. Salesforce. Retrieved from https://help.salesforce.com/s/articleView?id=sf.networkstopicsnavigational.htm&type=5.

Reference Details: The section "Set Up Navigational Topics" explicitly states

"You can have up to 25 navigational topics at the top level. Each top-level topic can have up to 10 second-level topics. Each second-level topic can have up to 10 third-level topics."

A successful Partner Community roll-out strategy requires engaging all key business stakeholders to align the community's functionality with overarching business objectives. A Partner Community typically supports multiple functions, including channel sales, marketing collaboration, and partner support. Therefore, it is crucial to meet with the Sales Team (for lead distribution, deal registration), the Marketing Team (for MDF, co-branded assets), the Service Team (for case management), and Executives (for strategic vision, sponsorship, and measuring ROI). This comprehensive approach ensures the community delivers value across the entire partner lifecycle.

A, B, C: These options are too restrictive. They each omit critical business units (e.g., Service, Marketing, Sales) that are essential stakeholders in a comprehensive Partner Relationship Management (PRM) solution delivered via a community.

E: #AskForce and the Success Community are external Salesforce resources for general help and best practices. They are not the internal business stakeholders of the company implementing the community.

1. Trailhead - Experience Cloud Strategy

"Define Your Community's Strategy and Goals" Unit: This module emphasizes the importance of a cross-functional team for a successful community launch. It states

"A successful community has a C-level champion and buy-in from all the departments that the community touches. For example

if your community is for customers

you want buy-in from the heads of customer support

sales

and marketing." This principle directly applies to a Partner Community

which serves partners across sales

marketing

and service functions.

2. Trailhead - Partner Relationship Management & Channel Sales

"Partner Relationship Management (PRM) Basics" Unit: This unit describes how a PRM solution

often built on Experience Cloud

helps companies manage partners across sales

marketing

and service activities. This confirms that representatives from sales

marketing

and service are the key stakeholders for defining the requirements of a Partner Community.

3. Salesforce Help - Who Should Be Involved in Building a Community?: This documentation outlines the typical roles involved in a community project. It lists the Executive Sponsor

Community Manager

and representatives from business units like "customer service

channel sales

or marketing" as essential team members

reinforcing the need for broad stakeholder engagement.

Salesforce Experience Cloud provides native, declarative controls for file uploads. Within Experience Workspaces (formerly Community Manager), the Administration section contains a Preferences page. On this page, administrators can configure site-wide file settings, including specifying the "Max file size in MB" and defining a comma-separated list of "Allow only these file types." This approach directly meets the requirements to limit both file size and type without requiring custom code or external applications.

A: Incorrect. File types can be restricted natively in the same administrative area where the file size limit is set.

C: Incorrect. An Apex trigger is a programmatic solution. A declarative option exists and is the best practice in this scenario.

D: Incorrect. The maximum file size can be restricted natively along with the allowed file types in the administration settings.

E: Incorrect. A third-party component is unnecessary as this functionality is a standard, built-in feature of Experience Cloud.

1. Salesforce Help

Set File Size and File Type Limits in Your Experience Cloud Site: This document explicitly details the procedure. It states

"You can set limits on the size and type of files that can be uploaded to your Experience Cloud site... From Setup... click Workspaces next to your site. Select Administration | Preferences. In the Files section

set your preferences... For Allow only these file types

enter a comma-separated list of file extensions."

Source: Salesforce Help. Title: Set File Size and File Type Limits in Your Experience Cloud Site.

2. Salesforce Help

Experience Workspaces: This document outlines the navigation and purpose of Experience Workspaces

confirming that Administration is a key area for site management. The path Workspaces > Administration > Preferences is the standard location for these settings.

Source: Salesforce Help. Title: Navigate Experience Workspaces.

3. Trailhead

Experience Cloud Basics

Set Up Your Experience Cloud Site: This module covers the fundamental setup of an Experience Cloud site

guiding users through the Administration workspace where preferences

including member access and file settings

are configured.

Source: Salesforce Trailhead. Module: Experience Cloud Basics. Unit: Set Up Your Experience Cloud Site.

To associate a custom domain with a Salesforce Experience Cloud site, a Canonical Name (CNAME) record must be created in the company's Domain Name System (DNS). The CNAME record maps the desired custom domain (e.g., community.regionalcontainers.com) as an alias to the internal Salesforce-hosted domain provided when you set up the domain in Salesforce. This allows web traffic for the custom URL to be correctly routed to the Salesforce servers hosting the community, without needing a static IP address, which Salesforce does not provide for sites.

A. MX Record: Incorrect. Mail Exchange (MX) records are used to specify mail servers for a domain and are unrelated to website hosting.

B. TXT Record: Incorrect. Text (TXT) records are used for verification purposes (like SPF or DKIM) and do not direct web traffic.

C. NS Record: Incorrect. Name Server (NS) records delegate a DNS zone to be managed by specific authoritative name servers, not point a hostname.

E. AAAA Record: Incorrect. AAAA records map a domain to an IPv6 address. Salesforce does not provide a static IP address for Experience Cloud sites.

1. Salesforce Help

"Point Your Custom Domain to Your Salesforce Org": This document explicitly states

"Work with your DNS provider to create a CNAME record to point your domain to your org." It details the process of mapping the custom domain to the Salesforce-generated internal FQDN.

2. Salesforce Help

"Set Up a Custom Domain for Your Experience Cloud Site": In the prerequisites section

it notes

"To point your custom domain to your org

add a CNAME record in DNS." This guide provides the step-by-step instructions for the entire process.

3. Salesforce Help

"Domains": Under the "Custom URLs" section

the documentation explains that custom URLs for Experience Cloud sites are served through a custom domain. The setup for this custom domain requires pointing it to your Salesforce org via a CNAME record in your DNS.

Experience Cloud templates, such as Koa, are built with a responsive design. This core feature ensures that the community's layout and components automatically adjust to provide an optimal viewing experience on any device, including desktops, tablets, and smartphones. For an external community member using an iOS device, the most direct and standard method of access is to navigate to the community's URL using a mobile web browser like Safari. The platform will automatically render the mobile-friendly version of the site without requiring any additional applications.

A: The Salesforce mobile app is primarily designed for internal Salesforce users. While it can access communities, it is not the standard or recommended method for external community members.

B: This is incorrect. Koa and other Experience Builder templates are specifically designed to be responsive and provide a seamless experience on mobile devices, not just desktops.

C: "OneCommunity" is not a standard Salesforce application. Organizations can create a custom-branded app using Mobile Publisher, but this is a separate, paid feature, not a default app.

1. Salesforce Help - Experience Cloud on Mobile Devices: This document outlines the mobile access options. It states

"Your Experience Builder site is mobile responsive

so users can access it from their mobile browsers without having to download an app." This directly supports the correctness of option D.

2. Salesforce Help - Choose an Experience Builder Template: The description for templates like Koa and Kokua notes they are "responsive and rich with features

" confirming they are designed for various devices

which contradicts option B.

3. Salesforce Help - Salesforce Mobile Publisher for Experience Cloud: This documentation describes Mobile Publisher as the tool to "create and submit a fully branded version of your app to the Apple App Store and Google Play." This clarifies that a branded app is a custom creation

not a generic app like the fictitious "OneCommunity" mentioned in option C.

4. Salesforce Help - Access Experience Cloud Sites in the Salesforce Mobile App: This document clarifies the use of the Salesforce app for communities

noting its primary audience is internal users and that access is managed through the app's navigation menu (switcher)

reinforcing that this is not the primary method for external members.