Salesforce Certified Sharing and Visibility Architect Practice Test Questions, Exam Dumps

Practice Exams:

View All

Certified Sharing and Visibility Architect Salesforce Practice Test Questions and Exam Dumps

Question 1
Universal Containers uses 75,000 distributors that have close to 1 million total users. Distributors need to use the community to see closing opportunities assigned to their distributor for delivery.
What license recommendation will meet distributor needs?

A. Customer Community
B. Customer Community Plus
C. Sales Cloud
D. Partner Community

Correct Answer: D

Explanation:

When selecting the appropriate Salesforce license type for community users, several key factors must be considered, including:

The number of users.
The functionality those users require.
Whether users need access to standard CRM objects, such as Opportunities, Leads, Accounts, and Contacts.

Let’s break this scenario down to match the right license type.

Key Requirements from the Scenario:

Large User Base: The organization has 75,000 distributors with close to 1 million users total.
Functionality Need: Distributors need to view opportunities assigned to them. Opportunities are a standard CRM object.
Use Case: This is a business-to-business (B2B) scenario, not a direct-to-consumer one.

License Options Explained:

A. Customer Community

Best for B2C scenarios with high volumes of users who only need access to basic data (e.g., cases, knowledge, or custom objects).
Limitations: It does not support access to CRM objects like Opportunities, Leads, or Campaigns.
Not suitable here because distributors need Opportunity access.

B. Customer Community Plus

Provides more access control and sharing capabilities (e.g., roles, reports, and dashboards), but still does not include CRM objects like Opportunities.
Also unsuitable due to the need for Opportunity access.

C. Sales Cloud

A full Salesforce license, offering complete CRM access including Opportunities, Leads, and Forecasts.
Designed for internal users, not for community users.
Not cost-effective or scalable for 1 million external users like distributors.

D. Partner Community

Tailored for external users in a B2B context, such as distributors, resellers, and channel partners.
Provides full access to CRM objects, including Opportunities, Leads, Contacts, and Accounts.
Scales to a large number of users with appropriate access and control through role hierarchies and sharing settings.
This is the ideal license for this scenario.

Summary:

Distributors need access to standard CRM objects (Opportunities) in a B2B model involving a large external user base. Only the Partner Community license fulfills both the access and scalability requirements effectively.

Correct answer: D

Question 2
Sales Operations at Universal Containers (UC) has created Public Report and Dashboard folders for sales managers that report to the VP of Sales. Sales Operations currently spends a few hours each month updating users that should have access to edit items in these folders.
In which two ways can UC grant access to sales managers to automate access to these Reports and Dashboards folders? (Choose two.)

A. Share the folders with the “VP of Sales” Role and Subordinates.
B. Share the folders lowest roles in the Role Hierarchy, superiors will get access automatically.
C. Share the folders with a “Sales Managers” Public Group.
D. Share the folders with the “Sales Managers” Queue.

Correct Answers: A and C

Explanation:

In Salesforce, Reports and Dashboards are stored in folders, and folder access determines who can view, edit, or manage the reports and dashboards within. Automating access to these folders is crucial for efficiency, especially in a hierarchical or role-based organization like Universal Containers.

Let’s analyze the options:

A. Share the folders with the “VP of Sales” Role and Subordinates.

Correct.
Sharing folders with a Role and Subordinates gives access to all users in that role and any roles below it in the hierarchy.
This is a scalable and hierarchy-based way of granting access.
Since sales managers report to the VP of Sales, this ensures they receive the necessary folder access automatically as long as their role is properly aligned.

B. Share the folders with the lowest roles in the Role Hierarchy, superiors will get access automatically.

Incorrect.
Role hierarchy access does not automatically flow upwards for reports and dashboard folders. In Salesforce, sharing in folders is explicit and does not follow standard record-level sharing rules. Therefore, if you share a low-level role, their superiors do not inherit access.

C. Share the folders with a “Sales Managers” Public Group.

Correct.
A Public Group is a flexible and powerful way to manage access.
By creating a group called Sales Managers and adding the relevant users to it, you can share the folder once with this group and simply manage the group membership going forward. This greatly reduces manual effort.

