Salesforce Certified Platform Sharing and Visibility Architect Free Sample Questions

In Large Data Volume (LDV) scenarios involving Enterprise Territory Management, the complexity and efficiency of assignment rules are the most common cause of performance issues. Simplifying rules by using indexed fields (like Record IDs, Owner IDs, custom fields marked as External ID) and reducing the total number of rules will have the most significant impact on performance. Replacing the standard feature with a custom solution is a massive undertaking and should be a last resort. Increasing batch size could exacerbate timeouts, and while archiving data is a valid LDV strategy, optimizing the active rule set is the most direct solution to the described problem.

The Security.stripInaccessible() method is the most efficient and recommended way to enforce FLS for read access on a list of SObjects. It removes fields from the SObject records that the user cannot access, preventing them from being displayed on the Visualforce page. While looping with isAccessible() works, it is far more verbose and less performant for multiple records and fields. WITH SECURITY_ENFORCED enforces sharing rules and FLS at the query level, but the requirement is to run the initial query without sharing. Checking object permissions with isReadable() doesn't solve the field-level requirement.

A Sharing Set is used to grant high-volume community users (like Partner Community users) access to records that are associated with their account or contact record. This perfectly fits the requirement for Cases. For the Opportunity requirement, a criteria-based sharing rule can be created to share Opportunity records with a specific Partner Role or Group when the custom lookup field contains a user from that partner account. Share Groups are for sharing records owned by high-volume users, not for sharing records with them.

The 'Sharing' button on a record detail page (in Classic, or the 'Sharing Hierarchy' action in Lightning) is the most direct tool for troubleshooting access to a single record. It provides a detailed list of every user, group, and role that has access and, crucially, the 'Reason' for that access (e.g., 'Manual Share', 'Owner', 'Sharing Rule: [Rule Name]'). This immediately pinpoints the exact mechanism. 'Login As' confirms access but doesn't explain the reason. Health Check is for org-wide issues, not specific records. The Setup Audit Trail shows changes but not the current state of access.

This statement is true. The dashboard's running user determines the data context for all viewers of that dashboard. If the running user is a System Administrator (who can see all data), the dashboard components will display aggregated data from all records, effectively bypassing the viewing user's personal record-level security. This is a critical security consideration when designing dashboards.

This is a classic example of Account Data Skew (or parent-child skew). When an operation like an ownership change occurs on a parent record with a very large number of child records (typically >10,000), Salesforce must lock the parent record while it updates all child records to reflect the change. This long-held lock leads to contention, resulting in UNABLE_TO_LOCK_ROW errors for any other transaction trying to access that parent record or its children. The solution often involves re-architecting the data model to avoid such heavily skewed parent-child relationships.

Salesforce record access is built upon a foundation of opening up access progressively. It starts with the most restrictive setting, the Organization-Wide Defaults (OWD). Then, the Role Hierarchy opens up vertical access. After that, Sharing Rules (both criteria-based and ownership-based) open up lateral access. Finally, Manual Sharing and Team Sharing allow for flexible, ad-hoc access on individual records. Object permissions (Profiles/Permission Sets) are checked first to see if a user can see the object at all, but for record-level access, this is the correct sequence.

Enterprise Territory Management 2.0 is specifically designed for complex, matrix-based sharing models where a single record (like an Account) can belong to multiple territories, and users can be assigned to multiple territories. This directly addresses the need for users to have access based on different product lines for the same account. Furthermore, Territory Management integrates with forecasting, fulfilling the second requirement. While sharing rules or Account Teams could partially solve this, they become unmanageable at scale and do not offer the integrated forecasting capabilities of ETM 2.0.

To meet the requirement of querying all contacts, the class must run in system context, which is achieved with the without sharing keyword. To ensure FLS is respected during the update, Security.stripInaccessible() should be used on the SObject records before the DML operation. This method will remove any fields from the records that the running user does not have update access to, preventing the DML from failing or writing to unauthorized fields. WITH SECURITY_ENFORCED would restrict the initial query, violating the first requirement.

This approach meets all requirements. Setting the running user to someone with full visibility (like a VP of Sales or an integration user) ensures the dashboard shows company-wide data. Storing the source reports in a private folder that the executives cannot access prevents them from clicking through to see the detailed record data. This allows them to see the aggregated view on the dashboard without granting them underlying record access. Granting 'View All Data' is excessive, and running as the viewer would restrict the data they see.