Examkin

Configuration and Setup

360 questions

All types360Multiple choice187Multiple select125Matching36Ordering12
Question 1Question →

A logistics enterprise relies on a single baseline profile for all 50 warehouse dispatchers. The administrator needs to grant two senior dispatchers elevated access to export freight records and edit the restricted 'Customs Priority' field on the Freight Manifest custom object, without expanding access for the remaining dispatchers. Which two administrative actions should be taken to meet this requirement following Salesforce security best practices? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Create a permission set granting the Export Reports system permission and Edit access to the Customs Priority field, then assign it to the two senior dispatchers.; Keep all dispatchers assigned to their existing baseline profile to preserve organizational least privilege principles.

Answer

The administrator should create a permission set with the required export and field-level edit permissions for assignment to the two senior dispatchers, while keeping all dispatchers on their standard baseline profile.
The combination of creating a permission set for the specific elevated permissions and leaving all users on their baseline profile adheres to Salesforce best practices. Permission sets allow administrators to extend functionality to specific users on a case-by-case basis while maintaining clean, maintainable profiles.

Step-by-Step Solution

1
Evaluate access requirements
Identify that only two out of fifty users require additional permissions.
Additive, user-specific permissions should be granted without altering the shared baseline for all users.
2
Build a targeted permission set
Configure a permission set containing 'Export Reports' and Edit access for 'Customs Priority'.
Permission sets extend user access privileges selectively without modifying baseline profile settings.
3
Assign the permission set to target users
Assign the new permission set directly to the two senior dispatchers.
This enforces the principle of least privilege while providing the necessary functional access.

Key Concept

Additive permissions via Permission Sets versus profile maintenance
Question 2Question →

A pharmaceutical firm tracks sensitive clinical test findings using a custom object called Clinical_Trial_Response__c. Business governance mandates that clinical researchers must only be able to view and edit trial records they personally own. Additionally, managers positioned above the researchers in the role hierarchy must automatically inherit read and edit access to records owned by their subordinates, while researchers in other departments must have no access. Which Organization-Wide Default (OWD) setting and configuration satisfies these access requirements?

Show answer & explanation

Answer: Set the Organization-Wide Default to Private and keep 'Grant Access Using Hierarchies' enabled.

Answer

Set the Organization-Wide Default to Private and keep 'Grant Access Using Hierarchies' enabled.
Setting the Organization-Wide Default to Private establishes the most restrictive baseline access so that users only see records they own. Keeping 'Grant Access Using Hierarchies' selected ensures users above the record owner in the role hierarchy automatically inherit access to those records.

Step-by-Step Solution

1
Determine the baseline access requirement for non-owners in different departments.
Since non-owner researchers in other departments must have no access to records, the baseline Organization-Wide Default (OWD) must be set to Private.
OWD defines the most restrictive baseline level of access across the organization.
2
Evaluate role hierarchy requirements for managers above record owners.
Higher-level roles require access to records owned by subordinates.
For custom objects, keeping 'Grant Access Using Hierarchies' checked ensures that users higher in the role hierarchy automatically inherit the access rights of record owners below them.

Key Concept

Organization-Wide Defaults (OWD) and Role Hierarchy access propagation for custom objects
Question 3Question →

A Salesforce Administrator needs to provision access for 15 new regional auditors. All 15 auditors require the base access provided by the standard 'Read Only' profile. However, 5 of these auditors also require permissions to create and edit records on a custom object named 'Compliance Audit', while the remaining 10 auditors must not have access to modify this object. How should the administrator provision these users to meet the security requirements while minimizing administrative maintenance?

Show answer & explanation

Answer: Assign all 15 auditors the standard Read Only profile, and create and assign a Permission Set granting Create and Edit access on the Compliance Audit object to the 5 auditors who require it.

Answer

Assign all 15 auditors the standard Read Only profile, and create and assign a Permission Set granting Create and Edit access on the Compliance Audit object to the 5 auditors who require it.
Assigning all users a common baseline profile and using a Permission Set for the 5 users who need extra permissions adheres strictly to Salesforce security architecture guidelines. Profiles establish the base privileges, and Permission Sets grant incremental permissions without cluttering the org with multiple single-purpose profiles.

Step-by-Step Solution

1
Identify baseline user access requirements across all target users.
All 15 auditors require identical baseline read-only access.
Establishing a single common profile minimizes administrative complexity.
2
Evaluate the additive permission requirements for the subset of users.
5 auditors require additional Create and Edit access on the custom 'Compliance Audit' object.
Profiles should define baseline access, while Permission Sets extend access for specific sub-groups.
3
Select the appropriate Salesforce security component to grant the extra access.
Create a Permission Set with object-level Create and Edit permissions for 'Compliance Audit' and assign it to the 5 specific auditors.
This adheres to the principle of least privilege and Salesforce best practices for access management.