D. Share the folders with the “Sales Managers” Queue.

Incorrect.
Queues in Salesforce are used to manage ownership of certain object records (like Cases, Leads, etc.), but not for sharing Reports and Dashboards. Queues cannot be used to grant folder access.

Summary:

To automate folder access for sales managers:

Role-based sharing (A) helps cover access through organizational hierarchy.
Public Groups (C) allow easy manual control over access without having to configure individual permissions constantly.

Correct answers: A and C

Question 3
When a company is making extensive updates to its Salesforce role hierarchy, which advanced feature can Salesforce activate to help manage performance and reduce data locking issues?

A. Set external organization-wide default to public read only
B. Granular locking
C. Partitioning by Divisions
D. Skinny Table Indexing

Correct Answer: B

Explanation:

In Salesforce, adjusting the role hierarchy on a large scale—such as reassigning many users, changing reporting structures, or modifying access—can have major effects on system performance. These types of operations often trigger extensive recalculations of sharing rules and data access, which can lead to record locking issues, especially in organizations with complex hierarchies and a high volume of concurrent transactions.

To help with this, Salesforce offers an advanced, behind-the-scenes feature called granular locking. This is not a user-enabled setting but rather something Salesforce Support can turn on for large or enterprise-level orgs experiencing locking contention during such operations.

Granular locking works by refining how Salesforce locks parts of the role hierarchy. Normally, when a role is updated, Salesforce might lock the entire subtree of that role to prevent data inconsistencies. However, this broad locking can cause major issues if other processes also need access to that data at the same time. With granular locking, Salesforce can lock smaller portions of the hierarchy (e.g., at the role or group level) rather than the entire structure. This reduces lock contention, allows for greater concurrency, and leads to faster, more efficient operations.

Here’s why the other options are incorrect based on the context of the question:

A. Set external organization-wide default to public read only: This option affects external users (like community or portal users) and controls whether they can see or edit records. It does not help with internal performance or hierarchy recalculations.
C. Partitioning by Divisions: This helps segment data (like accounts and cases) for reporting or organizational purposes, but it does not address lock contention or role hierarchy performance.
D. Skinny Table Indexing: Skinny tables are designed to improve performance for queries by creating smaller versions of frequently accessed tables. While useful for improving read performance, they have nothing to do with role hierarchy or record locking.

Based on the information and best practices confirmed in Salesforce documentation and performance tuning references, granular locking is the correct and most appropriate advanced tool for this scenario. It is specifically designed to support large-scale role hierarchy realignments by reducing the impact of locking and improving the efficiency of operations in high-data-volume environments.

Question 4
When a partner account is first set up and the initial external user is created in Salesforce, how many roles are automatically generated by default for that account?

A. 3
B. 2
C. 1
D. 0

Correct Answer: A

Explanation:

In Salesforce, when working with Partner Community users (also known as Partner Portal or Partner Relationship Management users), role management is handled automatically to provide proper visibility and access within the partner's organization. This structure is important because it determines how data is shared between internal and external users while maintaining security and access boundaries.

When the first external user is created on a partner account, Salesforce automatically creates a role hierarchy with three roles assigned specifically to that partner account. These roles are structured to support visibility within the partner company and between the partner and the internal Salesforce org. The three default roles created are:

Partner Executive – Typically the top role, intended for higher-level users like partner managers or executives.
Partner Manager – A middle-tier role, suitable for managing reps and overseeing partner operations.
Partner User – The bottom role, typically used for standard partner sales reps or support users.

This predefined structure is designed to mirror typical business hierarchies and support common sharing needs, such as allowing a partner manager to view or manage data owned by partner users in their organization. Additionally, these roles ensure that Salesforce's role-based sharing rules can be applied efficiently to control access to records like leads, opportunities, and custom objects.

Let’s look at why the other choices are incorrect:

