Examkin

All practice questions

1784 questions

All types1,784Multiple choice918Multiple select587Matching142Ordering137
Question 1761Question →

A financial controller at Crestview Manufacturing requests that the Salesforce administrator alter the organization's reporting structure from a standard 12-month calendar year to a custom 13-week quarterly accounting pattern (4-4-5 calendar). Which critical implication must the administrator communicate to executive leadership before proceeding with this configuration?

Show answer & explanation

Answer: Once custom fiscal years are enabled in the organization, the setting cannot be deactivated or reverted to standard fiscal years.

Answer

Once custom fiscal years are enabled in the organization, the setting cannot be deactivated or reverted to standard fiscal years.
Enabling custom fiscal years is an irreversible feature in Salesforce. Once activated, an organization cannot revert to standard fiscal years. Additionally, enabling custom fiscal years prevents the use of standard opportunity forecasting and affects standard reports and quotas.

Step-by-Step Solution

1
Evaluate the requirement for a 4-4-5 accounting calendar
Identified that a custom fiscal year is required since standard fiscal years only support month-based start dates
Standard fiscal years follow 12 Gregorian calendar months, whereas custom fiscal years accommodate custom structures like 13-week quarters.
2
Assess the organizational impact and system warnings in Salesforce Setup
Confirmed that enabling custom fiscal years is permanent and impacts standard forecasting and reports
Salesforce explicitly warns administrators that custom fiscal years cannot be disabled once enabled.

Key Concept

Custom Fiscal Years vs. Standard Fiscal Years Irreversibility
Estimated Time:1m 0s
Question 1762Question →

An administrator at a financial enterprise needs to urgently restrict access for a departing System Administrator. However, an audit reveals that the departing user is configured as the Default Workflow User, is designated as the running user for several critical Scheduled Apex jobs, and is referenced in active automated processes. The executive leadership requires immediate revocation of login capabilities while ensuring zero downtime or failure of existing automated enterprise background jobs. Which resolution path should the administrator execute to satisfy these requirements?

Show answer & explanation

Answer: Freeze the user account immediately to block system login while allowing scheduled background processes to run, reassign all background automation dependencies to a generic system user, and then deactivate the user account.

Answer

The correct course of action is to freeze the user account immediately to block system login while allowing scheduled background processes to run, reassign all background automation dependencies to a generic system user, and then deactivate the user account.
Freezing a user account is specifically designed for scenarios where an administrator must instantly prevent a user from logging into Salesforce, but immediate account deactivation is blocked due to active background process dependencies (such as being the Default Workflow User or running user for Scheduled Apex). Freezing revokes authentication privileges immediately without disrupting running automated jobs. Once the process references are safely remapped to another user account, full user deactivation can be performed to free up the user license.

Step-by-Step Solution

1
Identify the immediate security constraint versus operational dependency.
Login access must be revoked instantly, but deactivating a user tied to background processes (Default Workflow User, Scheduled Apex) will cause errors or fail validation.
Deactivation prevents a user from being logged in, but Salesforce blocks deactivation if the user is a Default Workflow User or will cause scheduled background Apex to fail.
2
Apply user freezing as the immediate mitigation.
The user account status changes to Frozen, preventing any web, mobile, or API login attempts while leaving automated process execution unblocked.
Freezing stops user authentication without altering record ownership or removing the user from system processing contexts.
3
Reassign system administration dependencies and finalize offboarding.
Update the Default Workflow User setting under Process Automation Settings, re-queue or transfer Apex jobs to an active dedicated integration user, and deactivate the original user account.
Safely clears the user from active administrative roles, allowing permanent deactivation and license release.

Key Concept

User Freezing vs User Deactivation in Salesforce Administration
Question 1763Question →

Match each Salesforce administrative requirement on the left with the most appropriate security or configuration mechanism on the right.

Click a left item, then click its matching right item

Items

Restrict access to a sensitive SSN field on the Contact object globally across UI pages, standard reports, and API integrations.
Enforce strict IP address restrictions for a user group so that login attempts originating outside specified corporate IP ranges are blocked.
Grant Read and Create permissions on a custom Audit object to a single user without altering permissions for other users sharing the same Profile.
Hide a custom Salary field component on a Lightning Record Page for specific users while keeping the underlying field accessible via API integrations.

Matches

Show answer & explanation

Answer