Key Concept

Profiles vs. Permission Sets for additive access management
Question 4Question →

A renewable energy company manages confidential bidding proposals using a custom object named Partner_Bidding_Proposal__c. Executive leadership mandates that sales managers should only be able to view and edit bidding proposals owned by their direct reports. Users outside the owner's management hierarchy must have no access to these records unless explicitly shared. Additionally, the system administrator needs to ensure the baseline security configuration follows Salesforce best practices without creating unnecessary maintenance overhead. Which two administrative steps must the system administrator take to satisfy these security requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set the Organization-Wide Default (OWD) for Partner_Bidding_Proposal__c to Private.; Ensure the 'Grant Access Using Hierarchies' checkbox remains selected on the custom object's sharing settings.

Answer

The correct configuration requires setting the Organization-Wide Default for Partner_Bidding_Proposal__c to Private and ensuring the 'Grant Access Using Hierarchies' setting is enabled.
To achieve a baseline where only owners and their manager hierarchy can access records, the Organization-Wide Default must be configured to Private. Concurrently, keeping 'Grant Access Using Hierarchies' enabled on the custom object allows managers above the owner in the role hierarchy to automatically inherit visibility and editing privileges.

Step-by-Step Solution

1
Determine the required baseline record visibility
Since users outside the owner's hierarchy must have no access by default, set the Organization-Wide Default (OWD) internal access to Private.
OWD defines the most restrictive baseline access level for records an employee does not own.
2
Evaluate role hierarchy propagation for the custom object
Keep 'Grant Access Using Hierarchies' checked on the custom object.
For custom objects, 'Grant Access Using Hierarchies' is enabled by default and ensures managers above record owners automatically inherit access without requiring custom sharing rules.

Key Concept

Organization-Wide Defaults (OWD) and Role Hierarchy Inheritance
Question 5Question →

A Salesforce Administrator at a financial services firm needs to secure access to a custom field, Tax_Identification_Number__c, on the Account object. All users assigned to the Standard Support profile must be prevented from viewing or editing this field. However, two designated support lead users require Read access to this field. Additionally, all users on the Standard Support profile must be blocked from logging in when outside the corporate network IP range. Which two administrative actions should be implemented to fulfill these security requirements? (Choose 2 answers)

Select all that apply

Show answer & explanation

Answer: Deselect the Visible and Read-Only checkboxes for Tax_Identification_Number__c on the Standard Support profile, and assign a Permission Set granting Read access on the field to the two support lead users.; Add the corporate network IP addresses to the Login IP Ranges section on the Standard Support profile settings.

Answer

To satisfy the security requirements, the administrator should deselect visibility for the custom field on the profile and grant Read access via a permission set to designated leads, as well as configure Login IP Ranges on the profile to restrict network access.
Field-Level Security (FLS) configured at the profile level ensures that users on that profile cannot access the field in UI, reports, or APIs. A permission set can then additively grant read access to specific individuals without altering the base profile. Furthermore, setting Login IP Ranges directly on the profile restricts users on that profile to logging in exclusively within the specified IP range.

Step-by-Step Solution

1
Analyze field-level access requirements for profile and specific users
Disabling visibility on the profile restricts access for all standard support users, while assigning a permission set grants Read access specifically to the two support leads.
Profiles define baseline access, while Permission Sets selectively grant additional permissions to specific users.
2
Evaluate login IP restriction requirements
Configuring Login IP Ranges on the profile strictly prevents profile users from logging in outside the designated corporate IP range.
Profile-level IP ranges enforce hard login restrictions, whereas org-wide Network Access ranges only manage identity verification challenges.

Key Concept

Profiles establish maximum baseline restrictions and profile-level IP limits, whereas Permission Sets grant additive field permissions to targeted users.
Question 6Question →

Match each security and access control scenario for Global Logistics Corp to the appropriate Salesforce profile or field-level security (FLS) configuration setting.

Click a left item, then click its matching right item

Items

Completely restrict visibility of the sensitive field 'Executive_Audit_Notes__c' across all standard users regardless of page layout modifications.
Grant Read-Only visibility of the custom field 'Credit_Limit__c' to the Standard User profile while allowing full edit capability on the Finance profile.
Prevent users assigned to a specific custom profile from logging into Salesforce entirely when outside corporate network IP ranges.
Allow Sales Representatives to create, view, and modify custom 'Freight_Contract__c' records while explicitly revoking their capability to delete them.

