Salesforce-Platform-Sharing-and-Visibility-Architect Practice Test Questions

Explanation:

✅ Field-Level Security (FLS) is the right tool here because it controls whether a field is visible and whether it’s read-only for a given profile or permission set.
✅ By setting the field as read-only for Banking Reps, they can still search and see it, but they cannot edit it.
✅ Customer Support Reps have the field visible and editable, which matches the requirement.

Why not the other options?

A. Validation Rule:
Not a good solution here. Validation rules prevent record saving under certain conditions, but the field would still look editable to Banking Reps, and they’d get an error on save. This is a bad user experience and not the intended use of validation rules.

C. Search Layout + Page Layout:
→ Search layout controls which fields appear in search results, not editability.
→ Page layout controls field visibility, but does not enforce security—it can be bypassed through API or reports. For true control, FLS is required.

Salesforce Reference:
Field-Level Security
“Field-level security settings determine whether a user can see, edit, and delete the value for a particular field.”

✅ Final Answer: B

Explanation:

Universal Containers is running a pilot for a new application with a small group of sales reps, and they need to access the new app while having the legacy functionality hidden. Let’s break down the options to find the best solution, keeping it clear and detailed for someone learning Salesforce.

A. Clone the Sales Rep profile, adjust settings, and assign the pilot users the new profile.
This is the optimal solution. In Salesforce, profiles control a user’s access to apps, objects, fields, tabs, and more. Cloning the existing Sales Rep profile creates a new profile with the same permissions as a starting point.

The development team can then:
→ Enable access to the new application (e.g., make the app visible in the App Menu or grant permissions to related objects).
→ Hide the legacy functionality (e.g., set the old app or tabs to “Hidden” or revoke permissions for legacy objects).
→ Assign this new profile only to the pilot sales reps.

This approach is ideal because:
→ It isolates changes to the pilot group, leaving other sales reps’ access unchanged.
→ Profiles control app and tab visibility, which is key to hiding legacy functionality.
→ For a small pilot, creating a new profile is manageable and ensures a tailored experience.
→ It’s a clean setup for testing, as the pilot users operate in a controlled environment.

To implement this, the team would:
1. Go to Setup > Profiles and clone the Sales Rep profile, naming it something like “Sales Rep Pilot.”
2. In the new profile, enable the new application (e.g., under App Permissions or Tab Settings).
3. Remove access to the legacy functionality by setting the old app or tabs to “Hidden” or revoking permissions for related objects.
4. Update the pilot users’ profiles to the new “Sales Rep Pilot” profile in Setup > Users. This ensures the pilot users see only the new app and not the old functionality, while other sales reps continue using the original setup.

B. Revoke access to legacy functions in the Sales Rep profile and create a permission set for the new functionality.
This option is not ideal. Revoking access to legacy functionality in the Sales Rep profile would remove it for all sales reps using that profile, not just the pilot group. This is a problem because the question specifies only a small set of sales reps are in the pilot, and other reps still need the legacy functionality.
While a permission set could grant access to the new application (e.g., by giving permissions to new objects or features), it doesn’t address hiding the legacy functionality effectively. App and tab visibility are controlled by profiles, not permission sets, so this approach would require additional profile changes anyway. Modifying the main profile for a small pilot is disruptive and not targeted, making this option less suitable.

C. Create a permission set to grant access to the new functionality and hide the old functionality.
This option doesn’t fully work. Permission sets are designed to add permissions, such as access to objects, fields, or apps, but they cannot remove access or hide functionality like apps or tabs. For example, if the legacy functionality is an app or specific tabs, hiding them requires adjusting the profile’s App or Tab Settings.
A permission set could grant the pilot users access to the new application (e.g., by enabling object permissions or custom permissions), but it wouldn’t hide the legacy functionality. To achieve that, the team would still need to modify the profile or create a new one, making this option incomplete and less efficient than cloning a profile.