Field-Level Security matches restricting field access globally across UI, API, and reports. Profile Login IP Ranges matches strict login denial outside specified IP ranges. Permission Sets match granting object access to a single user without altering shared Profiles. Dynamic Forms Component Visibility rules match hiding fields on Lightning record pages while maintaining API field accessibility.
Each requirement maps to its optimal Salesforce configuration feature: Field-Level Security enforces universal field protection across UI, API, and reporting; Profile Login IP Ranges strictly block logins outside designated IP ranges; Permission Sets additively grant permissions to single users without profile sprawl; Dynamic Forms component visibility controls UI rendering while keeping field data accessible via API.

Step-by-Step Solution

1
Analyze global field security requirement across UI, API, and reporting channels.
Field-Level Security (FLS) is required because page layouts and dynamic component visibility do not restrict report or API access.
FLS is enforced at the platform data layer across all interfaces.
2
Evaluate IP address restriction mechanics at profile versus organization level.
Profile Login IP Ranges outright block unauthorized IP login attempts, whereas Org-Wide Network Access allows login following multi-factor authentication.
Profile-level IP restrictions define hard boundaries for user authentication.
3
Determine how to grant elevated object permissions to an individual user.
Assigning a Permission Set extends privileges cleanly to a specific user without causing profile duplication.
Profiles set baseline access for groups, while Permission Sets handle additive permissions per individual.
4
Identify the mechanism to hide fields strictly within UI view without restricting API integration access.
Dynamic Forms Component Visibility rules conditionally suppress UI rendering while retaining backend FLS visibility for integrations.
UI component visibility is distinct from platform field-level security.

Key Concept

Profiles, Permission Sets, Field-Level Security, and UI Visibility Controls
Question 1764Question →

Universal Containers tracks sensitive internal HR compliance reviews using a custom object named Internal_Investigation__c. Management requires that records must be hidden from all employees by default. Additionally, because these reviews are highly confidential, higher-level managers in the role hierarchy must NOT automatically receive access to records created by their direct reports. Which TWO security settings must an administrator configure to fulfill these requirements? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Set the Organization-Wide Default (OWD) internal access for Internal_Investigation__c to Private.; Deselect the Grant Access Using Hierarchies option for the Internal_Investigation__c object in Sharing Settings.

Answer

To meet the confidentiality requirements, the administrator must set the Organization-Wide Default (OWD) internal access for Internal_Investigation__c to Private, and deselect the Grant Access Using Hierarchies option for the custom object in Sharing Settings.
The correct configuration requires setting the Organization-Wide Default baseline for Internal_Investigation__c to Private to prevent unauthorized access by default, and deselecting Grant Access Using Hierarchies on the custom object settings to ensure managers above record owners in the role hierarchy do not automatically inherit access.

Step-by-Step Solution

1
Establish baseline security restriction
Set Organization-Wide Default (OWD) internal access for Internal_Investigation__c to Private
OWD defines the baseline access for users who do not own the record. Setting it to Private ensures non-owners have no visibility by default.
2
Disable implicit role hierarchy access propagation
Deselect 'Grant Access Using Hierarchies' in Sharing Settings for Internal_Investigation__c
Custom objects enable hierarchy access by default. Unchecking this setting prevents managers higher in the role hierarchy from automatically viewing records owned by their direct reports.

Key Concept

Organization-Wide Defaults (OWD) and Hierarchy Access Control for Custom Objects
Estimated Time:2m 0s
Question 1765Question →

A Salesforce administrator has created official holiday records in Setup to reflect upcoming company closures. The customer support management team wants to ensure that Case Escalation Rule timers automatically pause during these holiday dates. Which configuration step must the administrator perform next to achieve this requirement?

Show answer & explanation

Answer: Add the Holiday records to the specific Business Hours schedule assigned to the Case Escalation Rules.

Answer

Add the Holiday records to the specific Business Hours schedule assigned to the Case Escalation Rules.
In Salesforce, simply creating a Holiday record is not enough to affect automated timing processes. To pause Case Escalation Rules during holidays, the administrator must add the Holiday records to the relevant Business Hours configuration. When an escalation rule uses that Business Hours schedule, Salesforce automatically subtracts the holiday hours from escalation clock calculations.

Step-by-Step Solution

1
Identify how escalation rules calculate operational time
Escalation rules rely on assigned Business Hours to determine active target resolution clocks.
Escalation clocks run only during configured working hours.
2
Link created Holiday records to the target Business Hours
Salesforce subtracts holiday periods from the Business Hours schedule.
Associating holidays directly with a Business Hours profile instructs Salesforce to suspend time-based processes, such as escalation actions, on those designated days.

Key Concept

Associating Holidays with Business Hours
Question 1766Question →