Matches

Show answer & explanation

Answer

Each scenario maps to its underlying security level in Salesforce: sensitive field access to FLS hiding, profile-specific field editing to FLS visibility/read-only controls, network login enforcement to Profile Login IP Ranges, and record deletion restrictions to Object Permissions (CRUD).
Each business requirement aligns directly with Salesforce security controls: Field-Level Security governs data access at the field level regardless of UI controls, Object Permissions define baseline record CRUD privileges on profiles, and Profile Login IP Ranges enforce absolute network login restrictions.

Step-by-Step Solution

1
Analyze field-level security vs. page layout security requirements.
Field accessibility across APIs, reports, and search requires FLS settings rather than page layout adjustments.
Page layouts only hide fields on the user interface; FLS secures the field at the data layer.
2
Evaluate object-level CRUD permissions.
Disabling record deletion for a group of users requires unchecking Delete under Object Permissions on their assigned profile.
Object permissions define the baseline record operations (Create, Read, Edit, Delete) available to users with that profile.
3
Differentiate between Profile Login IP Ranges and Organization-Wide Trusted IP Ranges.
Profile Login IP Ranges restrict login access completely outside specified ranges, whereas Org-Wide Trusted IP Ranges only bypass multi-factor authentication challenges.
Profile-level IP restrictions strictly enforce network boundaries for authentication.

Key Concept

Profiles and Object/Field-Level Security
Estimated Time:2m 0s
Question 7Question →

An enterprise customer support organization recently transferred a Senior Support Manager to an unassociated international subsidiary. The Salesforce Administrator needs to immediately restrict this user's ability to log in to the org during an offboarding security evaluation. However, during an administrative check, the administrator discovers that the manager is currently designated as the Default Case Owner in Support Settings and is referenced as the target user in several active Case Escalation Rule actions. Which action should the administrator take to prevent log-in access immediately without disrupting existing automated case management processes?

Show answer & explanation

Answer: Freeze the user account immediately, reassign the Default Case Owner setting and Escalation Rule actions to another active user, and then deactivate the user account.

Answer

Freeze the user account immediately, reassign the Default Case Owner setting and Escalation Rule actions to another active user, and then deactivate the user account.
Freezing a user account immediately blocks login access while leaving license allocation and system references unchanged. This allows the administrator to address system dependencies—such as the Default Case Owner setting in Support Settings and active Case Escalation Rules—without leaving an active security vulnerability. Once dependencies are reassigned to another active user, the account can be safely deactivated.

Step-by-Step Solution

1
Evaluate immediate access restriction requirements vs administrative system dependencies.
Identified that immediate login prevention is required while the user is still referenced in Support Settings and Case Escalation Rules.
Direct deactivation is blocked when a user is set as Default Case Owner or tied to active escalation rule actions.
2
Select Freezing as the initial action.
The user's login access is blocked immediately without triggering system dependency validation errors.
Freezing stops user login capability without requiring immediate removal of workflow, setting, or hierarchy references.
3
Reassign system dependencies and execute deactivation.
Support Settings and Escalation Rules are updated to a valid active user, freeing the target user account for full deactivation.
Deactivation releases the Salesforce user license once all blocking administrative references are cleared.

Key Concept

Freezing vs. Deactivating Users with System Dependencies
Estimated Time:2m 0s
Question 8Question →

A healthcare organization requires 15 compliance auditors who belong to different departments—such as Billing, Customer Support, and Legal—to access audit records and view restricted compliance fields. Each auditor currently holds a unique base profile aligned with their primary job function. The administrator needs to grant these additional object and field permissions without altering the base permissions of their existing profiles or proliferating duplicate profiles. Which administrative strategy should the administrator implement to fulfill this requirement?

Show answer & explanation

Answer: Create a single permission set containing the required object and field access, and assign it to the 15 compliance auditors.

Answer

The administrator should create a single permission set with the required object and field permissions and assign it directly to the 15 compliance auditors.
The correct approach uses a permission set to grant supplemental object and field access to the 15 compliance auditors. Permission sets provide additive permissions, allowing administrators to grant extra access to specific users without modifying their baseline profiles or creating redundant profile variations.

Step-by-Step Solution

