A custom ServiceFeedback object is used to collect partner feedback.
ServiceFeedback records should be available to all internal employees. The organizationwide
default (OWD) is set to Private for external users so partners cannot see feedback
from other partner users.
How should the architect give access to all internal employees?
A. Create an owner based sharing rule for all Service Feedback records owned by partners.
B. Ensure all the internal users are above the partners in the Role Hierarchy.
C. Set the OWD for Internal Users to Public Read-Only.
Explanation:
To ensure all internal employees can view ServiceFeedback records while restricting partners, the Organization-Wide Default (OWD) must be configured separately for internal and external users. Since OWD for external users is already Private, setting the OWD for internal users to Public Read-Only is the most scalable solution. This grants all employees read access without manual sharing rules or role hierarchy adjustments.
Why Not A or B?
Option A (Owner-based sharing rule) only shares records owned by partners, leaving other records inaccessible unless manually shared.
Option B (Role Hierarchy) is irrelevant because internal employees don’t need hierarchical relationships to access partner-owned records. Role Hierarchy primarily controls access for records owned by users below in the hierarchy, not lateral or external ownership.
Key Consideration:
Salesforce allows different OWD settings for internal vs. external users via profiles or permission sets. Public Read-Only for internal users ensures compliance while minimizing administrative overhead.
Universal Containers has implemented Customer Community with Customer Community
Plus licenses for its distributors. Some distributors requested granting specific community
users (agents) to view cases submitted by other agentsof the same distributor.
Which feature only supports these requirements?
A. Permission set to grant community admin permission
B. Delegate external user
C. Partner super user
Explanation:
The Partner Super User feature is designed for this exact scenario. It allows designated users (e.g., partner managers or agents) to view records owned by other users within the same account (distributor). This is scalable and requires no manual sharing adjustments.
Why Not A or B?
Option A (Permission set for admin access) grants excessive privileges, risking data exposure.
Option B (Delegate external user) is temporary and impractical for ongoing collaboration.
How It Works:
When enabled, Partner Super Users automatically inherit Read/Edit access to records owned by users under the same account. This aligns with the requirement for agents to view peer cases without custom sharing rules.
Universal Containers (UC) delivers training in 500 different regions. The UC operations
users team manages course setup, scheduling, and trainer setup. The team members work
at a regional level and report to an operations manager. The operations manager
requested access to edit ALLscheduled courses owned by theoperation users team.
How should this be achieved?
A. The operations manager will get access to the scheduled courses by creating an ownership-based sharing rule and share the scheduled courses with the operations manager.
B. The operations manager will get access to the scheduled courses owned by the operations users team defined in the Role Hierarchy.
C. The operations manager will get access to the scheduled courses by creating a public group, and add the operations manager and the operations users team to the public group.
Explanation:
Since the operations manager needs access to ALL scheduled courses owned by the operations users team, creating an ownership-based sharing rule is the best approach. Sharing rules can be set based on record ownership and shared with specific users or roles, such as the operations manager. The Role Hierarchy option (B) works only if the operations manager is positioned above the operations users in the hierarchy and the object’s sharing is set to grant access up the hierarchy, but it might not cover all cases if the manager is lateral or outside the role path. Option C is less straightforward and doesn’t provide edit access unless combined with other sharing mechanisms.
Universal Containers (UC) has 200 distributors that use Partner Community licenses.
Partners cannot see each other's data, but UC is also trying to give morevisibility to data for
certain individuals at a distributor.
Which scalable option give users in the partner manager role access to all case and
container records for partner users at the same distributor?
A. Create an ownership based sharing rule.
B. Give Super User permission to the individual partner manager users.
C. Create sharing sets.
Explanation:
The "Super User" permission on partner licenses grants users enhanced visibility into their partner account's data, including access to records owned by other partner users in the same account (distributor). This is the most scalable way to give partner managers visibility without creating multiple sharing rules or complex sharing sets. Sharing sets are typically used for external users with Customer Community licenses and not for Partner Community licenses. Ownership-based sharing rules may not scale well with 200 distributors and could be difficult to maintain.
What should an architect recommend to make sure that users that gained access to a custom object record through Apex managed sharing do not lose access to it when its owner is changed?
A. Use "With Sharing” keyword to make sure record visibility will beconsidered.
B. Create a new record in _Share object with RowCause “Manual”.
C. Create aspecific Apex Sharing Reason for the custom object.
Explanation:
When implementing Apex managed sharing on custom objects, it is important to create a custom sharing reason (Apex Sharing Reason). This enables precise control over the share records created by Apex, and these share records are retained even if the record owner changes. Without a specific Apex Sharing Reason, the sharing records may be deleted or not correctly associated, causing users to lose access. The "With Sharing" keyword controls execution context but doesn't manage sharing persistence. Using RowCause "Manual" is for manual shares via the UI and doesn’t apply directly to Apex sharing.
Which method should be used to grant an unrelated group of users accessto a set of records?
A. Role Hierarchy
B. Sharing Sects
C. Public Groups
Explanation:
Sharing Sets dynamically grant access to unrelated users (e.g., community users) based on criteria like record ownership or attributes.
Use Case:
Ideal for ad-hoc groups needing access to specific records (e.g., projects, cases).
Alternatives Rejected:
Role Hierarchy (A): Requires parent-child relationships.
Public Groups (C): Static; impractical for dynamic record sets.
In order to allow community users to collaborate on Opportunities, which license type must the users be given?
A. Customer CommunityPlus
B. Customer Community
C. Partner Community
Explanation:
Partner Community licenses are designed to allow external users to collaborate on standard CRM objects like Opportunities, Leads, and Campaigns. Customer Community and Customer Community Plus licenses have limited access to standard objects and do not support full Opportunity collaboration. Partner Community licenses provide the necessary sharing and access capabilities for sales collaboration on Opportunities.
Universal Containers requested to leverage Lightning Web Components (LWC) to improve
support reps’ user experience. LWC will be used as view layer, and Apex classes will have
the business logic.
Which attention points should the development team consider when implementing this
solution?
A. Once that Apex runs on system mode, the development team needs to enforce record visibility.
B. Create test classes including runAs to test different users accessing the data.
C. Use isSharesble, isEditable, and isCreatable to enforce field permissions.
Explanation:
Apex runs in system context by default, which means it bypasses user sharing and permissions unless explicitly enforced. To ensure data security and respect the sharing model, developers must enforce record visibility within Apex. While testing with runAs is good practice, the key point is enforcing record-level security in Apex. isShareable, isEditable, and isCreatable are methods related to object and field permissions but not directly for enforcing record-level sharing inside Apex.
A junior account manager owns an account and creates a new opportunity to manage a
complex deal. She needs the help of the product specialist and solution engineer. Given
the size of this deal, she knows the account is likely to be reassigned to a senior account
manager in the near future.
What is the optimal way for the junior account manager to share the opportunity, given the
private sharing model?
A. Manual share on the opportunity
B. Manual share on the account
C. Opportunity Team
Explanation:
Opportunity Teams provide a scalable, flexible way to share access to opportunities with multiple users without changing record ownership. It allows the junior account manager to add product specialists and solution engineers with appropriate access levels to collaborate on the deal. Manual sharing on the opportunity is also possible but less manageable. Manual sharing on the account is not necessary and would grant broader access. Opportunity Teams also make transition easier when the account ownership changes.
The sales managers at Universal Containers requested their teams to define each user's
role on their accounts in order to provide an easy way to establish accountability and
collaboration. Sales managers also requested that sales associatesshould only get the
following permissions: 1. Read access to the accounts. 2. Read access to cases related to
the accounts. 3. No access to deals related to the accounts.
The sales associates may be granted access to opportunities when needed.
Assuming the overall sharing model of the organization is Private and no sharing rules
are configured on the Account object, how should an architect achieve these
requirements?
A. Use Account teams to define access to accounts as well as opportunities and cases related to accounts.
B. Use Account teams and Case teams. No configuration required for the Opportunity object.
C. Use Account teams and sharing rules to share cases with sales associates. No change required to the Opportunity object.
Explanation:
Account Teams provide:
Read access to accounts.
Read access to related cases (via Account Team sharing settings).
No access to opportunities unless explicitly added.
Scalability:
Teams are dynamic—no need for sharing rules.
A banking company wants their customers Date of Birth Field searchable by Banking Reps,
but only editable by Customer Support Reps.
Which approach is recommended to meet this requirement?
A. Create 2 Validation rule in the Data of Birth field so the rule returns true only when user.profilename matches Customer Support Rep.
B. Set the Field Level Security for the Date of Birth field to be Visible to Customer Support Rep Profile, and set the Date of Birth field Visible and Readonly to Banking Rep profile.
C. Add Date of Birth field to the Search layout of the Contact Object. Modify the Page layout assigned to Customer Support Rep and add Date of Birth field as Required.
Explanation:
Field Level Security (FLS) controls whether a field is visible or editable for users based on their profile or permission sets. To meet the requirement, the field must be searchable and visible to Banking Reps but not editable. Setting the Date of Birth field as Visible but Read-Only for Banking Reps allows them to search and view the field without editing capability. Meanwhile, the Customer Support Reps' profile can have the field set as Visible and Editable. Validation rules are more suited to enforcing complex logic but are not ideal for simple access control, as they cannot control searchability. Adding the field to the search layout ensures searchability but does not enforce edit permissions. Hence, adjusting FLS is the recommended, declarative, and secure approach.
Universal Containers is planning to pilot a new application to a small set of sales reps.
What is the optimal way to grant only those sales reps access to the new functionality,
while hiding the legacy functionality?
A. Clone the Sales Rep profile, adjust settings, and assign the pilot users the new profile.
B. Revoke access to legacy functions in the Sales Rep profile and create a permission set for the new functionality.
C. Create a permission set to grant access to the new functionality and hide the old functionality.
Explanation:
Profiles define a user’s baseline permissions and visible apps/tabs. Cloning the existing Sales Rep profile allows you to create a customized profile where you can enable the new functionality and remove legacy app visibility or permissions. This method cleanly separates users and controls UI elements effectively. Using permission sets to add new functionality (option B or C) can grant access but cannot hide legacy features already assigned via the profile. Profiles remain the fundamental way to restrict or grant access to core app functions and visibility.
| Page 1 out of 7 Pages |