SHARING-AND-VISIBILITY-ARCHITECT Practice Questions

Protected custom metadata types are specifically designed for this use case. When a custom metadata type's visibility is set to protected and it is included in a managed package, its records are not visible in the subscribing organization's user interface, including the Setup menu. This restriction applies even to users with the "View Setup and Configuration" permission. However, Apex code that is also part of the same managed package namespace can access the records and their fields. This mechanism allows developers to securely store secrets like encryption keys that are needed for application logic while keeping them completely hidden from all users in the subscriber org.

A: The "View Setup and Configuration" permission grants users the ability to see all custom metadata types and their records, overriding any profile-level restrictions. This would expose the key.

B: The protected visibility setting for custom metadata types is enforced through the namespace of a managed package. Unlocked packages do not provide the necessary encapsulation or namespace protection to hide the records.

1. Salesforce Help, Custom Metadata Types: "If a custom metadata type is in a managed package and has its visibility set to protected, the metadata type is directly accessible only by Apex code in the same managed package namespace. Subscriber orgs can’t see the type or its records in Setup."

2. ISVforce Guide, Second-Generation Managed Packages, Component Behavior in Packages (Page 10): This guide details how different components behave in packages. For protected components, it states, "The component is not visible in the subscriber’s org, but can be accessed from Apex code that is part of the managed package." This confirms that protected visibility is tied to managed packages.

3. Apex Developer Guide, Accessing Custom Metadata Type Records: "If a custom metadata type is protected and in a managed package, it’s accessible only through the code in that managed package." This section clarifies the programmatic access rules that fulfill the question's requirement.

The most efficient way to troubleshoot why a field is not visible is to use the "Field Accessibility" tool. This feature provides a consolidated view that shows a field's access level (e.g., Hidden, Visible, Read-Only) based on the combination of a user's profile, the record type, and the page layout. Since the page layout was confirmed to be unchanged, the issue is almost certainly related to Field-Level Security (FLS) for the users' profiles, which was likely modified during the deployment. The Field Accessibility tool directly diagnoses this by showing the resulting visibility from all controlling factors.

A. Run a Who Sees What report, filtering on Account.

This is not a standard Salesforce feature. Sharing tools and reports determine access to records, not the visibility of specific fields on a page.

B. Log in as a user and check several accounts to isolate the problem records.

This step confirms the user's experience but does not diagnose the root cause. It is a verification step, whereas the Field Accessibility tool is a diagnostic tool.

---

1. Salesforce Help - View and Edit Field Accessibility: "From the management settings for an object, you can view a grid that shows the access levels for all fields in that object for different profiles and record types... The field accessibility grid shows the access level for a field according to page layouts and record types." This document confirms that Field Accessibility is the designated tool for this exact purpose.

2. Salesforce Help - Field-Level Security: "Field-level security settings let you restrict what fields users can view and edit based on their profiles... Field-level security is the primary way to control field access." This establishes FLS as the likely cause when a page layout hasn't changed.

3. Salesforce Architects - Record-Level Security: "Before a user can see a record, they must have access to the object and the fields they want to see. Field-level security (FLS) controls which fields a user can see and edit on an object." This highlights that field visibility is a prerequisite for any data interaction and is controlled by FLS.

A large-scale reorganization of a complex role hierarchy and mass reassignment of record owners will trigger extensive sharing recalculations. This process is resource-intensive and can lead to significant performance degradation and record locking, disrupting business operations. The Deferred Sharing Recalculation feature is designed specifically for this scenario. It allows an administrator to suspend the automatic recalculations, perform all the necessary changes to roles and ownership, and then resume the recalculation process during a planned maintenance window. This minimizes the impact on users and ensures system stability during the transition.

A. Partition data using Divisions: Divisions are used to segment large data volumes to improve the performance of reports, list views, and searches, not to manage the impact of a sharing recalculation event.

B. Skinny table: Skinny tables are a performance feature that optimizes read-only operations, such as reports and list views, by creating a custom table with frequently used fields. They do not affect sharing calculation processes.

1. Salesforce Architects, Architect's Guide to Record-Level Security, Version 1.1, Page 31, "Managing Recalculations": "When you make changes to roles, territories, or public groups that are used in sharing rules, Salesforce recalculates sharing rules to add or remove access as needed... For large-scale recalculations, you can defer sharing calculations and then schedule the recalculation to run during your organization’s off-peak hours."