1
Analyze access requirements across disparate user roles
Identified that 15 users spanning different functional profiles require identical supplemental permissions.
Profiles determine baseline permissions for a role, whereas permission sets grant flexible, additive permissions.
2
Evaluate configuration options for scalability and maintainability
Determined that creating a permission set avoids modifying baseline profiles or creating redundant profile clones.
Permission sets can be assigned to users regardless of their underlying profile assignment.
3
Assign the permission set
Assigned the newly created permission set to the compliance auditors.
This adheres to the principle of least privilege and keeps administrative overhead low.

Key Concept

Using Permission Sets for Additive User Permissions
Question 9Question →

Nova Biotech uses a custom object named Lab_Sample__c with an Organization-Wide Default (OWD) set to Private. Senior Scientists need Read access to all Lab_Sample__c records owned by Lab Technicians who report below them in the role hierarchy. Additionally, members of the Quality Assurance team (located in a separate role hierarchy branch) require Read/Write access to all Lab_Sample__c records where the Status__c field is set to 'Pending Inspection'. Which two configuration steps should the Salesforce Administrator take to satisfy these access requirements?

Select all that apply

Show answer & explanation

Answer: Ensure 'Grant Access Using Hierarchies' remains enabled on the Lab_Sample__c custom object.; Create a criteria-based sharing rule on Lab_Sample__c where Status__c equals 'Pending Inspection' to share records with a Public Group containing Quality Assurance members.

Answer

The administrator must ensure 'Grant Access Using Hierarchies' remains enabled on the custom object and create a criteria-based sharing rule granting Read/Write access to the Quality Assurance Public Group when Status__c equals 'Pending Inspection'.
Enabling 'Grant Access Using Hierarchies' ensures that higher roles in the hierarchy (Senior Scientists) automatically inherit access to records owned by subordinate roles (Lab Technicians). Furthermore, creating a criteria-based sharing rule grants the Quality Assurance Public Group Read/Write access specifically when the record field Status__c equals 'Pending Inspection', satisfying both security requirements cleanly.

Step-by-Step Solution

1
Evaluate role hierarchy access requirements for managers.
Since Lab Technicians report below Senior Scientists in the role hierarchy, keeping 'Grant Access Using Hierarchies' enabled automatically extends Read access to upper roles for custom objects.
By default, custom objects inherit hierarchy access unless explicitly deselected.
2
Evaluate cross-branch conditional access requirements for Quality Assurance.
Create a criteria-based sharing rule evaluated on Status__c = 'Pending Inspection' that grants Read/Write access to a Public Group containing QA users.
Criteria-based sharing rules open up access across role branches based on record field criteria rather than ownership.

Key Concept

Role Hierarchy Access and Criteria-Based Sharing Rules
Question 10Question →

AeroVanguard Logistics maintains a custom field named Driver_License_Number__c on the Contact object. Currently, 15 dispatchers are assigned to a custom profile named 'Dispatcher Profile' which grants Read and Edit access to this field. The compliance department requests that only 2 senior dispatchers retain Read and Edit access to Driver_License_Number__c, while restricting access for all other dispatchers. What is the recommended administrator configuration to achieve this security requirement with minimal administrative maintenance?

Show answer & explanation

Answer: Set Field-Level Security for Driver_License_Number__c to Hidden on the Dispatcher Profile, create a Permission Set granting Read and Edit access to Driver_License_Number__c, and assign it to the 2 senior dispatchers.

Answer

Restrict access to Driver_License_Number__c on the base profile using Field-Level Security, then create and assign a Permission Set granting Read and Edit access to the 2 senior dispatchers.
In accordance with Salesforce security best practices, profiles should grant the minimum required baseline access (least privilege principle). Disabling Field-Level Security for Driver_License_Number__c on the Dispatcher Profile ensures no dispatcher sees the sensitive field by default. A Permission Set is then used to grant additive Read and Edit access specifically to the 2 senior dispatchers without needing a redundant custom profile.

Step-by-Step Solution

1
Identify the base profile security level required for the majority of users.
Modify Field-Level Security (FLS) on the Dispatcher Profile for Driver_License_Number__c to uncheck Read and Edit access.
Profiles establish the baseline (most restrictive) access for all assigned users.
2
Create a Permission Set to grant elevated field access.
Create a new Permission Set and set FLS on Driver_License_Number__c to Read and Edit.
Permission sets are designed to grant additive permissions without creating redundant profiles.
3
Assign the Permission Set to the subset of users.
Assign the created Permission Set to the 2 senior dispatchers.
Only those 2 users receive access to the field while remaining on their existing profile.

Key Concept

Field-Level Security and Additive Permission Sets
Estimated Time:1m 30s
Question 11Question →