Why Option A is Optimal?
Cloning the Sales Rep profile is the best approach because it:
→ Creates a separate profile for the pilot users, ensuring no impact on other sales reps.
→ Allows precise control over app visibility, object permissions, and tab settings to enable the new application and hide the legacy functionality.
→ Is straightforward for a small group, as managing a new profile for a pilot is simple and aligns with Salesforce best practices.
→ Provides a clean, isolated environment for testing the new application, which is critical for a pilot.
→ If the pilot expands or becomes permanent, the team can decide whether to merge changes into the main profile or keep the new profile for specific users.

Additional Considerations:
Testing the Setup: After creating the new profile, the team should test it with a pilot user to ensure the new app is accessible and the legacy functionality is hidden (e.g., check the App Menu and tabs in the user interface).
Object and Field Permissions: If the new application involves custom objects or fields, the team must grant appropriate permissions (e.g., Read, Create, Edit) in the new profile.
Reverting Post-Pilot: If the pilot ends, the team can easily reassign pilot users back to the original Sales Rep profile, making this approach flexible.
Profile Management: Cloning a profile is a one-time setup, but the team should document the changes to track differences between the original and pilot profiles for future reference.

Reference:
Salesforce Help: Profiles Overview
Salesforce Help: Permission Sets Overview
Salesforce Help: Manage Apps and Tabs

Explanation:

This question tests the understanding of Pricebook sharing and its specific terminology, which is distinct from standard and custom object sharing. The business requirement is for sales agents to be able to see products and prices and create opportunities.

Why A is Correct: The Organization-Wide Default (OWD) for Pricebooks has three specific settings: None, Read Only, and Use. "Public Read-Only" is the label for the Read Only setting in the user interface.
⇒ A setting of Read Only (Public Read-Only) allows all users to view pricebooks, which is necessary to see products and prices.
⇒ Crucially, this setting also allows users to use those pricebooks when creating opportunities. When adding products to an opportunity, a user must select a pricebook. The "Use" permission is implicitly granted by the "Read Only" OWD setting for this purpose.

Why B is Incorrect: "View" is not a valid OWD setting for any object in Salesforce, including Pricebooks. The standard OWD settings are Private, Public Read Only, and Public Read/Write. This option is a distractor.

Why C is Incorrect: "Use" is a valid OWD setting for Pricebooks. However, setting the OWD to Use is overly permissive. It allows users to not only see and use pricebooks but also to create, edit, and delete them. The business requirement only states that sales agents need to access the existing products and prices, not to administer or modify the pricebooks themselves. Granting "Use" access violates the principle of least privilege.

Reference:
Salesforce Help: Control Access to Price Books - "The organization-wide default sharing settings for price books determine the baseline level of access that users have to price books. You can set the baseline to None, Read Only, or Use."
⇒ "Read Only—Users can view but not edit price books. Users can also use the price books to add products to opportunities."
⇒ "Use—Users can view, edit, and use price books. Users can also create new price books."

Explanation:

The System.runAs() method in Salesforce test classes is used to test code under the record sharing context of a specific user. It's a critical tool for ensuring your application's sharing and visibility rules are enforced correctly.

Correct Option:

A. Enforcement of a user's record sharing
By default, all Apex code, including test methods, runs in system mode. In system mode, the code ignores the permissions and record sharing settings of the current user. The System.runAs() method allows a developer to temporarily change the user context for a block of code within a test method. This makes the code respect the sharing rules, such as organization-wide defaults, sharing rules, and role hierarchy, of the user specified in the runAs() method. This is essential for writing realistic and robust tests that mimic how different users will interact with data in a production environment.
Example: If you have a sharing rule that grants a "Sales" public group read-only access to all "Account" records, you can use System.runAs() with a test user from that group to verify that they can indeed read the records but cannot update them.

Incorrect Options:

B. Enforcement of a user's Field Level Security: The runAs() method does not enforce Field Level Security (FLS) or object permissions. To test for FLS, you must use other methods, like WITH SECURITY_ENFORCED in SOQL queries or stripInaccessible methods from the System or Security classes. The code inside runAs() still operates in system mode concerning FLS and object permissions.

C. Enforcement of a user's permissions: Similar to FLS, runAs() does not enforce a user's object-level or field-level permissions. Its sole purpose is to test data access based on record sharing.

Reference:
For more information, consult the official Salesforce documentation on the System.runAs() method in the Apex Developer Guide: Using the runAs Method.

Explanation:

➡️ Platform Encryption is managed using the Encryption Policy in Salesforce Setup.
➡️ The architect must update the encryption policy to include the new fields (Billing Street, Billing City, Phone).
➡️ Once enabled, all new data entered into those fields is encrypted automatically.
➡️ However, existing data already stored in Salesforce is not retroactively encrypted. To encrypt existing values, Salesforce provides a process called a backfill. You need to contact Salesforce Support to perform this operation.

Why not the other options?

A. Classic Encryption: Wrong, because Classic Encryption only works for a small set of standard fields (like password fields, credit card fields). It’s not extensible like Shield. Plus, this org already uses Shield.

B. Use Encryption Policy and wait for an email: Wrong. Just enabling encryption in the policy won’t automatically encrypt existing values. The backfill process is required.

Salesforce Reference:
Encrypt Fields with Shield Platform Encryption
“When you enable encryption for a field, new data entered is automatically encrypted. To encrypt existing data, contact Salesforce to perform a backfill.”

✅ Final Answer: C

Explanation:

Universal Containers has set the Opportunity object’s organization-wide default (OWD) to Private, meaning records are only accessible to the record owner and users above them in the role hierarchy, unless sharing rules or other mechanisms grant additional access. They created a public group with certain sales engineers and a sharing rule to grant access to specific Opportunity records. Let’s analyze the impact of these settings and why each option is correct or incorrect, keeping it clear and detailed for someone learning Salesforce.

A. Sales engineers and their managers in the Role Hierarchy will also have access to these records.
This is correct. The sharing rule grants access to the sales engineers in the public group for the specified Opportunity records. Additionally, Salesforce’s role hierarchy automatically gives access to users above the record owner or those granted access via sharing rules. This means managers higher in the role hierarchy than the sales engineers in the public group will also have access to these Opportunities.
For example, if the sharing rule grants Read or Edit access to Opportunities for the public group, and a sales engineer in that group has a manager above them in the role hierarchy, the manager inherits that access. This is how Salesforce’s sharing model works with a Private OWD.

Why it’s the impact: The sharing rule extends access to the public group, and the role hierarchy extends it further to managers, making this the direct result of the described settings.

B. Subordinates of managers who have sales engineers in the public group will also have access to these records.
This is incorrect. In Salesforce, the role hierarchy grants access upward, not downward. Subordinates (users lower in the role hierarchy) do not automatically gain access to records that their managers can see unless explicitly granted through sharing rules, manual sharing, or other mechanisms. Since the sharing rule only applies to the public group (sales engineers), subordinates of managers not in the group won’t get access.
For example, if a manager has access because their subordinate (a sales engineer) is in the public group, the manager’s other subordinates lower in the hierarchy won’t inherit that access.

C. Other sales engineers who are in the same Role Hierarchy as the sales engineers of the public group will also have access to these records.
This is incorrect. The sharing rule grants access only to the sales engineers in the specified public group, not to all sales engineers in the same role or role hierarchy. Users in the same role or nearby roles don’t automatically share access unless they’re part of the same public group or another sharing rule applies. The role hierarchy only extends access upward to managers, not sideways to peers or others in similar roles.
For example, if Sales Engineer A is in the public group and gets access via the sharing rule, Sales Engineer B in the same role but not in the public group won’t get access.