Universal Containers wants to restrict baseline access to a custom object named Support_Ticket__c so that users can only view records they own. Additionally, managers must automatically retain access to records owned by their direct subordinates. Which TWO configurations must the administrator complete to meet these baseline access requirements?

Select all that apply

Show answer & explanation

Answer: Set the Organization-Wide Default (OWD) sharing setting for Support_Ticket__c to Private.; Ensure that the Grant Access Using Hierarchies checkbox remains selected for Support_Ticket__c.

Answer

To configure the baseline security according to requirements, the administrator must set the Organization-Wide Default (OWD) for Support_Ticket__c to Private and ensure that Grant Access Using Hierarchies is checked.
Setting the Organization-Wide Default to Private ensures that record access is restricted by default to record owners. Keeping Grant Access Using Hierarchies checked allows users higher up in the role hierarchy to automatically inherit access to records owned by subordinate roles.

Step-by-Step Solution

1
Determine the most restrictive baseline access setting.
The Organization-Wide Default (OWD) setting for the custom object must be set to Private so non-owners cannot see each other's records by default.
OWD sets the default baseline access level for all records in the organization.
2
Verify role hierarchy access behavior for the custom object.
Ensure Grant Access Using Hierarchies is checked.
This setting allows higher-level roles in the hierarchy to inherit access to records owned by or shared with lower-level roles.

Key Concept

Organization-Wide Defaults (OWD) and Role Hierarchy Access
Question 1767Question →

A Salesforce administrator at a biotechnology company is auditing custom field architecture on a custom Clinical Trial object and refining the Lead conversion process. The administrator needs to convert an existing custom Lookup relationship on Clinical Trial to a Master-Detail relationship, configure field data retention for prospect leads, and calculate total trial budgets. Which two statements accurately describe the technical requirements and platform behaviors associated with these custom field and relationship configurations? (Select 2)

Select all that apply

Show answer & explanation

Answer: To convert a custom Lookup relationship field to a Master-Detail relationship, every existing detail record must have a populated value in that lookup field prior to conversion.; Custom fields on the Lead object must be explicitly mapped to custom fields on the Account, Contact, or Opportunity objects within Lead Conversion Field Mapping to transfer data upon lead conversion.

Answer

The correct statements are that all existing detail records must have a populated lookup value before converting a lookup relationship to master-detail, and custom lead fields require explicit administrator mapping to custom fields on Account, Contact, or Opportunity objects for data to transfer during lead conversion.
The correct choices identify fundamental platform rules for custom fields and object relationships. First, converting a custom lookup relationship to a master-detail relationship requires every child record to have a populated lookup field value because master-detail relationships enforce required parent records. Second, custom fields on the Lead object do not convert automatically; an administrator must explicitly map custom Lead fields to target custom fields on the Account, Contact, or Opportunity objects.

Step-by-Step Solution

1
Evaluate relationship field type conversion prerequisites.
Converting a Lookup field to a Master-Detail field requires that every existing record on the child object contains a valid parent record reference, as Master-Detail records cannot exist without a parent.
Master-Detail relationships enforce mandatory parentage and cascading deletion behaviors.
2
Evaluate Lead conversion custom field mapping rules.
Lead conversion requires manual mapping of custom Lead fields to custom target fields on Account, Contact, or Opportunity.
Automatic field mapping only occurs for standard Lead fields; matching API names do not trigger auto-mapping.
3
Verify Roll-Up Summary field capabilities across relationship types.
Roll-Up Summary fields are restricted to Master-Detail relationships.
Lookup relationships do not support native declarative roll-up summary fields.

Key Concept

Custom Field Data Types and Relationship Conversion Limits
Question 1768Question →

Northern Trail Outfitters maintains an organization-wide Network Access configuration with trusted IP ranges defined for their corporate offices (198.51.100.0 to 198.51.100.255). A field sales representative whose profile has no Login IP Ranges configured attempts to log into Salesforce from a remote location with IP address 203.0.113.50. What will happen when the agent enters valid login credentials from this external IP address?

Show answer & explanation

Answer: The user receives an identity verification challenge but can log in successfully upon completing verification.

Answer

The user receives an identity verification challenge but can log in successfully upon completing verification.
Organization-wide Network Access IP ranges define locations from which users can log in without completing an activation or multi-factor identity challenge. When a user logs in from an IP address outside these trusted ranges—and their profile does not have explicit Login IP Ranges configured—Salesforce prompts them for identity verification. Once verified, the login succeeds.

Step-by-Step Solution