Apex Cloud Systems manages customer implementation projects using a custom object named Onboarding_Plan__c. The Organization-Wide Default (OWD) for Onboarding_Plan__c is set to Private. To prevent executive leadership from automatically viewing sensitive technical audit notes, the System Administrator deselects the 'Grant Access Using Hierarchies' checkbox on the Onboarding_Plan__c object. However, Senior Implementation Specialists still require Read access to all Onboarding Plan records owned by Junior Implementation Specialists. Which configuration should the System Administrator implement to satisfy this requirement?

Show answer & explanation

Answer: Create an owner-based sharing rule that shares records owned by the Junior Implementation Specialist role with the Senior Implementation Specialist role.

Answer

Create an owner-based sharing rule that shares records owned by the Junior Implementation Specialist role with the Senior Implementation Specialist role.
Creating an owner-based sharing rule allows the System Administrator to selectively share records owned by users in the Junior Implementation Specialist role with users in the Senior Implementation Specialist role. Since 'Grant Access Using Hierarchies' is turned off for the custom object, this targeted sharing rule delivers required visibility without exposing records to higher executive roles up the hierarchy.

Step-by-Step Solution

1
Evaluate baseline access controls and hierarchy settings.
The Organization-Wide Default is set to Private and 'Grant Access Using Hierarchies' is deselected, meaning upper role hierarchy levels do not automatically inherit access.
Deselecting hierarchy access blocks default upward record access propagation in custom objects.
2
Select the appropriate sharing mechanism for targeted record access.
Implement an owner-based sharing rule targeting records owned by the Junior Implementation Specialist role and share them with the Senior Implementation Specialist role.
Owner-based sharing rules enable explicit record access to defined target roles without enabling hierarchy access globally for higher executive roles.

Key Concept

Owner-Based Sharing Rules and Hierarchy Access Control
Question 12Question →

A Salesforce Administrator at a global manufacturing organization needs to provision system access for 50 newly hired field service technicians. All technicians require base read and edit permissions on Cases and Assets. However, five of these technicians act as regional shift leads and additionally require elevated permissions to create and publish Salesforce Knowledge articles. Company policy requires enforcing the principle of least privilege while minimizing long-term administrative maintenance. Which configuration strategy should the administrator use to provision these users?

Show answer & explanation

Answer: Assign all 50 technicians a single base profile for field service staff, and assign a Permission Set granting Knowledge creation and publishing capabilities to the five regional shift leads.

Answer

Assigning a single base profile to all technicians and granting additional Knowledge management capabilities to shift leads via a Permission Set satisfies least privilege and minimizes profile maintenance.
The correct approach assigns a shared base profile to all technicians for common Case and Asset access, while leveraging a Permission Set to grant Knowledge article management permissions to the shift leads. This adheres to Salesforce best practices by using profiles for baseline functional access and permission sets for additive access.

Step-by-Step Solution

1
Analyze core access requirements shared by all 50 technicians
Identify Case and Asset read/edit capabilities as the common baseline baseline requirement.
Profiles should define baseline access shared by a job function.
2
Evaluate access requirements unique to the sub-group of shift leads
Identify Knowledge article creation and publishing as supplementary permissions.
Additive capabilities needed by a fraction of users should be granted via Permission Sets rather than cloning or proliferating profiles.
3
Select the optimal provisioning model
Assign one baseline profile to all 50 users and assign the Permission Set to the 5 shift leads.
This setup adheres to least privilege and maintains low administrative complexity.

Key Concept

Profile baseline access vs additive Permission Set provisioning
Estimated Time:1m 30s
Question 13Question →

BrightPath Health requires strict data privacy for sensitive patient information on a custom object named Patient Record. Currently, all 40 clinical coordinators share the custom 'Clinical Coordinator' profile. The management team requires that only 4 compliance auditors can view and edit the national_insurance_id__c field. Furthermore, access to this field must be restricted at the API and reporting levels, not just on the user interface. Which two steps should the Salesforce Administrator take to meet these security requirements? (Choose 2 answers.)

Select all that apply

Show answer & explanation

Answer: Set Field-Level Security on the national_insurance_id__c field to remove Read and Edit access from the Clinical Coordinator profile.; Create a Permission Set that grants Read and Edit access to national_insurance_id__c and assign it to the 4 compliance auditors.

Answer

The administrator should restrict access on the base profile using Field-Level Security (FLS) and extend field permissions to the four compliance auditors using a Permission Set.
Field-Level Security (FLS) on the base profile secures the field across all interfaces (UI, API, reports). A Permission Set is then used to grant additive read/edit access specifically to the users who need it, adhering to Salesforce security best practices.