2. Salesforce Help, "Defer Sharing Calculations": "To improve performance, you can suspend and resume sharing calculations. Suspending calculations is useful before you create or modify roles, territories, groups, or sharing rules in a way that might initiate a large number of recalculations."

3. Salesforce Help, "What are Divisions?": "Divisions let you segment your organization's data into logical sections, making searches, reports, and list views more meaningful to users. Divisions are useful for organizations with extremely large amounts of data."

4. Salesforce Developer Documentation, "Query & Search Optimization Cheat Sheet": "A skinny table is a custom table in the Force.com platform that contains a subset of fields from a standard or custom base Salesforce object... Salesforce can use skinny tables to return results for reports, list views, and SOQL queries more quickly." This confirms skinny tables are for query performance, not sharing recalculation.

The most secure and optimal approach among the choices to prevent a user from editing a record is to control their object-level permissions. Removing the 'Edit' permission for the Work Order object from the Sales Representative's profile (or a permission set) fundamentally revokes their ability to modify any Work Order record, regardless of status or type. This aligns with the requirement that work orders cannot be changed by them. While this approach affects all work orders, it is the only option provided that enforces a true inability to edit at the data level, which is critical for a system-provisioned, unchangeable record.

A. Implement a sharing rule that changes access for all Work Orders to Read.

Sharing rules are used to grant wider access to records than the organization-wide defaults allow; they cannot be used to restrict access.

B. Change the Record Type/Page Layout assignment for Work Orders to Read Only.

A read-only page layout is a user interface control, not a security control. A user with the 'Edit' object permission can still modify the record through other means, such as the API or inline editing on a list view.

1. Object Permissions (Profiles and Permission Sets):

Salesforce Security Guide, "Control Access to Objects". This guide details that object permissions, controlled via profiles and permission sets, are the primary way to specify what users can do with records of a particular object (e.g., create, read, edit, delete). Removing the "Edit" permission is the direct method to prevent record modification.

2. Sharing Rules:

Salesforce Security Guide, "Sharing Rules". This section explicitly states, "Use sharing rules to extend sharing access to users in public groups, roles, or territories. Sharing rules give particular users greater access by making automatic exceptions to your organization-wide sharing settings." This confirms they are for extending, not restricting, access.

3. Page Layouts vs. Security:

Salesforce Help, "Page Layouts". The documentation describes page layouts as a tool to "control the layout and organization of buttons, fields, s-controls, Visualforce, custom links, and related lists on object record pages." It also notes you can make fields read-only, but this does not override the fundamental object permissions a user has.

Account Teams are the ideal solution as they are designed to grant a team of users record-level access to a specific Account and its related child records. By configuring an Account Team, an architect can define specific roles for each member (e.g., "Sales Associate") and precisely control their access levels for the Account, as well as its related Opportunities and Cases. To meet the requirements, the Sales Associate role on the Account Team would be configured with Read-Only access to Accounts, Read-Only access to Cases, and Private (no access) to Opportunities, all within a single feature.

B. Use Account teams and Case teams. No configuration required for the Opportunity object.

Case Teams grant access to a single Case, not all Cases related to an Account. Account Teams can already provide the required Case access, making Case Teams redundant and incorrect for this scenario.

C. Use Account teams and sharing rules to share cases with sales associates. No change required to the Opportunity object.

Sharing rules are criteria-based and grant broad access, which is not suitable for the requirement of granting access to specific users on specific accounts. Account Teams provide the necessary record-by-record access control.

1. Salesforce Help, "Account Teams": "An account team is a team of users who work together on an account... You can specify each team member’s role... and level of access to the account and its contacts, opportunities, and cases." This document confirms that Account Teams are the single feature designed to manage access to an account and its related standard objects.

2. Salesforce Help, "Set Up Account Teams": Under the section for setting up teams, the documentation details the ability to define team member access levels for Account, Contact, Opportunity, and Case. The available access levels for Opportunities and Cases are "Private," "Read-Only," or "Read/Write," directly enabling the solution described.

3. Salesforce Architects, "Record-Level Sharing: Under the Hood" (White Paper): This document explains various sharing mechanisms. It positions teams (Account, Opportunity) as a method for flexible, user-managed sharing on a record-by-record basis, contrasting them with the automated, criteria-based nature of Sharing Rules. This supports why Account Teams are appropriate and Sharing Rules are not.