B. 2: Although some other community types or org structures may involve fewer roles, in the context of a Partner Community, Salesforce specifically generates three roles to cover different levels of user responsibility within the partner’s organization.
C. 1: One role might be sufficient for simpler external sharing models (such as a Customer Community), but partner structures require more granularity, which is why three are created.
D. 0: External users cannot function properly without roles since Salesforce uses roles to determine data visibility. Creating a user without roles would severely limit their ability to access records and collaborate effectively.

When the first partner user is created, Salesforce automatically provisions three roles to manage data access within that partner organization. This setup is key to enabling scalable, secure, and structured collaboration with external partners while maintaining internal data visibility controls.

Question 5
A finance analyst at Universal Containers was temporarily granted access to Opportunities but now also sees Account and Contact records, even though the Finance team typically doesn't need access to these.

What are two possible reasons for this unexpected visibility? (Choose two.)

A. Contact records can be accessed due to implicit sharing from Account.
B. Account records can be accessed due to role hierarchy.
C. Account records can be accessed due to implicit sharing from Opportunity.
D. Contact records can be accessed due to implicit sharing from Opportunity.

Correct Answer: A and C

Explanation:

This question deals with implicit sharing in Salesforce, which refers to automatically granted access to related records based on standard parent-child relationships, regardless of sharing rules or manual sharing. This mechanism is designed to maintain logical access to relevant data when users are granted permissions on related records.

Let's analyze the scenario:

The finance analyst is explicitly given access to Opportunity records, but now they also see Account and Contact records—even though they normally shouldn’t. So, how could this visibility be happening?

C. Account records can be accessed due to implicit sharing from Opportunity – Correct

When a user is granted access to an Opportunity, Salesforce provides implicit access to its parent Account. This makes sense from a business perspective: if someone is working a deal (Opportunity), they often need information about the associated Account to do their job effectively (e.g., for financial verification, contacts, or history). So, if the finance analyst has been granted access to the Opportunity, they automatically gain access to the related Account, even if they haven't been given Account access directly. This is a classic case of implicit sharing from child (Opportunity) to parent (Account).

A. Contact records can be accessed due to implicit sharing from Account – Correct

Contact records are generally treated as child records of Accounts. When a user has access to an Account, they automatically receive read access to the associated Contacts due to implicit sharing. This access is not manually assigned but is part of the standard Salesforce data model. So, once the analyst gains access to the Account (via implicit sharing from the Opportunity), they also get access to its Contacts. That chain of access explains how a temporary Opportunity permission leads to Account and Contact visibility.

B. Account records can be accessed due to role hierarchy – Incorrect

The role hierarchy allows users higher in the hierarchy to inherit access to records owned by users lower in the hierarchy. However, the scenario doesn’t mention any change to the finance analyst’s role or their position in the hierarchy. Furthermore, this would not explain temporary access triggered by Opportunity sharing.

D. Contact records can be accessed due to implicit sharing from Opportunity – Incorrect

Opportunities are not directly related to Contacts in a parent-child relationship. Even if an Opportunity has a Contact Role, it does not grant implicit access to the Contact record itself. Implicit sharing does not flow from Opportunity to Contact, so this is not a valid explanation for the observed behavior.

Summary:

The finance analyst’s access to Opportunity records triggered implicit sharing that allowed access to Account records, which in turn granted access to related Contact records. Therefore, the correct causes of this access chain are:

Account access due to implicit sharing from Opportunity
Contact access due to implicit sharing from Account

Question 6
Sarah from Universal Containers shares a public link to a product brochure stored in Salesforce Files with some customers during a meeting. After the meeting, she wants to make sure those customers can no longer access that file through the link.

What should she do?

A. Delete the public link.
B. Move the file to another folder.
C. Delete the file.
D. Rename the file.

Correct Answer: A

Explanation:

This question centers on Salesforce Files and how public links work. Public links are URLs generated to allow external users (who do not have Salesforce access) to view or download a file stored in Salesforce. These links are commonly used to share product brochures, proposals, datasheets, or marketing materials with people outside the organization.

In this scenario, Sarah shares a public link to a product brochure during a meeting. After the meeting, she wants to revoke access so that customers can no longer view or download the file using the same link.