Step-by-Step Solution

1
Configure Field-Level Security on the Clinical Coordinator profile
Field access to national_insurance_id__c is restricted for all clinical coordinators across UI, reports, and API.
FLS enforces field-level security across all data access channels in Salesforce.
2
Create and assign a Permission Set for the compliance auditors
The four compliance auditors are granted Read and Edit permissions for national_insurance_id__c.
Permission sets add permissions on top of profile access for specific individuals.

Key Concept

Profiles restrict base Field-Level Security while Permission Sets extend field permissions to specific users.
Question 14Question →

Vanguard Global Tech needs to restrict access to a sensitive custom field, Base_Salary__c, on the Employee__c object so that only two HR Specialists out of fifty HR team members can view and edit it. Additionally, compliance mandates that all users assigned to the Standard HR Profile must be blocked from logging into Salesforce if they are outside the corporate network IP range. Which two administrative actions should the Salesforce Administrator take to satisfy these security requirements? (Choose 2 answers)

Select all that apply

Show answer & explanation

Answer: Create a Permission Set granting Read and Edit access for the Base_Salary__c field and assign it exclusively to the two HR Specialists.; Specify the corporate network IP range in the Login IP Ranges settings of the Standard HR Profile.

Answer

The correct administrative actions are creating a Permission Set granting Read and Edit access to the sensitive field for the two HR Specialists, and defining the corporate network IP range under Login IP Ranges on the Standard HR Profile.
Creating a Permission Set allows the administrator to selectively grant Read and Edit Field-Level Security (FLS) to the two HR Specialists without altering the access of other users on the Standard HR Profile. Configuring Login IP Ranges directly on the Standard HR Profile enforces hard restrictions that prevent any user with that profile from logging in outside the designated corporate network IPs.

Step-by-Step Solution

1
Evaluate field-level security requirements for a subset of users on the same profile.
Keep field-level security restricted (no access) on the base profile for all fifty HR team members, and create a Permission Set with Read and Edit access assigned only to the two HR Specialists.
Permission sets provide additive permissions for specific users, avoiding profile proliferation.
2
Evaluate login restriction requirements for all users on the Standard HR Profile.
Configure the corporate IP range within the Login IP Ranges section of the Standard HR Profile.
Profile-level Login IP Ranges enforce strict login blocking outside the designated ranges.

Key Concept

Profiles control base restrictions (such as Login IP Ranges), while Permission Sets extend additive access (such as Field-Level Security) to subset user groups.
Estimated Time:1m 30s
Question 15Question →

Apex Freight Services needs to restrict access to a sensitive custom field, Contract_Value__c, on the Account object. Most users assigned to the standard Sales User profile should be prevented from viewing or editing this field. However, three regional Finance Managers who are also assigned the Sales User profile require both Read and Edit access. Which two steps should the administrator take to meet these security requirements while adhering to Salesforce best practices?

Select all that apply

Show answer & explanation

Answer: Set the Field-Level Security for Contract_Value__c on the Sales User profile to clear both Read Access and Edit Access.; Create a Permission Set that grants Read Access and Edit Access for Contract_Value__c, and assign it to the three regional Finance Managers.

Answer

The administrator should restrict Field-Level Security (FLS) on the Sales User profile by removing Read and Edit access for Contract_Value__c, and create a Permission Set granting Read and Edit FLS for Contract_Value__c to assign to the three regional Finance Managers.
Field-Level Security (FLS) controls field access at the platform data layer, ensuring fields are hidden in reports, API integrations, list views, and page layouts. Clearing Read and Edit access on the Sales User profile secures the field by default for all standard sales users. Creating a Permission Set with Read and Edit access and assigning it to the three Finance Managers follows the fundamental Salesforce principle of using profiles for baseline restrictions and permission sets for additive access.

Step-by-Step Solution

1
Evaluate the baseline security restriction
Determine that Field-Level Security (FLS) on the Sales User profile must be restricted so that the default behavior for users on that profile is to hide Contract_Value__c across all platform interfaces (UI, API, reports).
Profiles establish the foundational, most restrictive level of field access needed for the majority group.
2
Determine the optimal mechanism for granting selective access
Identify that a Permission Set granting Read and Edit FLS for Contract_Value__c should be assigned to the three regional Finance Managers.
Salesforce security best practices dictate using Permission Sets for additive permissions to avoid profile proliferation.
3
Reject non-secure or redundant configuration methods
Rule out Page Layout/Dynamic Forms visibility adjustments (UI-only) and Profile Cloning (causes unnecessary administrative overhead).
Field visibility on Lightning pages does not enforce data security, and profile cloning for small user groups creates unnecessary maintenance.