1
Evaluate Profile-Level IP Restrictions
No Login IP Ranges are configured on the user's profile, so login attempts from any IP address are eligible for access rather than being hard-blocked.
Profile-level Login IP Ranges act as strict access boundaries where any IP outside the range is immediately denied entry.
2
Evaluate Org-Level Network Access Settings
The login IP address (203.0.113.50) is outside the org-wide Network Access trusted IP range (198.51.100.0 to 198.51.100.255).
Org-wide Network Access defines IP ranges where users can log in without identity verification.
3
Determine Final Login Behavior
Because the IP is not in the org-level trusted range, Salesforce prompts the user for identity verification (MFA/activation code). Upon successful verification, login is granted.
Being outside org Network Access trusted ranges triggers verification rather than blocking entry.

Key Concept

Difference between Org Network Access Trusted IP Ranges (identity verification prompt bypass) and Profile Login IP Ranges (hard login restriction).
Estimated Time:1m 30s
Question 1769Question →

An administrator at a renewable energy company needs to configure custom field mapping on the Lead object so data flows smoothly when converting leads. Which two statements describe valid requirements for mapping custom Lead fields? (Select 2)

Select all that apply

Show answer & explanation

Answer: The target field must be a custom field created on the Account, Contact, or Opportunity object.; The custom target field must have a data type that is compatible with the custom source field on the Lead object.

Answer

The target field must be a custom field created on the Account, Contact, or Opportunity object, and the custom target field must have a data type that is compatible with the custom source field on the Lead object.
Custom lead fields can only be mapped to custom fields on Account, Contact, or Opportunity objects, and both the source and target custom fields must possess compatible data types to ensure valid data transfer.

Step-by-Step Solution

1
Determine target object field eligibility for lead conversion field mapping.
Confirm that custom lead fields can only be mapped to custom fields on Account, Contact, or Opportunity objects.
Salesforce Lead Conversion Field Mapping does not allow custom lead fields to map to standard fields.
2
Verify data type compatibility between source and target custom fields.
Ensure that the source custom field on Lead and the target custom field share identical or compatible data types.
Mismatched data types prevent successful field mapping configuration.

Key Concept

Custom Lead Field Mapping Requirements and Data Type Compatibility
Question 1770Question →

An administrator at an event management organization needs to ensure that data stored in a custom Lead picklist field, Attendee_Preference__c, is successfully transferred to the Contact object when a lead is converted. What requirement must be met to configure custom field mapping for lead conversion?

Show answer & explanation

Answer: A custom field with a compatible data type must first be created on the Contact object before setting up Lead Custom Field Mapping.

Answer

A custom field with a compatible data type must first be created on the Contact object before setting up Lead Custom Field Mapping.
When mapping custom Lead fields to target objects during lead conversion, an administrator must create a custom field on the Account, Contact, or Opportunity object prior to setting up the mapping. The target field must also have a compatible data type to accept the source Lead field's values.

Step-by-Step Solution

1
Identify the target record type and object for Lead conversion
The target object for attendee details during conversion is the Contact object.
Custom Lead fields do not automatically populate standard or existing target fields unless mapped explicitly.
2
Create the custom target field on the Contact object
A new custom field (e.g., Attendee_Preference__c as a Picklist or Text) is created on Contact.
Lead Field Mapping requires existing target custom fields with compatible data types on Account, Contact, or Opportunity.
3
Navigate to Lead Object Manager settings and configure Map Lead Fields
The Lead custom picklist field is mapped directly to the newly created Contact custom picklist field.
This guarantees data transfer during the lead conversion process.

Key Concept

Custom Lead Field Mapping Data Requirements
Question 1771Question →

Universal Containers uses a single baseline custom profile for all 150 members of its global account management team. To support a new European privacy compliance audit, two account managers assigned to European accounts require temporary 'Edit' and 'Delete' permissions on a custom object named Compliance Audit (Compliance\_Audit__c). Company security policy mandates adhering to the principle of least privilege while minimizing ongoing administrative overhead and avoiding profile proliferation. How should the Salesforce administrator grant the required access to the two account managers?

Show answer & explanation

Answer: Create a standalone Permission Set granting 'Edit' and 'Delete' access on the Compliance Audit object, and assign it directly to the two account managers.

Answer

The administrator should create a standalone Permission Set that grants 'Edit' and 'Delete' access on the custom object and assign it to the two specific account managers.
Creating a targeted Permission Set is the Salesforce best practice for granting additive permissions to a subset of users who share a baseline profile. This maintains least privilege, prevents profile proliferation, and allows simple assignment and removal of permissions.

Step-by-Step Solution

