Free Practice Questions for Salesforce Sharing-and-Visibility-Architect Exam

To allow presenters to edit details on a private custom object (Presentation) based on their relationship through a junction object, Apex Managed Sharing is the best solution:

Option A: Permission sets provide global permissions, not record-specific access based on a junction object.

Option B: Adding users to a Sales Team applies to opportunities, not custom objects like Presentation.

Option C (Correct): Apex Managed Sharing allows the creation of precise, record-specific sharing rules that dynamically grant access based on junction object relationships. This approach ensures presenters can edit only their related Presentation records.

In Apex, the IsUpdateable() method of the Schema.DescribeFieldResult class checks if the current user has permission to update a specific field. Using this method ensures that the Apex class respects Field-Level Security (FLS) for all profiles, avoiding unauthorized updates.

Option A: Adding the "With Sharing" keyword enforces record-sharing rules but does not enforce field-level security.

Option B: Placing the code in an inner class with "With Sharing" does not address the field-level security issue.

Option C (Correct): Using IsUpdateable() ensures field permissions are honored programmatically, preventing updates to read-only fields.

When performing large-scale changes, such as reorganizing roles or reassigning ownership, recalculating sharing rules can be resource-intensive and may affect performance. Deferred Sharing Recalculation allows Salesforce admins to temporarily pause sharing rule calculations during bulk operations. This ensures that the reorganization completes efficiently, and the sharing recalculations are processed after the changes are made.

Option A: Partitioning data using Divisions helps segment data logically but does not address the specific need to optimize sharing recalculations.

Option B: Skinny tables improve query performance for specific data structures but do not mitigate recalculation delays.

Option C (Correct): Deferred Sharing Recalculation ensures minimal performance impact during bulk ownership changes or Role Hierarchy updates.

Content Delivery is a Salesforce feature designed for secure file sharing. When creating a content delivery, users can require a password for access, ensuring compliance with the CISO's requirement.

Option A: While AppExchange products could provide similar functionality, Salesforce’s native Content Delivery feature already meets the requirement without additional cost or complexity.

Option B (Correct): Content Delivery allows the sharing of files via secure, password-protected links.

Option C: Setting up an Experience Cloud site is an excessive and unnecessary solution for this simple file-sharing requirement.

Sharing List Views with Public Groups:

Public Groups provide a flexible way to share list views with multiple users. Sharing with a Public Group allows administrators to manage access efficiently for specific user groups, such as executives specializing in problematic deals.

Why Option C is Correct:

By creating a Public Group for the specialized executives and sharing the list views with this group, UC ensures that only the intended users can access the views, fulfilling the requirement.

Why Others Are Incorrect:

Option A: Sharing with roles might include unintended users if the role contains non-specialized executives.

Option B: Sharing with individual users is not scalable and would require frequent manual updates.

For more information, refer to Salesforce documentation on Public Groups and List Views: https://help.salesforce.com/

The Opportunity Team feature allows collaboration by granting specific permissions (Read, Read/Write, or access defined by roles) to users added to an opportunity. In this scenario, the sales rep has Read/Write permissions, which means they can:

View and update the opportunity, including editing fields like the opportunity stage.

They cannot perform administrative tasks like transferring ownership or managing the opportunity team unless explicitly granted "Full Access" or assigned additional roles that permit these actions.

Option A (Correct): Updating the opportunity stage is allowed as part of Read/Write access.

Option B: Replacing the opportunity owner requires administrative privileges, which are not included in standard Read/Write permissions.

Option C: Adding or removing members in the opportunity team requires "Full Access," which exceeds Read/Write permissions.

For custom objects, Salesforce allows disabling the Access Using Hierarchies option. By setting the Organization-Wide Default (OWD) to Private and unchecking Access Using Hierarchies, you ensure that records are only accessible to the owner and explicitly granted users. This prevents the owner’s manager or anyone higher in the role hierarchy from automatically gaining access.

Option A: Removing CRUD permissions from profiles would block all access to the object for managers, which may not align with business requirements.

Option B: Apex sharing is unnecessary when the problem can be solved declaratively by adjusting the OWD and hierarchy settings.

Option C (Correct): Setting OWD to Private and disabling Access Using Hierarchies is the most straightforward solution for restricting access to managers.

Field-Level Security (FLS) is the most secure and efficient method to restrict visibility of sensitive fields like the VIP Flag to specific user groups or profiles. FLS is applied at the field level, ensuring that users who lack permission cannot view, edit, or access the field, regardless of the sharing or page layout configurations.

Option A: Changing the field type to a picklist and using record types unnecessarily complicates the solution. Record types are typically used for different business processes, not for field-level security.

Option B: Using page layouts restricts visibility on the UI but doesn’t secure the field from API or report-level access. Users with access to the object could still retrieve the field's data.

Option C: Setting FLS ensures that the field is hidden everywhere it appears (e.g., UI, reports, APIs) for all profiles except the Private Banking Rep Profile. This is the most effective and Salesforce-recommended method for sensitive data control.

Step 1: Remove Read permission on the Driver profile for the Feedback object to ensure that drivers cannot see their feedback records. Object-level permissions control whether users can see, edit, or delete records.

Step 2: Automatically transfer ownership of feedback to the driver's manager upon submission. This ensures that managers own the feedback records, providing a natural ownership hierarchy for data visibility.

Step 3: Leverage the Role Hierarchy to grant access to the manager's superiors, ensuring that visibility extends appropriately up the organizational structure.

Why Option B is Correct: It directly aligns with the requirement that managers (not drivers) need access, and feedback visibility should follow the Role Hierarchy even after a driver’s manager changes.

Why Others Are Incorrect:

Option A: Sharing rules would be redundant in this case since the Role Hierarchy already provides the required access.

Option C: Allowing drivers to retain ownership conflicts with the requirement that they should not have visibility.

For detailed references, see Salesforce Role Hierarchies and Ownership documentation: https://help.salesforce.com/