certified-sharing-and-visibility-architect Sample Questions & Answers

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.

This is the most scalable and declarative solution. Customer Community licenses are ideal for high-volume Patient users. A Sharing Set for their profile can easily grant them access to their own Medical Records by mapping User.ContactId = Medical_Record__c.Contact__c. Customer Community Plus licenses are suitable for Physicians who need more advanced sharing. A second Sharing Set can be created for the Physician profile that grants access to Medical Records by mapping the User.Clinic__c = Contact.Clinic__c relationship, effectively giving them access to all records of patients treated at their clinic. This avoids Apex and scales well for high volumes.

Salesforce Shield Event Monitoring is the only feature that can provide this level of detail. It captures granular user activity events, including the 'Report Export' and 'Report Run' events. These event log files can be analyzed to see which users ran which reports, providing the necessary evidence for auditors. The Setup Audit Trail tracks metadata changes, Login History tracks logins, and Field History Tracking tracks data value changes, none of which capture report execution details.

The 'Defer Sharing Calculations' feature is designed specifically for this scenario. When enabled, Salesforce does not immediately initiate a full sharing rule recalculation when roles, territories, or groups are modified. Instead, an administrator can suspend the calculations, make all necessary changes, and then resume and run the recalculation process during a planned maintenance window (e.g., overnight). This prevents performance degradation during business hours.

Even though there is a lookup relationship, the Project__c object's OWD is Public Read-Only. This setting is the baseline and grants all users Read-Only access to all Project__c records, regardless of their relationship to the parent Account. Implicit sharing from parent to child only applies when the child's OWD is more restrictive (e.g., Private or Controlled by Parent). In this case, the more permissive OWD on the child object takes precedence.

A Permission Set is the correct tool to grant additional permissions (like access to specific Apex classes and custom settings) to a user without changing their profile. To make the solution robust and declarative, a Custom Permission should be created to represent the abstract concept of 'Can Run Dupe Job'. This Custom Permission can then be included in the Permission Set. The Apex code can then check for this Custom Permission (FeatureManagement.checkPermission('Can_Run_Dupe_Job')) before executing, decoupling the logic from specific profiles or users.