Key Concept

Field-Level Security (FLS) and Additive Access via Permission Sets
Question 16Question →

Nova Health System tracks third-party compliance assessments using a custom object named Vendor_Security_Review__c. The Organization-Wide Default (OWD) sharing setting for Vendor_Security_Review__c is set to Private. During initial object configuration, a system administrator cleared the 'Grant Access Using Hierarchies' checkbox for this object. Later, a Compliance Manager created several assessment records. The VP of Compliance, who occupies a higher position in the role hierarchy above the Compliance Manager, is unable to view or edit these records. Which configuration change should the administrator make to allow the VP of Compliance to access these records without changing the OWD to public?

Show answer & explanation

Answer: Select the 'Grant Access Using Hierarchies' checkbox on the Vendor_Security_Review__c custom object definition.

Answer

Select the 'Grant Access Using Hierarchies' checkbox on the Vendor_Security_Review__c custom object definition.
For custom objects, the 'Grant Access Using Hierarchies' option determines whether users higher in the role hierarchy receive access to records owned by or shared with subordinates. Selecting this checkbox on the object definition resolves the issue while keeping Organization-Wide Defaults Private.

Step-by-Step Solution

1
Analyze the access issue
The VP of Compliance sits above the record creator in the role hierarchy, but cannot view records despite being higher in the hierarchy.
For standard objects, hierarchy access is mandatory and cannot be disabled. For custom objects, hierarchy access can be toggled off via the 'Grant Access Using Hierarchies' setting.
2
Identify the cause of disabled access
The administrator explicitly unchecked 'Grant Access Using Hierarchies' on the custom object definition.
Deselecting this option prevents managers and executive roles from automatically receiving implicit access to records owned by subordinates.
3
Determine the optimal administrative solution
Re-enable 'Grant Access Using Hierarchies' on the object definition.
Enabling this checkbox allows users higher in the role hierarchy to inherit record access while leaving the Organization-Wide Default setting at Private.

Key Concept

Role Hierarchy Access Inheritance on Custom Objects
Question 17Question →

Aura Solar Solutions uses a custom object named Installation_Project__c to track engineering projects. The Organization-Wide Default (OWD) for Installation_Project__c is set to Private, and the 'Grant Access Using Hierarchies' setting is currently unchecked on the object definition.

Management requires the following access configuration:
1. Regional Operations Managers must regain automatic access to Installation_Project__c records owned by users below them in the role hierarchy.
2. Members of the Safety Compliance Team must receive Read access to any Installation_Project__c record where the Risk_Level__c field is set to 'High', regardless of record ownership.

Which TWO configurations should the System Administrator implement to meet these access requirements?

Select all that apply

Show answer & explanation

Answer: Select the 'Grant Access Using Hierarchies' checkbox on the Installation_Project__c object definition.; Create a criteria-based sharing rule on Installation_Project__c where Risk_Level__c equals 'High' to share Read access with the Safety Compliance public group.

Answer

The administrator must enable 'Grant Access Using Hierarchies' on the Installation_Project__c custom object and create a criteria-based sharing rule granting Read access to the Safety Compliance public group when Risk_Level__c equals 'High'.
To restore manager access up the role hierarchy, the 'Grant Access Using Hierarchies' option must be enabled on the object configuration. To conditionally share specific records based on a field value ('Risk_Level__c = High'), a criteria-based sharing rule targeting the appropriate public group is the exact recommended mechanism.

Step-by-Step Solution

1
Address role hierarchy access for managers.
Checking 'Grant Access Using Hierarchies' on the object settings enables automatic upward access propagation along the role hierarchy for custom objects.
When unchecked, custom object records are not shared with users higher in the role hierarchy unless explicit sharing rules or OWD changes are made.
2
Address selective access based on record field values.
Configure a criteria-based sharing rule on Installation_Project__c checking if Risk_Level__c equals 'High' and sharing Read access with the Safety Compliance Team public group.
Criteria-based sharing rules evaluate field criteria on individual records to grant access to designated public groups or roles without altering baseline OWD settings.

Key Concept

Role Hierarchy propagation settings and Criteria-Based Sharing Rules
Estimated Time:1m 30s
Question 18Question →

