Universal Containers implemented Sales Cloud and requested that sales agents have
access to products and prices the company sells, and to be able to createopportunities for
its customers.
What should the organization-wide defaults be for pricebook?
A. Public Read-Only
B. View
C. Use
Explanation:
For sales agents needing access to products and prices with ability to create opportunities, "Public Read-Only" is the correct organization-wide default for pricebooks. This setting allows all users to view pricebooks (required for seeing products and prices) while preventing unauthorized edits, as only users with "Manage Price Books" permission can modify them. "View" (Option B) isn't a valid pricebook sharing option. "Use" (Option C) would allow editing pricebooks, which exceeds the requirement. Public Read-Only strikes the right balance - sales agents can reference pricebooks when creating opportunities without risking unauthorized changes to pricing data. This aligns with the principle of least privilege while meeting business requirements. The solution also scales well as the sales team grows and maintains data integrity by preventing accidental modifications to critical pricing information. Additional control can be layered through permission sets if specific users need edit access.
Which functionality does the system method "runAs()" verify when writing test methods?
A. Enforcement of s user's record sharing
B. Enforcement of a user's Field Level Security
C. Enforcement of a user's permissions
Explanation:
The runAs() system method in Apex test classes primarily verifies enforcement of a user's record sharing settings (Option A). When testing with runAs(), the system executes code with the specified user's sharing context, allowing verification of sharing rules, role hierarchy, and manual sharing. While it runs in the user's context, it doesn't fully enforce Field-Level Security (Option B) - field accessibility must be tested separately. It also doesn't verify all user permissions (Option C) as some permissions like API access aren't restricted in test context. The primary purpose of runAs() is to test record-level visibility, crucial for validating sharing models in private or controlled org-wide defaults. This enables comprehensive testing of security models without requiring actual user logins. Developers use runAs() to ensure records are properly shared or restricted according to org sharing settings, making it an essential tool for testing sharing and visibility requirements in complex implementations with multiple user types and access levels.
An architect from a previous project implemented Platform Shield Encryption for a
company. However, based on a recent audit, the company's Privacy Team identified three
additional fields in their Account Records (Billing Street, BillingCity and Phone) that needs
to be secure and protected.
How should an architect proceed with this new policy change?
A. Use Classic Encryption toensure all fields are protected and contact Salesforce for help with encryption verification.
B. Use Encryption Policy and wait for an email from Salesforce indicating the field values are encrypted.
C. Use Encryption Policy and contact Salesforce to update the existing records so that their field values are encrypted.
Explanation:
For adding new fields to Platform Shield Encryption, Option C is correct. The proper process is to use Encryption Policy to select the new fields (Billing Street, Billing City, and Phone) and then contact Salesforce to encrypt existing records, as historical data isn't automatically encrypted. Option A is incorrect because Classic Encryption is deprecated and shouldn't be mixed with Platform Encryption. Option B is incomplete because while Encryption Policy defines what to encrypt, it doesn't address existing data encryption without Salesforce assistance. Platform Encryption requires a specific implementation process: 1) Define encryption policy for new fields, 2) Deploy changes, 3) Contact Salesforce Support to encrypt existing records, as this operation requires backend processing. This approach maintains consistency with the existing encryption implementation while expanding protection to the newly identified sensitive fields. It also ensures compliance with the audit requirements by properly securing all historical data in the newly identified fields, not just future entries. The solution follows Salesforce best practices for encryption expansion projects.
Universal Containers created a public group with certain sales engineers to help on
complex deals, as well as a sharing rule to grant access to these opportunities. The
Opportunity organization-wide default is Private.
What is the impact of these sharing settings?
A. Sales engineers and their managers in the Role Hierarchy will also have access to these records.
B. Subordinates of managers who have sales engineersin the public group will also have access to these records.
C. Other sales engineers who are in the same Role Hierarchy as the sales engineers of the public group will also have access to these records.
Explanation:
With Opportunity OWD set to Private and a sharing rule granting access to a public group of sales engineers, Option A correctly identifies that managers in the role hierarchy will also gain access. In Salesforce's sharing model, when records are shared with users (in this case via public group membership), those users' managers in the role hierarchy automatically gain equal or greater access. This is a fundamental aspect of Salesforce's role hierarchy behavior. Option B is incorrect because subordinates don't inherit access upwards. Option C is wrong because merely being in the same role hierarchy doesn't grant access - the sharing must be explicit or through hierarchy. The scenario demonstrates how sharing rules combine with role hierarchy to determine access. Organizations must consider this behavior when designing sharing models, especially with private OWD settings. It's often desirable as it allows managerial oversight, but can lead to unintended access if not properly planned for during security design.
Universal1 Containers (UC) is a non-profit organization with more than 20,000,000
members (donors). UC decided to assign those accounts to donations reps based on their
regions. Donations reps ended up owning more than 50,000donors each. The donation
reps started to see significant degradation of the system performance.
What is the reason for this problem?
A. There is an Account ownership data skew problem.
B. The donations reps' access to the assigned accounts is wrong.
C. Salesforce sharing recalculation kicked off.
Explanation:
The performance degradation is caused by an account ownership data skew problem (Option A). When individual users own more than 10,000 records (in this case 50,000+ donors each), Salesforce experiences performance issues due to sharing table calculations. This is a well-documented limit in Salesforce architecture. Option B is incorrect because access being "wrong" wouldn't necessarily cause performance degradation. Option C is inaccurate because while sharing recalculations occur, they're a symptom not the root cause. The core issue is the data model assigning too many records to single users, violating Salesforce best practices for data distribution. Solutions include: implementing account teams to distribute access without transferring ownership, using territory management, or revising the assignment rules to better balance record ownership. The situation highlights the importance of considering data skew during design phases for large-volume objects, especially when implementing ownership-based sharing models. Performance can be maintained by ensuring no single user owns excessive records and that data is evenly distributed across the user base.
Universal Containers (UC) has a team that analyzes customer orders looking for fraud.
This team needs access to Invoice records (custom object, Private organization-wide
default). UC has complex rulesto control users’ access. Thearchitect recommended using
Apex managed sharing to meet these requirements.
Which recommendation should a developer consider when implementing the changes?
A. Use "Without Sharing” keyword to make sure record visibility will be considered.
B. Use "With Sharing” keyword to enforce Field-Level Security.
C. Use runAs system method to test different users accessing these records.
Explanation:
For testing Apex managed sharing implementations, Option C is correct - using runAs() to test different user contexts is essential. This allows verification that sharing works as intended for various user profiles. Option A is incorrect because "Without Sharing" would ignore sharing rules entirely, contrary to the requirement. Option B is wrong because "With Sharing" enforces record-level security, not Field-Level Security. When implementing Apex managed sharing, developers should: 1) Create sharing records programmatically based on business rules, 2) Use runAs() in test classes to verify visibility from different user perspectives, and 3) Ensure tests cover both positive and negative cases (users who should and shouldn't have access). This approach provides comprehensive testing of the complex sharing requirements while maintaining security. The solution supports the audit team's need for controlled access to private Invoice records while allowing for flexible, rule-based sharing that can evolve with the company's fraud detection processes. Proper testing with runAs() ensures the implementation meets all security requirements.
Besides their own team accounts, sales managers at Universal Containers (UC) need
Read access to all accounts of the same segment in other countries. Role Hierarchy was
implemented accordingly (based on countries), but a sales manager inthe U.S. is
complaining that he cannot view account records of the same segment in Canada.
What should UC do to grant access properly?
A. Create an owner-based sharing rule to grant access to account records, that have the same segment, to all sales manager roles.
B. Create a public group and include all accounts of the same segment, and then grant access with a permission set.
C. Change the Role Hierarchy and put all the sales managers in the U.S. and Canada in the same role.
Explanation:
To grant U.S. sales managers read access to same-segment Canadian accounts, Option A is correct - creating an owner-based sharing rule is the most appropriate solution. Sharing rules can grant access based on record characteristics (like segment) to entire roles or public groups, crossing hierarchy boundaries. Option B is less ideal as permission sets don't directly grant record access and maintaining public groups of accounts is cumbersome. Option C would break the logical country-based role hierarchy unnecessarily. Owner-based sharing rules are powerful tools for granting horizontal access across role hierarchies while maintaining the vertical hierarchy structure. The rule would: 1) Identify accounts by segment field, 2) Specify sales manager roles as recipients, and 3) Grant read access. This provides clean, maintainable access that automatically adjusts as accounts change segments or managers change roles. The solution respects the existing role hierarchy while meeting the business requirement for cross-border visibility within segments. It's also scalable if additional countries or segments are added later, and performs well because sharing rules are calculated asynchronously.
A consulting company uses the Salesforce mobile app for its field consultants and uses
Case object to track customer specific consulting done by field consultants. The company
also has a large number of customer servicerepresentatives who takes calls from
customers on company issued desktops and uses case object to track customer issues
and grievances. The company would like to capture images of customer site captured by
field consultants while they are editingthe case record during customer site visit. The
Director of IT wants to minimize customization and promote reuseability of code artifacts
wherever possible.
What recommendations should an architect give to the company to implement the image
capture requirement, while ensuring customer that the service rep can continue to use
same lightning pages they were trained to use?
A. Use Lightning Component as an override for “Edit” action on mobile view allowing image capture feature. No Change required for desktop users.
B. Use Lightning Component as an override for “Edit” action on lightning experience allowing image capture feature. Detect the form factor of the device and redirect the user to the default notoverridden 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.
Explanation:
Option A provides the optimal solution by using a Lightning Component override specifically for mobile edit actions, requiring no changes for desktop users. This approach: 1) Minimizes customization by only modifying what's necessary, 2) Promotes reusability through Lightning Components, 3) Maintains existing desktop functionality exactly as is, and 4) Provides a tailored mobile experience. Option B is overcomplicated by attempting device detection in the component itself. Option C creates UI inconsistency by adding a separate button. The override solution cleanly separates mobile and desktop experiences at the action level, following Salesforce best practices for form-factor specific customization. The Lightning Component can encapsulate all mobile-specific functionality including image capture, while desktop users continue using their familiar interface unchanged. This solution also future-proofs the implementation as Salesforce continues enhancing mobile capabilities. It respects the requirement to minimize disruption to trained service reps while adding valuable functionality for field consultants in the most maintainable way possible. The component can be reused elsewhere if similar mobile-specific functionality is needed for other objects.
Universal Containers (UC) operates worldwide, with offices in more than 100 regions in 10
different countries, and has established a very complex Role Hierarchy to control data
visibility. In the new fiscal year, UC is planning to reorganizethe roles and reassign account
owners.
Which feature should an architect recommend to avoid problems with this operation?
A. Partition data using Divisions
B. Skinny table
C. Deferred Sharing Recalculation
Explanation:
When Universal Containers plans to reorganize roles and reassign a large number of account owners, it can trigger massive sharing recalculations which can negatively impact system performance. To manage this efficiently, Deferred Sharing Recalculation is the right solution. It allows administrators to temporarily suspend automatic recalculations of record sharing when changes are made in roles, territories, or ownership. After completing all changes, the recalculations can then be run in bulk, reducing the performance impact and avoiding timeouts or incomplete recalculations. Options like Divisions and Skinny Tables are not relevant in this context—Divisions are used for reporting segmentation and Skinny Tables improve query performance but don’t help with sharing recalculations. Hence, Deferred Sharing Recalculation ensures scalability and performance during such organizational changes.
Sales reps at Universal Containers sometimes create large files as a part of the sales
process that are too large to share over email. They would like users to be able to share
files with customers, but the CISO hasrequested that any file linksshared must be
password-protected.
How can this be accomplished?
A. Utilize an AppExchange product for delivering password protected files to customers
B. Create a content delivery; during creation, the user should select the option to require 3 password to access content.
C. Set up an Experience Cloud site for customers to access files and share the file with customers via Chatter. Customers can then log in ta the site to access the content.
Explanation:
Salesforce Content Deliveries allow users to share files externally with password protection, meeting the CISO’s security requirement. Option A (AppExchange) is unnecessary since native functionality exists. Option C (Experience Cloud) requires customer logins, which may not be as seamless as password-protected links. Thus, B is the most straightforward and secure solution.
Universal Containers (UC) has a partner community for its 200 distributors.
UC customer accounts are assigned an individual distributor. The organization-wide default
setting for the custom Delivery object is Private.
How should an architect advise UC to grant all users at a distributor access to delivery
records for all customers assigned to a particular distributor?
A. Create a criteria based sharing rule that shares delivery records matching a distributor to theDistributor role in the Role Hierarchy.
B. Create 2 criteria-based sharing rule that shares delivery records matching the Distributor to users of aPublic Group created for the distributor.
C. Create a Sharing Set for the Distributor profile to grant access to the Delivery object.
Explanation:
The Delivery object is set to Private, so sharing rules are required to make records visible across users. Since each customer is assigned to a distributor, the records can be filtered based on a distributor field. Sharing to the Distributor role in the Role Hierarchy ensures that all users under that role (and its subordinates) will gain access. Option B (Public Group) could work but lacks hierarchical propagation. Option C (Sharing Set) applies only to Experience Cloud users—not internal users. Therefore, using criteria-based sharing with Role Hierarchy is the most efficient and scalable way to meet the requirement.
A sales rep (John) at Universal Containers requested to update information in an account
record where he has Read-Only access. John requested the Edit access permission from
the owner of the record (Paul). Paul manually shared the record withJohn.
Assuming the organization-wide default of the Account object is Public Read-Only, what is
the impact in the system?
A. Existing AccountShare record is updated. Row Cause is "Manual” and Access Level is "Read/Write".
B. New AccountShare record is created. Row Cause is “Manual” and Access Level is “Read/Write”.
C. New AccountShare record is created. Row Cause is “Owner” and Access Level is "Full".
Explanation:
When a record is manually shared, Salesforce creates a new entry in the AccountShare table with the RowCause as Manual. Since John initially had Read-Only access (from OWD), Paul’s manual sharing grants him additional rights, and this is done through a new sharing record—not by updating an existing one. The Access Level reflects the shared access — in this case, Read/Write. Option A is incorrect because existing OWD-based access isn't updated; it's extended via a separate sharing record. Option C incorrectly states "Owner" as RowCause, which only applies to ownership-based access. Therefore, the correct mechanism is a new AccountShare record with RowCause “Manual” and the correct access level.
Page 2 out of 7 Pages |
Previous |