Why Option A is the Impact?
The sharing rule gives the sales engineers in the public group access to the specified Opportunity records, despite the Private OWD. Because of Salesforce’s role hierarchy, managers above these sales engineers automatically inherit the same access (e.g., Read or Edit) to those records. This is the primary impact of the sharing settings described. Options B and C incorrectly suggest access extends to subordinates or peers, which doesn’t align with how sharing rules and the role hierarchy work.

Additional Details:
Private OWD: With Opportunities set to Private, only the record owner (e.g., the sales rep who created the Opportunity) and users above them in the role hierarchy have access by default. The sharing rule adds access for the public group.
Public Group: This is a collection of users (in this case, specific sales engineers) who can be granted access via sharing rules. It’s a flexible way to manage access for a group without relying on roles alone.
Sharing Rule: This rule likely specifies criteria (e.g., Opportunities in complex deals) and grants access (Read or Read/Write) to the public group. The role hierarchy then extends this access to managers above the group members.
Role Hierarchy: Managers higher in the hierarchy (e.g., Sales Manager over Sales Engineer) get the same or greater access to records their subordinates can see, including those shared via sharing rules.
Security Consideration: The team should ensure the sharing rule’s criteria are specific (e.g., only complex deals) to avoid over-sharing sensitive Opportunity data.

Reference:
Salesforce Help: Organization-Wide Defaults
Salesforce Help: Sharing Rules
Salesforce Help: Role Hierarchy

Explanation:

In Salesforce, when a single user owns too many records (more than ~10,000), it creates ownership skew (also called “data skew”).
When this happens, performance degrades because:
✅ Salesforce must recalculate sharing for a massive number of records every time ownership or sharing rules change.
✅ Lock contention issues can occur, especially when multiple transactions try to update records owned by the same user.
✅ Since each donations rep owns 50,000+ Accounts, this is clearly Account ownership data skew.

Why not the other options?

B. The donations reps’ access is wrong: Incorrect. Access model may affect usability but doesn’t directly cause system performance degradation at this scale.

C. Salesforce sharing recalculation kicked off: Partially true — recalculations do happen, but the root cause here is ownership data skew. That’s the recognized exam answer.

Salesforce Reference:
Make SOQL query selective
“When a large number of records are associated to a single owner or a single parent, performance issues such as record locking or sharing recalculations may occur. This is referred to as ownership skew or data skew.”

✅ Final Answer: A. There is an Account ownership data skew problem.

Explanation:

Universal Containers (UC) has a team that needs access to Invoice records (a custom object with a Private organization-wide default, or OWD). The OWD being Private means only the record owner and users above them in the role hierarchy have access, unless additional sharing rules or mechanisms like Apex managed sharing are used. The architect recommends Apex managed sharing to handle complex access rules for the fraud analysis team. Let’s evaluate each option to find the best recommendation for a developer implementing this solution, keeping it clear and detailed for someone learning Salesforce.

A. Use "Without Sharing" keyword to make sure record visibility will be considered.
This is incorrect. The without sharing keyword in Apex means the code runs in system mode, ignoring the user’s sharing rules and role hierarchy. This would allow the code to access all Invoice records, regardless of the Private OWD or other sharing settings, which could lead to over-sharing sensitive data.
In this case, UC needs to enforce complex sharing rules for the fraud analysis team, so Apex managed sharing should respect user permissions and only grant access to specific records as defined. Using without sharing would bypass these controls, making it the opposite of what’s needed.
For example, if the Apex code creates share records to give the fraud team access to certain Invoices, without sharing might expose records the team shouldn’t see, violating the Private OWD.

B. Use "With Sharing" keyword to enforce Field-Level Security.
This is incorrect. The with sharing keyword in Apex ensures the code respects the user’s sharing rules and role hierarchy, meaning it only accesses records the running user is allowed to see based on the OWD, sharing rules, or manual sharing. However, it does not enforce Field-Level Security (FLS). FLS is controlled separately using methods like Schema.sObjectType.

