Pass the Salesforce Architect Exams Sharing-and-Visibility-Architect Questions and answers with CertsForce

Master-Detail Relationship Behavior:

In a master-detail relationship, access to child records (Invoice) is determined by access to the parent record (Account).

Since the AR team does not have access to accounts, they cannot see invoices related to those accounts.

Why Option B is Correct:

To resolve this issue, a sharing rule must be created to share accounts with the AR team. This will cascade access to the related Invoice records due to the master-detail relationship.

Why Others Are Incorrect:

Option A: The AR team has object-level access to Invoice but still cannot see the records due to account-level sharing restrictions.

Option C: Sharing rules for invoices are not applicable because access to invoices is governed by account-level access in a master-detail relationship.

For detailed information, refer to Salesforce Sharing and Object Relationships documentation: https://help.salesforce.com/

OWD Settings and Access Control:

When the OWD for Contacts is "Controlled by Parent," access to the Contact is determined by access to the related Account.

Why Option C is Correct:

Service reps have "View All" permission on Cases, granting them access to related Accounts. Since Contacts are controlled by the parent Account, service reps also gain access to relevant Contacts.

Why Others Are Incorrect:

Option A: Service reps can access Accounts related to Cases they can view, even if the OWD is Private.

Option B: Contacts controlled by the parent are accessible as long as the parent Account is accessible.

For detailed guidance, see Salesforce documentation on OWD and Controlled by Parent: https://help.salesforce.com/

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.

Default Account Teams allow users to predefine a set of supporting internal users (e.g., legal, engineering, finance) who need access to customer records. The team members are automatically granted the specified access whenever an Account is created or updated, reducing the manual effort required by sales reps.

Option A: A criteria-based sharing rule might grant access to a larger group but does not provide the flexibility and precision of Account Teams.

Option C: Assigning View All Data via a permission set gives overly broad access and violates the principle of least privilege.

If a field disappears from the Account page, the likely cause is that its visibility has been restricted through Field-Level Security (FLS) or a related profile/permission set update. Using Field Accessibility in Object Manager allows the admin to review and troubleshoot field permissions across profiles.

Option A: A "Who Sees What" report is used for record visibility, not field visibility.

Option B: Logging in as a user might help confirm the issue but doesn’t provide insights into why the field is missing.

Option C (Correct): Field Accessibility offers a comprehensive view of field-level security for troubleshooting.

The Public Group and Sharing Rule approach grants access to specified users and, by default, extends access to their managers in the Role Hierarchy. Here’s how the settings interact:

Public Group: The group includes a specific set of sales engineers.

Sharing Rule: It grants access to opportunities for the Public Group. This rule respects the existing Role Hierarchy.

Role Hierarchy: In Salesforce, managers in the hierarchy automatically gain access to records their subordinates can access, ensuring seamless visibility for leadership.

Option A (Correct): Managers of sales engineers in the Role Hierarchy will gain access because sharing rules honor the Role Hierarchy.

Option B: Subordinates of managers will not gain access because sharing rules do not propagate access downward in the hierarchy.

Option C: Other sales engineers outside the specified Public Group will not gain access unless explicitly included in the sharing rule.

To enable community users to collaborate on Opportunities, they must have access to the Opportunity object, which is included in the Partner Community license. This license type is specifically designed for partners and provides access to features like Opportunities, Campaigns, Leads, and other standard objects required for collaborative sales processes.

Option A: Customer Community Plus licenses do not grant access to Opportunities, as they are primarily focused on external customer engagement without sales collaboration.

Option B: Customer Community licenses are limited to basic interactions like viewing and updating cases or accessing content, and they exclude access to Opportunities.

Option C (Correct): Partner Community licenses include access to Opportunities, making them the appropriate choice for this use case.

Public Groups are the most flexible method to grant access to an unrelated group of users. Public Groups can include individual users, roles, and roles with subordinates, allowing for granular control over which users gain access to records. Sharing sets and role hierarchies are less suitable because they rely on predefined relationships, such as account ownership or role-based hierarchies, which may not apply to unrelated users. By leveraging Public Groups, administrators can define and manage record-level sharing without requiring additional custom logic. (help.salesforce.com)

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/

When developing Lightning Web Components (LWC) that interact with Apex classes for business logic, it's crucial to consider how Apex's execution context affects data access and security. By default, Apex operates in system mode, which means it runs with elevated privileges, ignoring the current user's permissions and sharing rules. This behavior can inadvertently expose or allow manipulation of data that the user shouldn't access. Therefore, developers must explicitly enforce record visibility and sharing rules within their Apex code to ensure data security and compliance with the organization's sharing model. This can be achieved by declaring classes with the with sharing keyword to enforce sharing rules or by implementing explicit permission checks within the code.

Option B suggests using runAs in test classes to simulate different user contexts. While runAs is valuable for testing user-specific sharing and permissions, it doesn't directly address the need to enforce record visibility in the actual business logic.

Option C mentions using isShareable, isEditable, and isCreatable to enforce field permissions. However, these methods are not standard in Apex for enforcing field-level security. Instead, developers should use methods like isAccessible, isCreateable, and isUpdateable from the Schema.DescribeFieldResult class to check field-level permissions.

In summary, since Apex runs in system mode by default, it's imperative for the development team to enforce record visibility explicitly to ensure that users can only access data they are permitted to see.