1
Analyze access requirement scope
Identify that only 2 out of 150 users sharing a baseline profile require temporary additive object-level permissions.
Additive access needed for a subset of users should not alter the baseline profile shared by the entire team.
2
Evaluate administrative and security best practices
Determine that creating a Permission Set provides targeted additive CRUD access without profile duplication.
Permission Sets allow clean assignment and revocation of permissions while keeping user profiles streamlined.
3
Assign the Permission Set
Assign the created Permission Set specifically to the two European account managers.
This satisfies least privilege and prevents profile proliferation.

Key Concept

Permission Sets vs. Profiles for Additive Access
Estimated Time:2m 0s
Question 1772Question →

An administrator at Universal Containers has configured a Master-Detail relationship between the standard Account object (Master) and a custom object named Inspection__c (Detail). The administrator deletes an Account record that has several associated Inspection__c records. Later, the administrator restores the deleted Account record from the Recycle Bin. What happens to the related Inspection__c records after the parent Account record is restored?

Show answer & explanation

Answer: The related Inspection__c records are automatically restored alongside the parent Account record, preserving their master-detail relationship.

Answer

The related Inspection__c records are automatically restored alongside the parent Account record, preserving their master-detail relationship.
In a Master-Detail relationship, deleting the master record causes a cascade delete of all associated detail records into the Recycle Bin. When the master record is restored from the Recycle Bin, Salesforce automatically restores all detail records that were deleted as part of the cascade operation, fully retaining their relationship definition and data state.

Step-by-Step Solution

1
Analyze Master-Detail relationship cascade deletion rules
When a master record (Account) is deleted, all detail records (Inspection__c) are automatically soft-deleted and moved to the Recycle Bin.
Detail record lifecycle is strictly tied to the parent master record in a Master-Detail relationship.
2
Evaluate Master-Detail restoration behavior
Restoring the master record automatically triggers the restoration of all related detail records that were cascaded to the Recycle Bin during the deletion.
Salesforce maintains relational integrity by automatically undeleting child records when the parent is restored.

Key Concept

Master-Detail Relationship Cascading Deletion and Restoration Behavior
Question 1773Question →

An organization relies on a custom object named Risk_Assessment__c to document compliance reviews. Executive leadership mandates that by default, only record owners and managers higher in the role hierarchy should have access to view and edit risk assessment records. Unrelated peers and lower-level staff must have no visibility. Which Organization-Wide Default (OWD) setting should the administrator select to establish this baseline access model?

Show answer & explanation

Answer: Private, while keeping Grant Access Using Hierarchies selected.

Answer

The baseline access setting should be configured as Private with Grant Access Using Hierarchies enabled.
Setting the Organization-Wide Default (OWD) to Private establishes the most restrictive baseline access, ensuring users cannot view records owned by others unless explicitly shared. Because Grant Access Using Hierarchies is enabled by default on custom objects, superior roles in the role hierarchy automatically inherit access to records owned by lower-level staff.

Step-by-Step Solution

1
Determine the most restrictive baseline visibility requirement.
Since unrelated peers must have no visibility to records they do not own, the baseline Organization-Wide Default (OWD) must be set to Private.
OWD sets the baseline level of access for the most restricted user in the organization.
2
Evaluate role hierarchy access behavior for the custom object.
Ensure 'Grant Access Using Hierarchies' remains selected so users higher in the role hierarchy automatically gain record access.
Custom objects allow administrators to toggle Grant Access Using Hierarchies, which is enabled by default to propagate record access up the management hierarchy.

Key Concept

Organization-Wide Defaults (OWD) define the baseline record-level security in Salesforce. Profiles and permission sets cannot restrict record access beyond the baseline established by OWD.
Question 1774Question →

An organization has configured custom Business Hours for their London support team (09:00 to 17:00 GMT, Monday through Friday). A Case Escalation Rule is configured to trigger 4 business hours after case creation based on the Business Hours specified on the Case record. An administrator creates a new Holiday record in Salesforce for 'London Bank Holiday' occurring on a Wednesday, but does not associate this holiday with the London support team's Business Hours schedule. If a Case assigned to London Business Hours is created on that Wednesday at 10:00 GMT, when will the Case Escalation Rule trigger?

Show answer & explanation

Answer: At 14:00 GMT on the same Wednesday, because holidays must be explicitly added to a Business Hours schedule for escalation timers to pause.

Answer

At 14:00 GMT on the same Wednesday, because holidays must be explicitly added to a Business Hours schedule for escalation timers to pause.
Holiday records created in Salesforce configuration do not impact business hour calculations or case escalation rules unless they are explicitly assigned to the specific Business Hours schedule. Because the administrator did not associate the 'London Bank Holiday' with the London support team's Business Hours schedule, Wednesday was treated as a standard operating day. Adding 4 business hours to the creation time of 10:00 GMT results in escalation at 14:00 GMT on Wednesday.