When a file is posted to the Chatter feed of a specific record, its visibility is directly inherited from that record. The user who posts the file is the owner and always has access. In addition, any user who has access to the parent record (through ownership, role hierarchy, sharing rules, manual sharing, etc.) can also see the record's Chatter feed and, consequently, the file attached to it. The object's 'Private' organization-wide default restricts access to the record itself, but the principle of inherited sharing for the attached file remains the same for those who do have record access.

A. A shared Chatter post link is an explicit sharing action, not the default visibility that is established when the file is first posted to the record.

B. This is incorrect because the primary purpose of posting a file to a record's feed is to collaborate with other users who have access to that record.

1. Salesforce Help, Article: Who Can See My File?

Under the section "Where the File is Shared," the documentation states: "Files attached to records follow the sharing rules for the record. If you can view a record, you can view the files attached to it." This directly supports the principle that file visibility is inherited from the record it's attached to.

2. Salesforce Help, Article: Share Files with Records

This article explicitly states: "Attaching a file to a record makes it available to anyone with access to the record." This confirms that access to the record is the determining factor for file visibility in this context.

3. Salesforce Files Implementation Guide (PDF)

In the "Sharing and Visibility" section (page 10 of the Spring '16 version, a principle that remains constant), it details file sharing behavior: "When a file is attached to a record, it inherits the sharing settings of that record. Users with access to the record can view the file." This reinforces the concept of inherited sharing from the parent record.

The most effective and scalable solution is to override the standard "Edit" action with a single Lightning component. Within this component, the @salesforce/client/formFactor scoped module can be used to determine the user's device type. If the form factor is 'Large' (desktop), the component can use the lightning/navigation service to redirect the user to the standard edit page, ensuring their experience remains unchanged. If the form factor is 'Small' (mobile), the component will render the custom UI with the image capture functionality. This approach minimizes customization to a single component, promotes code reuse, and seamlessly handles the different user experiences without introducing new UI elements.

A. Use Lightning Component as an override for “Edit” action on mobile view allowing image capture feature. No Change required for desktop users.

This is incorrect because a standard action override in Lightning Experience applies to all form factors (desktop and mobile). It is not possible to create an override for only the mobile view.

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.

This is a less optimal solution. It adds a new UI element, which can be confusing for users, and requires separate page layout configurations, increasing administrative overhead and not fully leveraging standard actions.

1. Lightning Web Components Developer Guide - formFactor: The @salesforce/client/formFactor module provides information about the form factor of the hardware running the browser. This allows a component to adapt its rendering based on whether it's running on a desktop (Large), tablet (Medium), or phone (Small). This is the core mechanism for the solution in option B.

Source: Salesforce Lightning Web Components Developer Guide, Reference, Modules, @salesforce/client/formFactor.

2. Lightning Web Components Developer Guide - lightning/navigation: The lightning/navigation service is used to navigate to different pages, including standard record pages in edit mode. This is how the component in option B would redirect desktop users to the standard experience.

Source: Salesforce Lightning Web Components Developer Guide, Reference, lightning/navigation, "Navigate to a Record's Edit Page".

3. Salesforce Help - Override Standard Actions with a Lightning Component: Official documentation states that when you override a standard action, the override applies across both Lightning Experience on the desktop and the Salesforce mobile app. This directly invalidates the premise of option A.

Source: Salesforce Help, Salesforce Mobile App Developer Guide, "Override Standard Actions". The documentation notes, "When you override a standard action on an object, that override applies to both Lightning Experience and the Salesforce mobile app."

Apex classes, when invoked from a Lightning Web Component, run in system mode but default to a without sharing context. This means that by default, they do not enforce the running user's record-level sharing settings, potentially exposing data the user should not see. Therefore, a primary consideration for the development team is to explicitly enforce record visibility. This is achieved by declaring the Apex class with the with sharing or inherited sharing keyword, which ensures that all SOQL queries and DML operations respect the user's sharing rules and permissions.

B. Create test classes including runAs to test different users accessing the data.

This is a best practice for validating the sharing implementation, not the primary implementation consideration itself. The core task is to first write the code to enforce sharing (Option A).

C. Use isSharesble, isEditable, and isCreatable to enforce field permissions.

This option lists incorrect method names (isUpdateable, not isEditable) and misapplies isShareable. These methods check Field-Level Security (FLS) and object properties, not enforce record-level visibility.

1. Salesforce Apex Developer Guide, "Using the with sharing, without sharing, and inherited sharing Keywords":

"An Apex class with the @AuraEnabled annotation that is called from a Lightning component (Aura or LWC) defaults to without sharing." This statement confirms that developers must take explicit action to enforce sharing for LWC controllers.

2. Salesforce Secure Coding Guide, "Enforcing Sharing Rules":

"By default, Apex code runs in system context... The only exceptions to this rule are Apex code that is executed with the executeAnonymous call and Chatter in Apex. To enforce sharing rules, you must declare the class with the with sharing keyword." This highlights the developer's responsibility to enforce sharing.

3. Salesforce Apex Developer Guide, "Enforcing Object and Field Permissions":

This section details the use of Schema Describe methods like isAccessible(), isCreateable(), and isUpdateable() to verify a user's access to objects and fields (FLS), which is distinct from the record-level sharing enforced by the with sharing keyword. This clarifies the inaccuracy of option C.

4. Salesforce Apex Developer Guide, "Testing with runAs":

"The runAs method enables you to write test methods that change the user context to an existing user or a new user so that the user’s record sharing is enforced." This confirms that runAs is a testing tool used to verify sharing behavior.

The primary issue is a platform limitation. The affiliate's organizational structure requires a four-level role hierarchy (VP → Director → Manager → Rep) to manage record visibility. However, Salesforce Experience Cloud for Partners restricts the number of roles that can be created for any single partner account to a maximum of three. This technical constraint directly prevents the implementation of the required four-level hierarchy using the standard partner role functionality. The architect must devise an alternative solution, such as using groups or a custom sharing model, to accommodate the client's visibility needs.

A. The Channel Manager is an internal Salesforce user role for managing partners; the problem lies within the partner's own user role structure, not the internal management role.

C. Partner Community does support a role hierarchy for partner users. The problem is not the absence of this feature but the specific limitation on its depth (three levels per account).

1. Salesforce Help, Set Up Partner Roles: "You can create up to three roles for your partner accounts. The roles are created for all partner accounts that you enable. The roles appear on the partner account record, where the partner account owner can assign them to partner users." This directly confirms the three-role limit.

2. Salesforce Help, Who Sees What in Experience Cloud Sites, Partner Role Hierarchy: "Partner roles are a bit different from your internal Salesforce roles. Every partner account has its own role hierarchy... You can add up to three role levels for your partner accounts (for example, Partner User, Partner Manager, and Partner Executive)." This section explicitly details the functionality and its three-level limitation.

3. Salesforce Architects, Record-Level Sharing for External Users: "Each partner account has its own role hierarchy with up to three levels. When you enable the first external user on a partner account, Salesforce creates this three-level role hierarchy." This architect-level documentation reinforces the platform constraint.

Partner Super User access is the most scalable and appropriate solution for this requirement. This feature is specifically designed to grant users in a partner account (like a manager) access to data owned by other users who are in the same role or a role below them within the same partner account's role hierarchy. It avoids the creation of numerous sharing rules, which would be unmanageable across 200 distributors. You enable the feature once for the community and then grant "Super User" access to the specific manager-level users, allowing them to see all relevant case and container records for their subordinates at their specific distributorship.

A. Create an ownership based sharing rule.

This is not scalable. To maintain data segregation, each of the 200 distributors would require its own set of roles and a corresponding sharing rule, leading to significant administrative overhead.

C. Create sharing sets.

Sharing sets grant access to records based on the user's account affiliation, but they typically grant this access to all users with a specific profile, not just to users in a managerial role.

---

1. Correct Answer (B): Salesforce Help Documentation, "Give Super User Access to Your Partners and Customers".

Quote/Concept: "Partner super users can access more data and user records than other partner users. Super users have access to data owned by other partner users who have the same role or a role below them in the account role hierarchy. Partner super user access applies to cases, leads, custom objects, and opportunities." This directly supports using Super User access for hierarchical visibility within a single partner account.

2. Incorrect Answer (A): Salesforce Help Documentation, "Sharing Rules".

Quote/Concept: "Sharing rules are used to extend sharing access to users in public groups, roles, or territories." The documentation illustrates that rules are configured to share records from a source group to a target group. For 200 distinct partner accounts, this would necessitate 200 separate role hierarchies and 200 corresponding sharing rules to maintain data silos, which is not a scalable architecture.

3. Incorrect Answer (C): Salesforce Help Documentation, "Control Access Using Sharing Sets".

Quote/Concept: "Use a sharing set to grant high-volume community or portal users access to any record associated with an account or contact that matches the user’s account or contact... You configure sharing sets to grant access to users based on their profile." This confirms that sharing sets grant access based on profile and account/contact lookup, not on a user's specific role (e.g., manager) within the account hierarchy.