Explanation:

This question tests the understanding of cross-hierarchy sharing. The Role Hierarchy grants access downwards (managers see their subordinates' records), but it does not grant access across parallel branches of the hierarchy. A U.S. Sales Manager and a Canadian Sales Manager are in sibling roles; neither is above the other, so the hierarchy provides no access between them.

Why A is Correct: A sharing rule is the standard, declarative tool designed specifically for this purpose.
→ An owner-based sharing rule can be configured to share records owned by members of one role (e.g., the "Canadian Sales Manager" role) to another role or group (e.g., the "US Sales Manager" role).
→ The rule can be further refined with criteria (e.g., Segment = 'Enterprise') to ensure it only shares the specific accounts required by the business case. This meets the requirement precisely and efficiently.

Why B is Incorrect: This approach misunderstands how sharing works. You cannot grant access to a collection of records (the public group of accounts) via a permission set. Permission sets grant permissions to users (e.g., object permissions, field permissions, system permissions). They cannot be used to grant record-level access to a specific set of records. Record access is controlled through the sharing model (sharing rules, teams, manual share, etc.).

Why C is Incorrect: Flattening the role hierarchy by putting all managers in the same role is a poor architectural solution.
→ It destroys the logical organization of the hierarchy based on countries.
→ It would over-share dramatically. A U.S. Sales Manager would get access to all accounts owned by all Canadian sales users (reps and managers), not just the managers' accounts of the same segment. This violates data security and the principle of least privilege.
→ It is not a scalable solution; adding a new country would require constantly re-architecting the role hierarchy.

Reference:
Salesforce Help: Sharing Rules - "Use sharing rules to extend sharing access to users in public groups, roles, or territories. Sharing rules give additional users access to records they don’t own or can’t see normally."
Platform Sharing and Visibility Architect Exam Guide: This scenario directly addresses the objective "Given a scenario, design a sharing strategy that uses sharing rules." It highlights a classic limitation of the role hierarchy (no lateral sharing) and the use of sharing rules to solve it.

Explanation:

Summary:
To allow field consultants to capture images on their mobile devices while keeping the standard "Edit" page for desktop users, the architect should recommend using a Lightning Component to override the "Edit" action for the mobile form factor only. This approach minimizes customization and avoids disrupting the existing user experience for customer service representatives.

Correct Option:

A. Use Lightning Component as an override for "Edit" action on mobile view allowing image capture feature. No Change required for desktop users.
Salesforce Lightning Experience allows for different overrides for actions based on the form factor—specifically, a desktop view and a mobile view. By creating a custom Lightning Component that handles image capture and then setting it as an override for the mobile "Edit" action on the Case object, the architect can achieve the requirement without any changes to the desktop experience. The customer service representatives will continue to see and use the standard "Edit" page they are accustomed to. This method is the most direct and efficient way to meet the business and technical constraints of the problem.

Incorrect Options:

B. Use Lightning Component as an override for "Edit" action on lightning experience allowing image capture feature. Detect the form factor of the device and redirect the user to the default not-overridden view.
Reasoning: This approach is unnecessarily complex. Overriding the "Edit" action for the entire Lightning Experience and then trying to redirect desktop users back to the standard page introduces unnecessary code and potential points of failure. The platform already provides a simpler, built-in solution for handling form factor-specific overrides, making this approach less efficient and more difficult to maintain.

C. Create a separate button “Edit in Mobile”, which opens a custom lightning component that will allow field consultants to add an image. No change required for desktop users.
Reasoning: While this option would work, it is not the most user-friendly or elegant solution. It introduces a new button for a standard action ("Edit"), which can confuse users and lead to inconsistent user interface behavior. The goal is to provide a seamless experience, and overriding the existing "Edit" action is a cleaner solution that leverages the platform's native capabilities without adding clutter to the page layout.