Step-by-Step Solution

1
Analyze the relationship between Holiday records and Business Hours schedules in Salesforce.
Creating a Holiday record in Setup defines the holiday date, but it has no functional impact on Case Escalation Rules until it is manually linked to specific Business Hours schedules.
Salesforce allows global organizations to assign different holidays to different regional business hours schedules.
2
Calculate elapsed business hours for the Case on the given day.
Because the London Bank Holiday was omitted from the London Business Hours schedule, Wednesday is treated as a normal 8-hour operational day (09:00 to 17:00 GMT).
Unassociated holidays are bypassed during business hour evaluation.
3
Determine the exact escalation trigger timestamp.
Adding 4 business hours to the creation time of 10:00 GMT yields 14:00 GMT on the same Wednesday.
The entire 4-hour duration falls within Wednesday's active operating window of 09:00 to 17:00 GMT.

Key Concept

Business Hours and Holiday Association Precedence
Question 1775Question →

An administrator at Cloud Kicks is asked to update a custom field on the Account object named `Account_Priority__c` from a Text data type to a Picklist data type to standardize reporting. Additionally, the administrator must ensure that during Lead conversion, the custom `Lead_Priority__c` field correctly populates this updated field on the created Account record. However, when attempting to change the data type directly in Object Manager, the administrator notices potential data preservation risks and field mapping constraints. Which sequence of actions must the administrator take to complete this requirement without losing existing data or breaking lead conversion?

Show answer & explanation

Answer: Change the custom field type from Text to Picklist on the Account object, define the required picklist values ensuring they match existing text data, update record type picklist assignments if record types exist, and map the custom Lead priority field to the Account priority field in Lead Custom Field Mapping.

Answer

The administrator must change the data type from Text to Picklist on the Account object, verify that the defined picklist API names match existing text entries, assign the picklist values to all active Account record types, and configure the custom field mapping on the Lead object to map to the Account picklist field.
Converting a custom Text field to a Picklist field is a valid administration operation in Salesforce. To ensure complete functionality, existing text values must correspond to the new picklist values, the values must be enabled for active record types on the object, and Lead custom field mapping must link the custom Lead field to the matching custom Account field.

Step-by-Step Solution

1
Evaluate custom field data type conversion rules for Salesforce objects.
Changing a custom field from Text to Picklist is supported, provided data length limitations are respected and values align with the picklist definition.
Ensures historical data integrity without causing truncation or data loss during data type conversion.
2
Configure Record Type picklist value availability on the Account object.
All newly added picklist values are assigned to the relevant active Account record types.
If record types exist, newly created or converted picklist values are not automatically available until assigned to specific record types.
3
Configure Lead Custom Field Mapping in Object Manager for the Lead object.
The custom Lead picklist field is mapped to the target custom Account picklist field.
Lead conversion requires explicitly mapping custom Lead fields to compatible custom fields on Account, Contact, or Opportunity.

Key Concept

Custom Field Data Type Conversion and Lead Field Mapping Constraints
Question 1776Question →

An administrator at Universal Containers created a custom Picklist field on the Lead object named 'Preferred Service Level'. The business requirement specifies that when a Lead is converted, the selected value in this custom field must automatically populate onto the newly created Contact record. During testing, the administrator observes that converted Contact records are created with a blank 'Preferred Service Level' field. Which configuration mistake accounts for this behavior?

Show answer & explanation

Answer: The administrator failed to map the custom Lead field to a compatible custom field on the Contact object in the Lead Custom Field Mappings setup.

Answer

The custom Lead field was not mapped to a compatible custom field on the Contact object within the Lead Custom Field Mappings administration settings.
The correct answer highlights that custom fields on the Lead object must be explicitly mapped to custom target fields on the Account, Contact, or Opportunity object using the 'Map Lead Fields' tool under Lead Object Manager. Without this mapping, custom lead field data is ignored during the conversion process.

Step-by-Step Solution

1
Identify the mechanism for transferring custom data during Lead conversion.
Salesforce requires explicit mapping between custom Lead fields and custom Account, Contact, or Opportunity fields.
Custom fields do not automatically carry over upon conversion unless configured in Lead Custom Field Mapping.
2
Verify custom field creation on both source (Lead) and target (Contact) objects.
Both fields must exist and possess matching or compatible data types.
Mapping requires compatible field types (e.g., Picklist to Picklist or Picklist to Text).
3
Navigate to Object Manager > Lead > Fields & Relationships > Map Lead Fields.
Map 'Preferred Service Level' on Lead to 'Preferred Service Level' on Contact.
This establishes the data mapping rule executed during lead conversion.

