Universal Containers recently built a Community for their customers. They would like to allow access Of files maintained in their Sharepoint Online with customers. Which Salesforce feature should the Salesforce Admin recommend?
A. Content Library
B. Files Connect
C. Files Sync
D. Chatter and Files
Explanation:
🔗 Files Connect is the correct and recommended Salesforce feature for this use case.
It allows Salesforce users (including Community users) to:
Access and share files stored in external repositories, such as:
SharePoint Online
Google Drive
OneDrive
Box
Search and reference external files without copying them into Salesforce
Optionally preview or attach them to records, depending on configuration
🔐 Security Considerations:
Files Connect can be configured to use:
OAuth 2.0 authentication for services like SharePoint Online
Access can be controlled using permission sets and profiles
It supports both internal and external (community) users, with proper setup
📚 Reference:
Salesforce Help - Files Connect Overview
Set up Files Connect for SharePoint Online
❌ Why Other Options Are Incorrect:
A. Content Library
This is a part of Salesforce CRM Content, now largely deprecated
Does not support external file systems like SharePoint
C. Files Sync
Was part of the older Salesforce Files product
Retired and no longer supported in Lightning Experience
Does not support SharePoint integration
D. Chatter and Files
Lets you share internal Salesforce files within Chatter
Does not support external repositories like SharePoint
🏁 Conclusion:
If you want external file access in Salesforce (including Experience Cloud/Communities), and specifically need to integrate with SharePoint Online, the best and native solution is:
👉 ✅ B. Files Connect
Universal Containers launched their Community built on the Napili template. They would like to update the Community with Live Agent support and additional menu option for Assets. What is the most efficient way for a Salesforce Admin to roll out the new features?
A. Deactivate the Community to make changes to the Community and reactivate with changes after testing in a Sandbox
B. Build a new Community with required features after testing in a Sandbox and deactivate the existing Community
C. Make changes to the existing Community after testing in a Sandbox and publish the Community when the changes are ready for customers.
D. Create new Community profiles with the modified features and assign them to customers when the Community is ready for customers.
Explanation:
Key Requirements:
Add Live Agent support and a new Assets menu option to the existing Napili-based Community.
Ensure minimal downtime and a smooth rollout.
Why Option C?
Test in Sandbox First:
Safely implement and validate Live Agent and menu updates in a sandbox.
Deploy to Production:
Apply changes to the existing Community (no need to rebuild).
Publish When Ready:
Updates go live without deactivating the Community, minimizing disruption.
Why Not Other Options?
A. Deactivate Community: Causes unnecessary downtime; changes can be made without deactivation.
B. Build New Community: Inefficient—existing Community can be updated directly.
D. New Profiles: Profiles control access, not feature deployment; irrelevant for this use case.
Reference:
Salesforce Help: Update Communities
Trailhead: Manage Community Updates
Conclusion: The most efficient method is testing in sandbox, updating the existing Community, and publishing (Option C). ✅
How should the Salesforce Admin meet this requirement? Universal Containers creates a Community for their partners. Members of the Community should not be able to participate in discussions with other members. However, users from the same partner should be able to hold discussions amongst themselves.
A. Create a sharing group for partner accounts under Sharing Settings.
B. Deselect Community User Visibility under Sharing Settings.
C. Update the Internal User record to Private under Sharing Settings.
D. Turn off Portal User Visibility under Sharing Settings.
Explanation:
Universal Containers wants to create a Community (Experience Cloud) for their partners where Community members (Partner Community users) cannot participate in discussions with users from other partner organizations but can hold discussions within their own partner organization. The most efficient way to meet this requirement is to deselect Community User Visibility under Sharing Settings. This setting, when disabled, restricts external users (e.g., Partner Community users) from seeing users outside their own account, ensuring that partners can only interact with users from their own organization in discussions (e.g., via Chatter or forums).
How It Works: In Setup > Sharing Settings, locate the “Community User Visibility” setting (under “Other Settings”). Deselect the checkbox to disable visibility of Community users across different accounts. This ensures Partner Community users can only see and interact with users associated with their own partner account (e.g., via the Account hierarchy), allowing intra-partner discussions while preventing cross-partner interactions.
Reference: Salesforce Help: Control Community User Visibility.
Why Other Options Are Incorrect
A. Create a sharing group for partner accounts under Sharing Settings:
Why Incorrect: Sharing groups (or sharing sets) are used to grant record access based on user attributes (e.g., account or role), not to control user visibility in discussions. They do not restrict Community users from seeing or interacting with other users in discussions, failing to meet the requirement.
C. Update the Internal User record to Private under Sharing Settings:
Why Incorrect: Setting the organization-wide default (OWD) for the User object to Private restricts internal user visibility but does not apply to external Community users (e.g., Partner Community users). The requirement focuses on Community members, not internal users, making this option irrelevant.
D. Turn off Portal User Visibility under Sharing Settings:
Why Incorrect: “Portal User Visibility” is a legacy setting for older Salesforce Portals (e.g., Customer Portal), not Experience Cloud Communities. It is not applicable to modern Communities, and the correct setting is “Community User Visibility.”
Additional Details
Community User Visibility: When disabled, this setting leverages the Account-based structure of Partner Community users, ensuring users only see others tied to the same Account (e.g., same partner organization). This applies to Chatter posts, discussions, and user searches in the Community.
Partner Community Licenses: Ensure Partner Community users are assigned to profiles with appropriate access to Chatter and discussion features, restricted by the Community User Visibility setting.
Testing: Test in a sandbox to confirm that users from different partner accounts cannot see or interact with each other in discussions, while intra-account discussions work as expected.
Best Practice: Combine with role-based sharing or account relationship data sharing rules for additional control over record access, if needed, to complement discussion restrictions.
References:
Salesforce Help: Control Community User Visibility – Explains the Community User Visibility setting and its impact on external user interactions.
Salesforce Trailhead: Experience Cloud Basics – Covers user visibility and sharing for Communities.
Universal Containers builds a Partner Community for their dealers. They set up the partner account with two roles to represent sales employees and their managers. After going live, the dealerships inform Universal Containers that they need a CEO type of access for specific users who need to access all of the data on the partner account. How should the Salesforce Admin fulfil this requirement?
A. Promote the CEO partner user to delegated admin on the partner account
B. Assign Super User access to the CEO partner user on the Contact page
C. Add a third role to the partner account hierarchy for the CEO partner user
D. Make the CEO partner user the owner of the partner account
Explanation:
Salesforce provides a specific feature for Partner Community Users called Super User Access.
🔑 What is Super User Access?
A Partner Community Super User can:
View data owned by other users in the same partner account
View and access leads, opportunities, cases, and custom object records associated with the account
Without needing to be in a higher role in the role hierarchy
This is exactly what the CEO-type user needs.
🧩 Why the Other Options Are Incorrect:
A. Promote the CEO partner user to delegated admin
❌ Delegated administration allows the user to manage users, reset passwords, etc.
It does not give access to records or data visibility.
C. Add a third role to the partner account hierarchy
❌ Each partner account in Salesforce can have up to 3 roles, but this does not solve access on its own.
Also, you’re already using 2 roles, and the question doesn’t specify needing more role separation — only broader access within the account.
Even if you add a 3rd role, it won’t allow the CEO to view all records unless record ownership and sharing are also adjusted.
D. Make the CEO partner user the owner of the partner account
❌ Account ownership doesn't grant full access to all related opportunities, leads, etc., unless sharing rules are changed.
Also, you wouldn’t typically reassign account ownership just for data visibility purposes in Partner Communities.
🛠 How to Enable Super User Access:
Go to the Contact record associated with the Partner Community user
Check the box: "Enable Super User Access"
Save
🔗 Reference:
Super User Access for Partner Users (Salesforce Help)
Partner Community User Access Control
🏁 Final Answer:
👉 ✅ B. Assign Super User access to the CEO partner user on the Contact page
What are the two most efficient ways for the Salesforce Admin to fulfill the following requirements?
Universal Containers plans to build a large-scale Community and expose Leads and Opportunities to their resellers. Universal Containers has the following requirements for their partner account:
• 120,00 partner accounts
• Minimize the number of partner account roles
• Partner account is made up of sales employees and sales managers
• Sales employees only have access to their data
• Sales managers have access to all sales employees data
A. Set up partner accounts with two roles.
B. Set up partner accounts with one role.
C. Use sharing rules to grant sales managers access to sales employees data.
D. Make the sales manager the Super User on the partner account.
Explanation:
Requirement Breakdown:
120,000 partner accounts → Need a scalable solution.
Minimize roles → Avoid complex hierarchies.
Sales employees → Access only their own data.
Sales managers → Access all employees' data.
Why Option A (Two Roles)?
Sales Employee Role: Default access to their own records.
Sales Manager Role: Higher in the role hierarchy, inheriting access to subordinates' data.
Minimal roles (just 2) meet the requirement while keeping it simple.
Why Option D (Super User for Managers)?
Super User Access (on the Contact record) allows managers to:
Bypass role hierarchy and see all data under the partner account.
Works without additional sharing rules (simpler than Option C).
More scalable than manual sharing rules for 120K accounts.
Why Not Other Options?
B (One Role): Fails because managers wouldn’t automatically see employee data.
C (Sharing Rules): Not scalable for 120K accounts (high maintenance).
Reference:
Salesforce Help: Partner Role Hierarchy
Super User Access for Partners
Conclusion:
Two roles (A) + Super User for managers (D) is the most efficient and scalable approach. ✅
A coffee company is launching a public brand worldwide. Consumers need to see all relevant information about the brand in one place. Brand advisors can also submit applications to become partners. How should the coffee companies administrator meet these requirements?
Select one or more of the following:
A. Create a Private Community and let brand advisors and consumers register themselves.
B. Create a Public Community for consumers and brand advisors.
C. Create a Public Community and let brand advisors and consumers register themselves.
D. Create a Public Community for consumers and a separate Private Community for brand advisors
Explanation
The coffee company needs a solution to provide consumers with all relevant brand information in one place and allow brand advisors to submit partnership applications, as part of a worldwide public brand launch. The most effective approaches are:
C. Create a Public Community and let brand advisors and consumers register themselves: A Public Community (Experience Cloud site with public access) allows consumers to access brand information without authentication, meeting the requirement for a centralized information hub. Self-registration enables both consumers and brand advisors to create their own accounts, streamlining access for submitting partnership applications.
D. Create a Public Community for consumers and a separate Private Community for brand advisors: A Public Community serves consumers with brand information, while a separate Private Community (requiring login) for brand advisors provides a secure space for submitting and managing partnership applications, ensuring sensitive data is protected.
Why Efficient:
Option C uses a single Public Community with self-registration, which is simple to set up and allows both audiences to access information and submit applications. It’s ideal for a streamlined, public-facing solution.
Option D separates audiences for enhanced security and user experience, with a Public Community for consumers and a Private Community for brand advisors to handle sensitive application processes. This is scalable and secure for managing different user needs.
Reference:Salesforce Help: Experience Cloud Site Access and Self-Registration for Experience Cloud Sites.
Why Other Options Are Incorrect
A. Create a Private Community and let brand advisors and consumers register themselves:
Why Incorrect: A Private Community requires all users to log in, which is not suitable for consumers needing easy access to public brand information. This contradicts the requirement for a public-facing hub where consumers can view information without barriers.
B. Create a Public Community for consumers and brand advisors:
Why Incorrect: While a Public Community works for consumers, it lacks specificity about self-registration or handling sensitive brand advisor applications. Without self-registration, managing access for brand advisors could be manual and inefficient. Additionally, public access may not secure sensitive application data, making this less precise than Options C and D.
Additional Details
Option C (Single Public Community):
Setup: Use a template like Customer Service in Experience Builder to create a Public Community. Enable self-registration (Setup > Feature Settings > Digital Experiences > Settings > Allow self-registration) with profiles like Customer Community for consumers and Partner Community for brand advisors. Add a custom form (e.g., via Lightning Web Components or Flow) for advisors to submit applications.
Pros: Simplifies management with one site; public access suits consumers; self-registration streamlines onboarding.
Cons: Less secure for advisor applications unless additional security (e.g., restricted pages) is implemented.
Option D (Public + Private Communities):
Setup: Create a Public Community for consumers using a template like Customer Account Portal, with no login required for brand information. Create a Private Community for brand advisors using a Partner Central template, enabling self-registration with a Partner Community license for secure application submission.
Pros: Separates public and sensitive data; enhances security for advisor interactions; tailored user experiences.
Cons: Requires managing two sites, increasing setup and maintenance effort.
Security: For Option C, use page variations or audience targeting to restrict application forms to authenticated users. For Option D, the Private Community inherently secures advisor data. Ensure appropriate licenses (e.g., Customer Community for consumers, Partner Community for advisors).
Best Practice: Test in a sandbox to verify public access for consumers and secure self-registration for advisors. Use Salesforce CMS or Knowledge for brand content and Flow for application forms.
References
Salesforce Help: Experience Cloud Site Access – Details public and private site configurations.
Salesforce Trailhead: Experience Cloud Basics – Covers site creation and self-registration.
A Community has two types of users:
- External users who can belong to multiple Communities.
- Internal users who belong to one or more Communities. Which two features allows both user groups to navigate between each Community?
Choose 2 answers.
A. Mobile Administration.
B. Global Header
C. Community URL.
D. Appending "/one/one.app" to the Community URL
Explanation:
To allow internal and external users to navigate between multiple Communities, Salesforce provides features that support seamless transitions across branded sites. Here's how the correct options fulfill that:
✅ B. Global Header
The Global Header is a navigation bar that appears at the top of the screen and allows users to switch between Communities they are members of.
It’s especially useful for internal users who belong to multiple Communities and need quick access.
External users can also use it if they’re members of more than one Community.
Must be enabled in Setup under Experience Cloud Settings.
✅ C. Community URL
Each Community has a unique URL, and users can navigate directly to any Community they’re a member of by entering or clicking the appropriate link.
This is the most basic and universal method for accessing different Communities.
Works for both internal and external users, assuming they have the right permissions.
🚫 Why the Other Options Don’t Fit
A. Mobile Administration
Refers to admin capabilities on mobile — not related to user navigation between Communities.
D. Appending "/one/one.app"
This loads the Lightning Experience UI, not a method for switching between Communities. It’s used for internal org navigation, not Community transitions.
📚 References:
Global Header Overview
Experience Cloud Navigation Best Practices
What moderation capabilities does Salesforce communities provide to automate the process of identifying and replacing words that are offensive or inappropriate for the Community?
A. Create Process flows to identify posts with the offensive or inappropriate words and replace with other content
B. Enable Moderation for the Community to block offensive or inappropriate content
C. Write a trigger to identify posts with the offensive or inappropriate words and replace with other content
D. Use moderation rules in the Community to block offensive or inappropriate content
Explanation:
✅ Moderation Rules in Experience Cloud:
Salesforce Communities provide built-in moderation tools to help automatically monitor and control user-generated content like:
Posts
Comments
Questions
Answers
With moderation rules, admins can:
Define a keyword list (offensive or sensitive terms)
Automatically:
Flag or block content
Replace offensive words (optional)
Send notifications
Assign moderation actions (like hiding or deleting posts)
Escalate to moderators or case records
⚙️ How to Use Moderation Rules:
Go to Experience Workspaces > Moderation
Create Keyword Rules using lists of inappropriate or sensitive terms
Choose actions like:
Replace word with asterisks
Block post/comment
Notify moderators
🔗 Reference:
Salesforce Help - Community Moderation Rules
🚫 Why the Other Options Are Incorrect:
A. Create Process Flows
❌ Process Builder / Flows can’t access or modify Chatter or feed content directly
❌ Not designed for real-time content moderation
B. Enable Moderation for the Community
❌ Enabling moderation is step 1, but alone it does nothing unless you configure specific moderation rules
C. Write a Trigger
❌ Writing a trigger on feed posts/comments is complex, error-prone, and not recommended
❌ You’d need to write and maintain custom Apex code, which Salesforce already provides natively via moderation rules
🏁 Final Answer:
👉 ✅ D. Use moderation rules in the Community to block offensive or inappropriate content
Which three Salesforce editions/user license combinations allow external users to access a Community on Salesforce1? Choose 3 answers.
A. Performance Edition/Customer Community.
B. Professional Edition/Customer Community.
C. Database.com Edition/ Customer Community.
D. Unlimited Edition/Customer Community.
E. Enterprise Edition/Customer Community Plus.
Explanation:
Key Requirement:
External users need Salesforce1 (Mobile) access via a Community.
Must be supported by the Salesforce edition and user license combination.
Supported Editions & Licenses:
Performance, Unlimited, and Enterprise Editions allow Customer Community or Customer Community Plus licenses.
Salesforce1 access is enabled for these licenses.
Why Not Other Options?
B. Professional Edition → Does not support Communities (requires at least Enterprise Edition).
C. Database.com Edition → No support for Customer Community licenses.
Reference:
Salesforce Help: Editions Comparison
Supported Licenses for Salesforce1
Conclusion: A, D, and E are the valid combinations. ✅
A Salesforce Admin enables "Allow members to Flag" in Community Workspaces. Which two content types can members flag as inappropriate? (Choose two.)
A. Posts and Comments
B. Topics
C. Files
D. Articles
Explanation:
When the Salesforce Admin enables “Allow members to flag content” in Experience Cloud Workspaces, members gain the ability to report inappropriate content directly from the UI. This feature supports flagging of:
Posts and Comments: These are the most common types of user-generated content in groups and feeds. Members can flag them using the “Flag as inappropriate” option.
Files: Uploaded files can also be flagged if they contain offensive or inappropriate material.
This empowers the community to self-moderate and helps admins maintain a safe and respectful environment.
🚫 Why B and D Are Incorrect
B. Topics
Topics are metadata tags used for organizing content. They are not user-generated content and cannot be flagged.
D. Articles
Knowledge articles are typically authored and published by internal users. They are not subject to member flagging via this feature.
🛠️ How to Enable Flagging
Go to Experience Workspaces.
Navigate to Administration → Preferences.
Check “Allow members to flag content”.
Save changes.
Once enabled, members will see the “Flag as inappropriate” option on supported content types.
📚 Reference:
Salesforce Help: Enable Members to Flag Items in Your Experience Cloud Site
Universal Containers (UC) has built a Community in a sandbox where it is in Active status. UC is getting ready to deploy the Community in production where it is currently Inactive. UC wants to ensure the welcome email is only sent to users after the Community is changed to Active status. Which three options should be validated to ensure the welcome email is not sent out ahead of schedule?
Choose 3 answers Select one or more of the following:
A. Turn the sandbox Community to Inactive status before deploying the metadata to production
B. Add the Community user profile(s) as members of the Community before activating production
C. Uncheck "Send Welcome Email" in production Workspaces before deployment
D.
Deploy the changes to production using change sets to disable the welcome email
Deploy the changes to production using change sets to disable the welcome email
Explanation:
Let’s break down each correct and incorrect answer:
✅ A. Turn the sandbox Community to Inactive status before deploying the metadata to production
✔️ Important because when using change sets, metadata related to the Community (such as status) can be deployed to production.
If the Community is active in the sandbox, it could unintentionally activate the Community in production upon deployment, triggering welcome emails.
Making the sandbox Community inactive before deployment prevents this.
✅ C. Uncheck "Send Welcome Email" in production Workspaces before deployment
✔️ The "Send Welcome Email" setting in Workspaces > Administration > Emails controls whether users get welcome emails when added to the Community.
By unchecking this, you can safely add users before activation without triggering emails.
This is the primary control Salesforce provides for email suppression.
✅ D. Deploy the changes to production using change sets to disable the welcome email
✔️ This refers to including the email settings as part of your change set to ensure "Send Welcome Email" is disabled when deployed.
While you cannot directly disable the email through metadata, this option assumes you're intentionally structuring your deployment to include this control.
🚫 Incorrect Answer:
❌ B. Add the Community user profile(s) as members of the Community before activating production
❌ Dangerous — if "Send Welcome Email" is enabled, users will receive emails immediately when added, regardless of whether the Community is active.
Adding profiles does not delay the email; the welcome email is triggered when users are added as members with the email setting ON.
Only do this after disabling the welcome email setting.
🔗 Reference:
Salesforce Help: Welcome Email Settings in Communities
Change Set Best Practices for Experience Cloud
🏁 Final Answer:
👉 ✅ A. Turn the sandbox Community to Inactive status before deploying the metadata to production
👉 ✅ C. Uncheck "Send Welcome Email" in production Workspaces before deployment
👉 ✅ D. Deploy the changes to production using change sets to disable the welcome email
You are setting up an Authenticated Community for your Customers many of them speak both English and French how will you ensure the most appropriate language(s) are available to them in your Napili Template Community?
A. Develop a custom lightning component which will allow seamless transition between anguages
B. Install the Google Translation component which allows Authenticated users to swap between languages
C. Language will be determined by the language set on their User Profile
D. Place the Language Picker Component on the Community home page
E. Multi-Language support is not available for Napili Template communities
Explanation:
Salesforce’s Napili template (now part of Lightning Experience Builder templates) fully supports multi-language Communities, making it ideal for global audiences like English and French-speaking customers.
Here’s how the correct options fulfill the requirement:
✅ C. Language Set on User Profile
Salesforce uses the Language field on the User record to determine the default language for authenticated users.
When a user logs in, the Community automatically displays content in their preferred language (if translations are available).
This is a native feature and requires no customization.
✅ D. Language Picker Component
The Language Picker is a standard Experience Builder component.
It allows users to manually switch languages from the Community UI.
Especially useful for bilingual users or those accessing from shared devices.
Can be placed on the home page or header for easy access.
🚫 Why the Other Options Don’t Fit
A. Custom Lightning Component
Unnecessary — Salesforce provides built-in multilingual support and components.
B. Google Translation Component
Not a standard Salesforce component; Google Translate integration is possible but not recommended for authenticated content due to accuracy and privacy concerns.
E. Multi-Language Not Available
Incorrect — Napili fully supports multilingual Communities via Experience Builder.
🛠️ Implementation Tips
In Experience Builder, go to Settings → Languages to add supported languages.
Use translated content in component properties or import translations via XML.
Enable Language Picker from the component panel and drag it to your desired location.
📚 Reference:
Salesforce Help: Multilingual Sites in Experience Builder
| Page 4 out of 24 Pages |
| Previous |