The most effective and direct way to revoke access to the file through a shared public link is to delete the public link itself. Salesforce allows users to manage public links through the File's sharing settings. When a public link is deleted:

The file remains in Salesforce.
Any existing internal or private sharing settings are preserved.
The specific public link becomes inactive, and anyone who tries to use it will see an error or access-denied message.

Now, let’s analyze the incorrect options:

B. Move the file to another folder – Incorrect

Salesforce Files don’t function like traditional folder-based systems (e.g., Dropbox or Google Drive). Moving the file to another "folder" or library (if using Salesforce CRM Content or Files Home) does not invalidate a public link. The URL remains active and still points to the file, regardless of where it is moved within the system.

C. Delete the file – Incorrect

While deleting the file would make the public link stop working, this is an excessive and potentially harmful action. Sarah likely wants to keep the file for future use, perhaps with other customers or internal teams. Deleting the file permanently removes it from Salesforce and could affect others who rely on it.

D. Rename the file – Incorrect

Renaming the file has no effect on the public link. The link is based on the file’s internal ID or URL reference, not its display name. Users accessing the link will still be able to see the renamed file unless the link is explicitly revoked.

The most appropriate and least disruptive action for Sarah is to delete the public link. This immediately ensures that no one can use that specific link again while keeping the file intact within Salesforce for future use. This method aligns with Salesforce's best practices for securely managing external file sharing and maintaining control over content access.

Question 7
At Universal Containers, the organization-wide default (OWD) setting for the Account object is set to Private. A sales representative has been granted Create/Edit access to Opportunity records.

What level of access will this user have to the Account records that are linked to those Opportunities?

A. Read/Create/Edit access
B. No access
C. Read/Create access
D. Read-only access

Correct Answer: D

Explanation:

This question focuses on implicit sharing behavior in Salesforce, particularly the parent-child relationship between Opportunities and Accounts, and how organization-wide defaults (OWDs) affect data visibility.

Key Concepts:

OWD set to Private for Accounts means users cannot see Account records they don’t own unless additional sharing (e.g., role hierarchy, manual sharing, or sharing rules) is applied.
The Opportunity object has a child-to-parent relationship with the Account object.
When a user has access to an Opportunity, Salesforce automatically provides read-only access to the related parent Account record — this is part of implicit sharing.

In this case, the sales rep has Create/Edit access to Opportunity records. Based on standard Salesforce behavior:

The sales rep can create or edit Opportunities.
For each Opportunity they can access, Salesforce provides read-only access to the related Account — only to support contextual understanding, such as viewing account names, industry, or related contacts.

This read-only access allows the user to see key Account details necessary to work on the Opportunity but does not grant edit or create permissions on the Account itself. This preserves data security and ensures that access control rules are respected across different objects.

Let’s examine each option:

A. Read/Create/Edit access – Incorrect. Although the user can edit Opportunities, they do not receive edit rights to the Account just by accessing a child record.
B. No access – Incorrect. Salesforce automatically grants read-only access to a parent record (in this case, Account) if the user has access to the child (Opportunity).
C. Read/Create access – Incorrect. There is no "create" access to the Account granted through implicit sharing. Create access can only be given through permissions directly.
D. Read-only access – Correct. This aligns with Salesforce's implicit sharing rules: access to an Opportunity grants read-only access to the related Account, assuming no other sharing (like role hierarchy or manual sharing) is applied.

In Salesforce, when OWD for Accounts is Private, and a user gains access to an Opportunity, they get read-only access to the parent Account. This implicit sharing is a built-in Salesforce mechanism designed to balance usability and data protection. Thus, the correct answer is D. Read-only access.

Question 8
The Corporate Identity and Access Team at Universal Containers needs to conduct an audit of how users are configured in the Salesforce org.

Which two permissions should be provided to enable this team to perform their audit effectively? (Choose two.)

A. View All Users
B. View Setup and Configuration
C. View permission on the User object
D. View All Data

Correct Answer: A and B

Explanation:

Auditing user setup in Salesforce requires the ability to review not only the user records themselves but also configuration settings that determine how those users are granted access, roles, and permissions. To do this effectively and securely—without giving unnecessary access to business data—the appropriate least-privilege permissions should be selected.