Key Concept

Custom Field Mapping during Lead Conversion
Estimated Time:2m 0s
Question 1777Question →

An administrator at a medical equipment manufacturer is configuring custom fields on the Equipment_Inspection__c custom object to meet two distinct business requirements:

1. Display the calculated sum of inspection costs from related Inspection_Item__c records, which are currently linked to Equipment_Inspection__c through a Lookup relationship.
2. Ensure custom Lead fields created to track specialized customer inspection requirements automatically pass data to target records during Lead conversion.

Which two considerations or platform limitations must the administrator keep in mind when configuring these custom fields? (Select 2)

Select all that apply

Show answer & explanation

Answer: Roll-up summary fields cannot be created on a parent object linked to child records via a Lookup relationship; the relationship must be Master-Detail or managed via flow automation.; Custom Lead fields can only be mapped to custom fields on the target Account, Contact, or Opportunity objects during Lead conversion, not to standard fields.

Answer

The administrator must account for the platform rule that native roll-up summary fields can only be created on parent objects in a Master-Detail relationship (or handled via automation for Lookup relationships), and the rule that custom Lead fields can only map to custom target fields on the Account, Contact, or Opportunity objects during conversion.
The correct selections address key platform rules for custom fields: native roll-up summary fields are exclusively available when objects are bound by a Master-Detail relationship, and Lead field mapping requires mapping custom Lead fields explicitly to custom target fields on the destination objects.

Step-by-Step Solution

1
Analyze requirement 1 regarding calculating total costs from child records over a Lookup relationship.
Identify that native Roll-Up Summary fields are restricted to Master-Detail relationships.
Lookup relationships do not support native declarative Roll-Up Summary fields unless the relationship is converted to Master-Detail or summary values are aggregated using Record-Triggered Flows.
2
Analyze requirement 2 regarding custom field data flow during Lead conversion.
Identify Lead custom field mapping constraints.
Custom fields on the Lead object must be explicitly mapped to corresponding custom fields on Account, Contact, or Opportunity; mapping directly to standard target fields is not supported.
3
Evaluate potential distractors regarding relationship deletion behaviors, record type picklists, and automatic mapping.
Eliminate incorrect choices based on core Salesforce field and data structure rules.
Lookup relationships do not cascade delete child records, picklist values must be configured per Record Type manually, and Lead mapping is never automatic by label matching.

Key Concept

Custom Field Capabilities and Limitations across Relationships and Lead Conversion
Question 1778Question →

A system administrator at a healthcare enterprise needs to configure security access for a team of temporary clinical research contractors. The contractors require the standard object and field access bundled inside an existing Permission Set Group named 'Clinical_Operations_PSG', which includes Read, Create, Edit, and Delete access on the custom object 'Patient_Trial__c' as well as the 'Modify All Data' system permission.

Management has outlined two specific compliance constraints:
1. Clinical research contractors must NOT be granted Delete access on 'Patient_Trial__c' or the 'Modify All Data' system permission.
2. Existing operational staff currently assigned to 'Clinical_Operations_PSG' must retain their full access permissions without any modifications.
3. The contractors' access must automatically expire 60 days after assignment.

Which two actions should the administrator take to fulfill these requirements? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Create a new Permission Set Group for the research team that bundles the base permission sets, and include a Muting Permission Set within this new group to suppress Delete access on 'Patient_Trial__c' and 'Modify All Data'.; Specify an Expiration Date of 60 days when assigning the new Permission Set Group to the clinical research contractors.

Answer

To meet the compliance requirements, the administrator must create a distinct Permission Set Group containing a Muting Permission Set to restrict Delete and Modify All Data permissions specifically for contractors, and configure an assignment Expiration Date set to 60 days.
Creating a new dedicated Permission Set Group allows administrators to reuse base permission sets while attaching a Muting Permission Set to selectively disable Delete access and 'Modify All Data' strictly for contractors. Combining this with the native Permission Set Group assignment expiration feature ensures that access automatically expires in 60 days without affecting existing staff access.

Step-by-Step Solution

1
Evaluate the impact of Muting Permission Sets on existing Permission Set Groups.
Recognize that adding a Muting Permission Set directly to the existing group would alter permissions for current operational staff.
Muting Permission Sets impact every user assigned to the Permission Set Group in which they reside.
2
Design a isolated Permission Set Group architecture.
Create a new Permission Set Group for contractors, re-use the base permission sets, and attach a Muting Permission Set that revokes Delete on 'Patient_Trial__c' and 'Modify All Data'.
This selectively restricts permissions for contractors while protecting existing staff access.
3
Configure user assignment lifecycle automation.
Set a 60-day assignment expiration date when assigning the new Permission Set Group to contractor user accounts.
Salesforce native user assignment expiration automatically revokes access upon the expiration date.