AeroSpace Tech Solutions recently added a custom field named Background_Check_Status__c to the Contact object to track candidate security clearance details. Management requires that only three HR managers have visibility and edit access to this sensitive field. All other employees, including standard users and sales representatives, must be prevented from seeing or modifying this field anywhere in Salesforce, including reports, list views, and API queries. Which configuration should the System Administrator implement to meet this requirement efficiently?

Show answer & explanation

Answer: Remove Read and Edit access for the field across all profiles via Field-Level Security, create a Permission Set granting Read and Edit access to the field, and assign the Permission Set to the three HR managers.

Answer

Remove Read and Edit access for the field across all profiles using Field-Level Security, create a Permission Set granting Read and Edit access for the field, and assign the Permission Set to the three HR managers.
The correct approach enforces field restriction at the data level by setting Field-Level Security (FLS) to hidden for all base profiles, and then granting Read and Edit access to the three HR managers using a Permission Set. This adheres to Salesforce best practices for granting additive permissions without causing profile sprawl.

Step-by-Step Solution

1
Restrict field access globally via Field-Level Security (FLS).
Uncheck Read and Edit access for Background_Check_Status__c across all profiles so no user receives access by default.
FLS enforces data-level security across all access points including reports, list views, and API queries.
2
Create a dedicated Permission Set.
Create a Permission Set and grant Read and Edit permissions for Background_Check_Status__c under Object Settings.
Permission Sets allow administrators to grant additive permissions to specific users without modifying base profiles.
3
Assign the Permission Set to the target users.
Assign the created Permission Set specifically to the three HR managers.
Only the assigned users gain access while all other users remain restricted.

Key Concept

Profiles and Field-Level Security vs. Permission Sets
Question 19Question →

A Salesforce Administrator needs to immediately suspend login access for a system manager who is taking a temporary leave of absence. The user is currently assigned as the Default Lead Owner in Lead Settings and is designated as the running user for several scheduled Apex jobs. The administrator must ensure that automated background processes continue to execute without disruption during the absence. Which action should the administrator take to meet these requirements?

Show answer & explanation

Answer: Freeze the user account from the User detail page.

Answer

Freeze the user account from the User detail page.
Freezing a user account prevents the user from logging into Salesforce while keeping the user account active for system processes. This allows background jobs and default lead routing to continue functioning normally without requiring re-configuration.

Step-by-Step Solution

1
Analyze the operational requirements and system dependencies.
Login access must be suspended immediately, but the user is tied to system functionality (Default Lead Owner, scheduled Apex running user).
Deactivating a user with active system references leads to validation errors or process disruptions.
2
Determine the appropriate Salesforce administrative tool for temporary restriction with active dependencies.
Freezing the user account stops the user from logging in while preserving record assignments, license allocations, and automated background jobs.
Freezing is designed specifically for cases where a user cannot be immediately deactivated due to system dependencies.

Key Concept

Freezing vs. Deactivating Users in Salesforce
Question 20Question →

BrightPath Education tracks sensitive instructor details using a custom field named SSN__c on the Instructor__c object. Academic Advisors and Human Resources representatives currently share the same custom profile. The administrator needs to ensure HR representatives have Read and Edit access to SSN__c, while Academic Advisors cannot view or edit this field in the UI, reports, or API. Which two configuration steps should the administrator take to fulfill this requirement? (Choose 2 answers)

Select all that apply

Show answer & explanation

Answer: Set Field-Level Security for SSN__c on the shared custom profile to restrict Read and Edit access for all users assigned to that profile.; Create a permission set that grants Read and Edit access to SSN__c and assign it specifically to the Human Resources representatives.

Answer

The administrator should restrict Field-Level Security on the shared profile to remove Read/Edit access for all users, and then create a permission set granting Read/Edit access to the field and assign it to the Human Resources representatives.
To grant field access to a subset of users sharing a profile, best practice dictates revoking access to the field on the baseline profile via Field-Level Security (FLS) and using a permission set to grant additive Read and Edit permissions to the specific users who need access.

Step-by-Step Solution

1
Modify base Field-Level Security (FLS) on the profile
Field-Level Security for SSN__c is restricted for all users sharing the custom profile, removing field access in the UI, reports, and API.
Salesforce security follows a least-privilege baseline model. Profile-level security must restrict access first.
2
Create and assign a Permission Set for additive access
Only Human Resources representatives are assigned the permission set granting Read and Edit access to SSN__c.
Permission sets allow administrators to grant additive field permissions to a target group of users without creating redundant profiles.

Key Concept

Field-Level Security (FLS) restriction on profiles combined with additive access via Permission Sets
Page 1 / 18Next