A. View All Users – Correct

This permission allows users to view all User records in the system, regardless of the sharing model. It’s essential for any team that needs to audit who exists in the org, what roles or profiles they have, and how they’re configured.

Without this permission, the team could be limited by sharing rules and might not see all user records, which would defeat the purpose of an audit.

B. View Setup and Configuration – Correct

This permission allows access to the Setup menu and lets users view all org configuration, including:

Profiles
Permission Sets
Role hierarchy
Login policies
Password policies
Single Sign-On settings
Two-Factor Authentication policies

This is critical for auditing purposes because it provides visibility into how access is granted or restricted across the organization, which is at the core of identity and access management.

Together, View All Users and View Setup and Configuration provide a complete picture of both who the users are and how the system is configured to manage their access.

Now let’s consider the incorrect choices:

C. View permission on the User object – Incorrect

This is a standard object-level permission granted via profiles or permission sets and only allows the user to view User records that they have access to via sharing rules. This is not sufficient for an audit since it could exclude users who fall outside the default sharing scope. It also does not provide access to setup/configuration data.

D. View All Data – Incorrect

This is a broad and powerful permission that gives users access to all data in the system—including all records for standard and custom objects like Accounts, Opportunities, Contacts, etc.

This permission is not necessary for a user setup audit and actually goes beyond the scope of what's needed. Granting this could violate the principle of least privilege and expose sensitive business data unnecessarily.

To perform a targeted and secure audit of user setup, the Corporate Identity and Access Team should be given the ability to:

See all user accounts (View All Users)
View configuration and access control settings (View Setup and Configuration)

These two permissions provide everything needed for a comprehensive audit of identity and access, without overreaching into broader data access. Therefore, the correct answer is A and B.

Question 9
Universal Containers is rolling out Sales Cloud. In the last quarter, sales agents often collaborate and want to assign an assistant agent on Opportunity records. When the assistant agent is changed on a record, the system should automatically remove access from the old assistant and grant it to the new one.

What is the best solution to implement this behavior in Salesforce?

A. Use opportunity team and create an assistant field, use apex to share opportunities with the assistant agent.
B. Use apex sharing to share and unshare opportunities with the assistant agent.
C. Use sharing rule to share opportunities with the assistant agent.
D. Use share group to share opportunities with the assistant agent.

Correct Answer: B

Explanation:

This scenario is centered on dynamic and programmatic record access that changes based on a custom field value — specifically, a custom "Assistant Agent" field on the Opportunity. When this field is updated, the system must remove access from the previous assistant and grant it to the new one. The key challenge is that access must be automatically adjusted, in real-time, and tailored to a specific user.

Why B. Use Apex sharing is the correct answer:

Apex-managed sharing allows developers to programmatically control who has access to which records. It is ideal for situations where record-level access changes dynamically based on custom logic or field updates. In this case:

When the Assistant Agent field is updated, a trigger or flow can invoke Apex code.
The Apex code can remove the existing manual share (unshare) for the old assistant.
Then, it can create a new manual share for the newly assigned assistant.

This provides a precise, controlled, and automated sharing mechanism that is tailored to this exact business requirement.

Let’s evaluate the incorrect options:

A. Use Opportunity Team and create an assistant field, use Apex to share opportunities with the assistant agent – Incorrect

While Opportunity Teams can provide access to users and allow role designation (like Sales Engineer, Partner, etc.), the standard Opportunity Team functionality:

Doesn’t automatically handle the removal of the previous assistant.
Also, Opportunity Teams are not driven directly by custom fields.
You would still need Apex sharing logic to manage dynamic access, so the Opportunity Team adds unnecessary complexity.

If you already need Apex, using Opportunity Team offers no real benefit here.

C. Use sharing rule to share opportunities with the assistant agent – Incorrect

Sharing rules are based on criteria or roles/groups, and they cannot dynamically assign access to a specific user listed in a field. In other words:

You can’t target a sharing rule to a user populated in a custom field like "Assistant Agent".
Also, sharing rules don’t revoke access when the field value changes — so the previous assistant would still retain access.

Therefore, sharing rules are not a good fit for this dynamic, field-driven access model.

D. Use share group to share opportunities with the assistant agent – Incorrect

Share Groups are used with Groups and Communities to allow broader access based on group membership, especially for high-volume community users (HVCPs). They are not applicable to standard record-by-record user access needs in internal orgs. Also:

Share groups don’t dynamically update based on field values.
You can’t control access at the individual user level with them.

Hence, this approach wouldn’t meet the requirement.

The goal is to allow sales reps to designate an assistant agent on Opportunities and dynamically update access when this field changes. Only Apex-managed sharing gives the needed control, precision, and automation to add and revoke access on a user-by-user basis when the assistant changes. Therefore, the correct and optimum solution is B. Use apex sharing to share and unshare opportunities with the assistant agent.

Question 10
Universal Containers uses a partner community for 200 distributors. Each customer account is assigned to one distributor. The custom object "Delivery" has its organization-wide default (OWD) set to Private.

What is the best way for an architect to ensure that all users within a given distributor can access Delivery records for customers assigned to them?

A. Create a criteria-based sharing rule that shares delivery records matching a distributor to the Distributor role in the role hierarchy.
B. Create a criteria-based sharing rule that shares delivery records matching the Distributor to users of a Public Group created for the distributor.
C. Give ownership of the delivery record to a distributor user.
D. Create a Sharing Set for the Distributor Profile to grant access to the Delivery object.

Correct Answer: D

Explanation:

This question examines how to implement record-level sharing in a Partner Community (Experience Cloud site) for external users (distributors) in a way that scales efficiently across many partner users. Since the custom Delivery object has an OWD of Private, access to records must be explicitly granted. The goal is to ensure that all users from the same distributor can see delivery records for customers assigned to them.

Why D. Create a Sharing Set for the Distributor Profile to grant access to the Delivery object is correct:

Sharing Sets are specifically designed for Experience Cloud users (external users, such as partners and customers). They allow you to grant access to records based on the user’s associated account or contact, using simple matching criteria.

In this case:

Each customer account is linked to a distributor (i.e., the distributor is the account owner or linked via a custom field).
Each Delivery record is presumably linked to a customer account or contains a reference to the distributor.
A Sharing Set can be configured to match users with Delivery records based on a common field, such as the distributor's ID or the related account.

Advantages of Sharing Sets:

They are declarative (no code required).
Designed specifically for portal/community users.
All users with the same profile and account relationship get access to the matching records.
They support custom objects, including Delivery.

This is exactly what is needed — granting access to all users of a given distributor to all delivery records assigned to their customers.

Let’s examine why the other options are incorrect:

A. Create a criteria-based sharing rule for the Distributor role – Incorrect

External users (like partners in a Partner Community) can be assigned to roles in the partner role hierarchy, but criteria-based sharing rules target internal roles, not external partner roles. Also, sharing rules do not scale well when you need to manage access for hundreds of distributors unless you have a fixed number of roles set up per distributor.

This approach is not maintainable for a dynamic partner community setup.

B. Create a criteria-based sharing rule using Public Groups – Incorrect

While Public Groups can be used in sharing rules, they are designed for internal users. Adding community users to public groups is not supported directly, and maintaining a separate group for each of 200 distributors would be unscalable and manual. Sharing Sets are a better fit here.

C. Give ownership of the delivery record to a distributor user – Incorrect

While ownership grants full access to a record, assigning ownership to a single distributor user:

Doesn’t grant access to all users at that distributor.
Requires complex ownership transfer logic, which is inefficient.
Is not scalable or aligned with standard record-sharing best practices in communities.

Also, you lose the ability to track original ownership for business purposes.

The best and most scalable solution for granting access to Delivery records for all users at a distributor is to use a Sharing Set based on the Distributor Profile. This solution leverages community-sharing features built into Salesforce and avoids manual sharing or code-heavy implementations. It is designed specifically for scenarios like this, where external users need access to records linked to their account or contact relationships.