Key Concept

Permission Set Groups with Muting Permission Sets and User Assignment Expiration
Question 1779Question →

An administrator at Meridian Biotech is evaluating login security controls for users assigned to the custom 'Clinical Researcher' profile. The administrator configures the following settings:

- Profile-level Login IP Ranges: 198.51.100.10 to 198.51.100.50
- Organization-wide Network Access Trusted IP Ranges: 203.0.113.0 to 203.0.113.255
- Profile-level Login Hours: Monday through Friday, 8:00 AM to 5:00 PM EST

Which two authentication outcomes will occur based on these combined security settings?

Select all that apply

Show answer & explanation

Answer: A user attempting to log in from IP address 203.0.113.15 at 10:00 AM on Wednesday is denied access immediately without receiving an identity verification prompt.; A user attempting to log in from IP address 198.51.100.25 at 9:00 AM on Saturday is denied access because the attempt falls outside the profile's designated login hours.

Answer

The two correct outcomes are that a user logging in from IP 203.0.113.15 at 10:00 AM on Wednesday is denied access immediately without an activation prompt, and a user logging in from IP 198.51.100.25 at 9:00 AM on Saturday is denied access due to login hours restrictions.
Profile-level Login IP Ranges establish a strict whitelist. Attempts originating outside 198.51.100.10–198.51.100.50 are rejected outright without sending an identity verification prompt, making the Wednesday attempt from IP 203.0.113.15 denied immediately. Separately, Profile Login Hours enforce temporal boundaries; because Saturday is not within Monday–Friday, the Saturday morning attempt is denied regardless of IP validity.

Step-by-Step Solution

1
Evaluate the login attempt from IP 203.0.113.15 against Profile-level Login IP Ranges.
IP 203.0.113.15 lies outside the allowed range of 198.51.100.10 to 198.51.100.50.
When profile-level IP ranges are configured, Salesforce enforces a hard denial on any IP address outside that range, completely ignoring organization-wide Network Access settings.
2
Evaluate the Saturday 9:00 AM login attempt from IP 198.51.100.25 against Profile-level Login Hours.
Saturday falls outside the allowed window of Monday through Friday, 8:00 AM to 5:00 PM EST.
Profile-level Login Hours block any login attempt outside the defined time window, even if the user connects from an explicitly allowed IP address.

Key Concept

Profile-level Login IP Ranges strictly restrict access (hard block outside range), taking precedence over Organization-wide Network Access. Profile Login Hours independently enforce strict login time boundaries.
Estimated Time:2m 0s
Question 1780Question →

Horizon Healthcare tracks internal compliance reviews using a custom object named Feedback__c. The legal team mandates that records must only be visible and editable by the record owner. Additionally, executive leadership requires that upper-level managers MUST NOT automatically inherit access to their subordinates' Feedback__c records through the management structure. Which configuration should the System Administrator implement to satisfy these security requirements?

Show answer & explanation

Answer: Set the Organization-Wide Default (OWD) for Feedback__c to Private and deselect the Grant Access Using Hierarchies option.

Answer

Set the Organization-Wide Default (OWD) for Feedback__c to Private and deselect the Grant Access Using Hierarchies option.
Setting Organization-Wide Defaults (OWD) to Private restricts baseline record access strictly to record owners. Deselecting 'Grant Access Using Hierarchies' on a custom object stops Salesforce from automatically granting access to users higher in the role hierarchy. Combining both settings enforces the requirement that only owners can access their records without managerial override.

Step-by-Step Solution

1
Determine the required baseline access level.
Since only record owners should see and edit their records by default, the baseline Organization-Wide Default (OWD) must be set to Private.
OWD sets the most restrictive baseline access for records across an organization.
2
Evaluate role hierarchy propagation requirements.
Standard security behavior propagates record access to higher roles in the hierarchy, but deselecting 'Grant Access Using Hierarchies' disables this access for custom objects.
Disabling Grant Access Using Hierarchies prevents managers and superiors from automatically gaining visibility into records owned by their subordinates.

Key Concept

Organization-Wide Defaults (OWD) and Grant Access Using Hierarchies for Custom Objects
PreviousPage 89 / 90Next
All practice questions — Salesforce Certified Administrator | Examkin