Examkin

All practice questions

1784 questions

All types1,784Multiple choice918Multiple select587Matching142Ordering137
Question 641Question →

A sales administrator at a logistics company wants sales representatives to convert qualified leads into Account and Contact records without automatically creating an Opportunity record. Which action allows sales representatives to skip creating an Opportunity during lead conversion?

Show answer & explanation

Answer: Select the checkbox labeled 'Don't create a new opportunity upon conversion' on the lead conversion screen.

Answer

Select the checkbox labeled 'Don't create a new opportunity upon conversion' on the lead conversion screen.
On the standard Salesforce lead conversion screen, users can check the 'Don't create a new opportunity upon conversion' box to create or update Account and Contact records without generating a new Opportunity.

Step-by-Step Solution

1
Identify the built-in Salesforce UI options available during lead conversion.
Salesforce includes a standard checkbox option directly on the conversion modal window.
This allows end users to evaluate if an active sales deal/opportunity exists before creating a new one.
2
Select the option that specifically prevents Opportunity record creation.
Checking 'Don't create a new opportunity upon conversion' creates Account and Contact records while skipping Opportunity generation.
This fulfills the business requirement without altering field mapping rules or object security settings.

Key Concept

Lead Conversion Opportunity Suppression
Question 642Question →

An administrator at Northern Trail Outfitters needs to configure user interface experience settings for a custom object, `Equipment_Maintenance__c`. The requirement states that when viewing records in the 'Field Operations' Lightning App, users with the 'Maintenance Technician' profile must see a tailored Lightning Record Page assigned specifically to their record type. However, for all other Lightning Apps, these same users should see the standard default page assigned for that record type. Which TWO activation and visibility configurations should the administrator implement to fulfill these requirements? (Select 2 choices)

Select all that apply

Show answer & explanation

Answer: Activate the tailored Lightning Record Page by assigning it as App, Record Type, and Profile default for the 'Field Operations' app and 'Maintenance Technician' profile.; Ensure the standard record page remains assigned as the App Default or Org Default for other Lightning Apps so non-target apps retain their baseline layout.

Answer

The administrator must activate the custom page using the App, Record Type, and Profile combination for the 'Field Operations' app and target profile, while relying on lower-precedence App or Org defaults for other apps.
In Salesforce Lightning App Builder, page activation follows a strict precedence hierarchy: 1) App, Record Type, and Profile, 2) App Default, and 3) Org Default. Activating the tailored page specifically for the 'Field Operations' app combined with the target Record Type and 'Maintenance Technician' profile satisfies the requirement for the target app. For all other apps, because no specific 3-tier assignment exists, Salesforce falls back to the lower-level App Default or Org Default, maintaining the standard layout seamlessly.

Step-by-Step Solution

1
Analyze activation hierarchy precedence in Lightning App Builder.
App + Record Type + Profile activation has the highest precedence, overriding App Default and Org Default only when those three criteria match.
To restrict a custom Lightning Record Page to a specific app, record type, and profile, the explicit 3-tier activation method must be used.
2
Verify fallback behavior for other apps.
When users navigate to the record in any other app, Salesforce checks for matching activation rules; if none exist for that app, it falls back to the App Default or Org Default.
Maintaining the standard page as Org/App default guarantees that non-target apps display the standard layout without further custom configuration.

Key Concept

Lightning Record Page Activation Precedence (Org Default vs App Default vs App + Record Type + Profile)
Question 643Question →

A Salesforce Administrator is tasked with manually provisioning a new Support Specialist who requires baseline system access along with specialized object permissions. In what order should the administrator perform the steps to complete the user provisioning workflow in accordance with Salesforce security best practices?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct administrative sequence is to first prepare the Profile and Permission Set, populate required identity details and select the license, assign the baseline Profile, save the user record, and finally assign the supplementary Permission Set to the created user.
The proper provision sequence starts with verifying security containers, followed by entering mandatory user attributes and assigning a baseline Profile on the creation layout. Saving the user record commits it to the database and generates a User ID, which is a prerequisite for assigning additional Permission Sets.

Step-by-Step Solution

1
Determine access control components
Baseline profile and permission set requirements are verified
Before initiating user creation, the administrator must confirm that the required access control structures exist.
2
Enter user details and license type
Mandatory identity attributes are entered on the User New page
Salesforce mandates fields such as Last Name, Alias, Email, Username, and User License before record creation.
3
Select baseline profile
Profile is associated with the draft user record
Each user must have a single profile assigned during initial creation to define baseline permissions.
4
Save the user record
User account is generated in Salesforce with an active User ID
Saving instantiates the user record in the database, allowing secondary access assignments.
5
Assign supplementary permission set
Additional object and field permissions are granted to the user
Permission Sets are assigned to active User IDs via the Permission Set Assignments related list or manager after user creation.

Key Concept

User Provisioning Workflow and Permission Hierarchy
Question 644Question →

A Salesforce Administrator at an industrial robotics manufacturing company is setting up Lead Custom Field Mapping so that qualified prospect details automatically transfer upon lead conversion. The administrator creates a custom Text field on the Lead object called 'Robotic Application Need'. However, when attempting to map this field in Setup under Lead Custom Field Mapping, the custom Account field 'Robotic Application Detail' (Long Text Area) does not appear in the target drop-down list. What is the reason the administrator cannot select the custom Account field for mapping?

Show answer & explanation

Answer: Custom Lead fields can only be mapped to custom target fields on Account, Contact, or Opportunity that share a compatible data type.

Answer

Custom Lead fields can only be mapped to custom target fields on Account, Contact, or Opportunity that share a compatible data type.
In Salesforce Lead Custom Field Mapping, custom Lead fields can only be mapped to custom fields on Account, Contact, or Opportunity records that possess a compatible data type. A custom Text field on the Lead cannot be mapped to a Long Text Area field on the Account.

Step-by-Step Solution

1
Identify the source and target field types in the scenario.
The source Lead field is a Text field, while the target Account field is a Long Text Area field.
Understanding data types is essential for evaluating field mapping compatibility in Salesforce.
2
Apply Salesforce Lead Custom Field Mapping rules.
Salesforce enforces strict rules requiring matching or compatible data types (e.g., Text to Text, Picklist to Picklist) when mapping custom Lead fields.
Incompatible data types prevent target fields from displaying in the setup mapping drop-down list.
3
Determine why other choices are invalid.
Lead custom fields cannot map to standard fields, record type picklists do not dictate custom field mapping dropdowns, and Sales Processes only control stage values.
Distractors confuse unrelated administration features with conversion mapping rules.

Key Concept

Salesforce Lead Custom Field Mapping Rules
Question 645Question →

A Salesforce administrator at a B2B agricultural equipment manufacturer is configuring lead conversion settings to transfer qualified prospect data across the revenue lifecycle. The sales team requires custom data captured on Lead records—including equipment preference picklists and annual fleet budgets—to map over to newly generated records upon conversion. Which two statements accurately describe the system rules and behaviors governing custom Lead field mapping?

Select all that apply

Show answer & explanation

Answer: A single custom Lead field can be mapped simultaneously to one custom field on the Account, one custom field on the Contact, and one custom field on the Opportunity.; The source custom Lead field and target custom fields on destination objects must share matching data types, such as mapping a custom Picklist to a custom Picklist.

Answer

The correct statements are that a single custom Lead field can be mapped to one custom field on the Account, Contact, and Opportunity objects simultaneously, and that the source and target custom fields must share compatible data types.
Salesforce Lead Custom Field Mapping allows administrators to map each custom field on the Lead object to one custom field on the Account, one custom field on the Contact, and one custom field on the Opportunity concurrently. Furthermore, field mapping enforces data type alignment, requiring source and target fields to share identical or compatible data types.

Step-by-Step Solution

1
Analyze custom lead field destination object limits
Confirm that a single source Lead custom field can map to 1 custom field per target entity (Account, Contact, Opportunity).
Salesforce architecture allows 1-to-1 mapping per object type from Lead conversion settings.
2
Evaluate data type mapping requirements
Verify that source and target fields must match in data type (e.g., Picklist to Picklist, Text to Text).
Field mapping enforces data type compatibility to prevent data corruption during Lead conversion.
3
Assess restrictions on mapping to standard target fields
Identify that custom Lead fields cannot be mapped to standard fields on destination objects.
Platform rules strictly restrict custom Lead field mapping targets to custom fields.

Key Concept

Lead Custom Field Mapping Rules and Data Transfer Capabilities
Estimated Time:1m 30s
Question 646Question →

A Salesforce Administrator is evaluating the core capabilities of Dynamic Forms while building a custom object record page in Lightning App Builder. Which two statements correctly describe features provided natively by Dynamic Forms?

Select all that apply

Show answer & explanation

Answer: Fields and field sections can be placed and organized directly within the Lightning App Builder canvas without depending strictly on traditional page layout structures.; Visibility rules can be configured on individual fields and field sections based on record values, user profile, or device context.

Answer

The correct statements are that fields and field sections can be placed and organized directly within the Lightning App Builder canvas, and visibility rules can be configured on individual fields and sections based on record, user, or device context.
Dynamic Forms allow administrators to break up traditional Record Detail components into individual field and section components directly inside Lightning App Builder. Additionally, administrators can apply component visibility filters to specific fields or field sections based on criteria such as user roles, record attributes, or device types.

Step-by-Step Solution

1
Identify the primary features of Dynamic Forms in Salesforce Lightning App Builder.
Dynamic Forms enable layout customization directly in Lightning App Builder by breaking down the Record Detail component into individual field and section components.
This allows granular layout management and conditional component visibility rules without creating multiple record types or page layouts.
2
Evaluate the distinction between Dynamic Forms visibility and data security.
Dynamic Forms visibility rules only control UI display on the Lightning record page.
Data visibility across APIs, reports, and list views, as well as field permissions, remains strictly governed by Field-Level Security (FLS) and Profile/Permission Set configurations.

Key Concept

Dynamic Forms Capabilities and Field Visibility vs Security
Question 647Question →

An organization requires a custom Lightning Home page to be displayed exclusively to users navigating within the Sales application, while users in all other applications continue to see the standard system default Home page. Additionally, a tailored Opportunity Lightning Record Page must be displayed only when users with the Commercial Sales profile view the High-Value Opportunity record type while working inside the Sales application.

Which two activation configurations must a Salesforce administrator complete in the Lightning App Builder to satisfy these requirements? (Select 2 choices)

Select all that apply

Show answer & explanation

Answer: Activate the custom Home page and set it as the App Default for the Sales application.; Activate the custom Opportunity record page and assign it as the App, Record Type, and Profile default for the Sales application, High-Value record type, and Commercial Sales profile.

Answer

The administrator must activate the custom Home page as the App Default for the Sales application and activate the custom Opportunity record page assigned to the specific App, Record Type, and Profile combination.
To display a customized Home page only within a designated application, the page must be assigned as the App Default for that app. To deliver a specialized record view based on app context, record type, and user role, the Lightning Record Page must be activated using the granular App, Record Type, and Profile default assignment.

Step-by-Step Solution

1
Determine the required activation level for the Home page requirement.
Home pages support two assignment tiers: Org Default and App Default. To target only the Sales app, assign it as the App Default for that specific app.
Home pages are global or app-specific landing pages and do not have record types.
2
Determine the required activation level for the Opportunity Record Page requirement.
Record pages support three assignment tiers: Org Default, App Default, and App, Record Type, and Profile.
Assigning by App, Record Type, and Profile ensures the page appears only for the designated profile, record type, and application context.

Key Concept

Lightning App Builder Activation Precedence (Org Default vs App Default vs App, Record Type, and Profile)
Estimated Time:1m 30s
Question 648Question →

Match each delegated administration requirement or operational task with the exact Salesforce group configuration setting required to grant that capability.

Click a left item, then click its matching right item

Items

Permitting delegated administrators to assign specific permission sets to managed users
Restricting delegated user management privileges to specific regional teams
Allowing delegated administrators to log in as users within their assigned scope
Granting delegated administrators capability to manage fields and layouts on specific custom objects

Matches

Show answer & explanation

Answer

Each delegated administration task maps directly to a specific sub-configuration within a Delegated Administration Group: permission set assignments require entry in Assignable Permission Sets; target user scoping requires specifying Roles and Subordinates in User Administration; logging in as managed users requires role assignments combined with enabling administrative login permissions; and custom object administration requires explicitly naming custom objects in Custom Object Administration.
Each administrative capability relies on explicit configuration within Delegated Administration Groups: Assignable Permission Sets governs permission set granting, Roles and Subordinates controls user boundary limits, Organization Login settings paired with user role scoping enables logging in as managed users, and Custom Object Administration grants layout/field administration rights for selected custom objects.

Step-by-Step Solution

1
Analyze the permission set assignment capability requirement.
Recognize that delegated administrators cannot assign arbitrary permission sets across the org; they are strictly restricted to those added under Assignable Permission Sets.
This prevents privilege escalation by ensuring delegated admins cannot grant permissions beyond their specified scope.
2
Determine how user administration boundaries are scoped.
Identify that adding Roles and Subordinates defines the exact target user population delegated admins can manage.
Delegated administration relies on role hierarchy definitions to scope user creation, password resets, and user edits.
3
Evaluate the setup required for logging in as managed users.
Confirm that the org setting 'Administrator Can Log In as Any User' must be active in combination with role assignment in the delegated group.
Delegated login privileges require feature activation at the org level combined with role-scoped authorization.
4
Identify custom object administration setup rules.
Match object schema administration delegation to the Custom Object Administration related list.
Delegated object management is granular and applies only to explicitly specified custom objects, allowing management of custom fields, page layouts, and picklists.

Key Concept

Salesforce Delegated Administration Setup and Scope Limits
Question 649Question →

A Salesforce Administrator at a medical device manufacturer needs to update product availability for an upcoming sales campaign. The business requires making a new diagnostic software product available to reps using the 'Americas Regional Price Book', while ensuring an obsolete hardware product can no longer be added to new opportunities without impacting existing deals. Which two administrative actions are required to satisfy these business requirements? (Select 2 options)

Select all that apply

Show answer & explanation

Answer: Create an active price entry in the Standard Price Book for the new diagnostic software product before adding it to the Americas Regional Price Book.; Deactivate the price book entry for the obsolete hardware product in the active price books to prevent future selection.

Answer

The administrator must create an active price entry in the Standard Price Book for the new product prior to adding it to custom price books, and deactivate the price book entry for the obsolete product to prevent new selection while preserving existing opportunity data.
The correct responses specify creating an active Standard Price Book entry first for new products, and deactivating the price book entry of obsolete items to block future selection on opportunities while maintaining existing records.

Step-by-Step Solution

1
Establish standard pricing requirement
Product is enabled in standard catalog
Salesforce architecture mandates an active standard price entry before a product can be associated with any custom price books.
2
Add product to custom price book
Product is available for regional sales reps
Once standard price exists and is active, the product can be added to the Americas Regional Price Book with custom list pricing.
3
Deactivate price book entry for obsolete product
Product selection restricted without data loss
Deactivating the price book entry stops reps from adding the product to future opportunities while preserving all past and open opportunity line item references.

Key Concept

Product and Price Book Entry Lifecycle
Question 650Question →

An administrator at Vanguard Medical Devices creates a new Product record for a hardware device named 'CardioMonitor X'. The administrator needs to make this product available for sales representatives to select on opportunities using custom price books. Which two configuration steps must be completed to achieve this requirement? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Create an active price entry for the product in the Standard Price Book.; Add the product as an active price entry in the desired custom price book.

Answer

To allow sales representatives to select a product on opportunities using custom price books, an administrator must create an active price entry for the product in the Standard Price Book and add the product as an active entry in the custom price book.
To make a newly created product available on opportunities using custom price books, an administrator must complete two essential configuration steps: first, create an active standard price entry for the product in the Standard Price Book, and second, add the product as an active entry to the target custom price book. The standard price entry serves as the mandatory foundation in Salesforce before any custom price book entries can be established.

Step-by-Step Solution

1
Create an active standard price entry for the product.
The product receives a baseline price in the Standard Price Book.
Salesforce enforces a standard price entry as a mandatory prerequisite before adding a product to any custom price book.
2
Add the product to the target custom price book with an active price entry.
The product becomes available within the custom price book catalog.
Opportunities assigned to that custom price book can now include this product as an opportunity line item.

Key Concept

Standard and Custom Price Book Entry Prerequisites
Estimated Time:1m 0s
Question 651Question →

A Salesforce Administrator at a heavy machinery rental company needs to create a field on the custom object Equipment_Fleet__c to automatically display the date of the most recent inspection recorded on related Inspection_Log__c records. However, when navigating to the Custom Field Creation Wizard on Equipment_Fleet__c, the Roll-Up Summary field type option is grayed out and cannot be selected. What is the root cause of this limitation?

Show answer & explanation

Answer: The relationship between Equipment_Fleet__c and Inspection_Log__c is defined as a Lookup relationship rather than a Master-Detail relationship.

Answer

The Roll-Up Summary field type is unavailable because Equipment_Fleet__c and Inspection_Log__c are connected via a Lookup relationship instead of a Master-Detail relationship.
Native Salesforce Roll-Up Summary fields are strictly supported on the master object of a Master-Detail relationship. If two objects are connected via a Lookup relationship, the Roll-Up Summary field option will be grayed out and unavailable during field creation.

Step-by-Step Solution

1
Identify the field requirement
The requirement asks to aggregate child record data (MAX inspection date) onto a parent custom object.
Aggregating values across related records is typically handled by Roll-Up Summary fields.
2
Evaluate declarative roll-up summary requirements
Native Roll-Up Summary fields in Salesforce require a Master-Detail relationship between the parent (master) and child (detail) objects.
Lookup relationships do not support native declarative Roll-Up Summary fields.
3
Determine the cause of the disabled field type
Since the field type option is disabled during field creation on the parent object, the underlying relationship must currently be a Lookup relationship.
Salesforce restricts the creation of Roll-Up Summary fields to master objects in Master-Detail relationships.

Key Concept

Roll-Up Summary Field Relationship Requirements
Question 652Question →

A Salesforce Administrator needs to restrict the visibility of the 'Submit for Approval' action on the Case Lightning record page. The action should only be visible when the Case Status is set to 'Escalated' and the current user has been assigned the 'Tier 2 Support' custom permission. In what correct sequential order should the administrator perform the steps in Lightning App Builder to configure these Dynamic Actions visibility rules?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps begins by selecting the Highlights Panel on the page canvas, upgrading it to use Dynamic Actions, selecting the specific action ('Submit for Approval'), adding an Action Visibility filter, and finally defining the filter criteria based on Record Status and User Custom Permission.
To configure Dynamic Actions with conditional visibility rules, an administrator must first select the Highlights Panel in Lightning App Builder and enable Dynamic Actions. Once enabled, the administrator selects the specific action ('Submit for Approval') from the properties pane, initiates a new Action Visibility filter, and defines the criteria evaluating the record's Status field and the viewing user's Custom Permission.

Step-by-Step Solution

1
Select the Highlights Panel component on the record page canvas.
The component properties pane opens on the right side of the Lightning App Builder.
Actions on Lightning record pages are managed within the Highlights Panel component.
2
Click to enable/upgrade to Dynamic Actions in the Highlights Panel property pane.
Actions are decoupled from the page layout and can now be configured directly in Lightning App Builder.
Dynamic Actions must be explicitly enabled on the Highlights Panel before action-level filters can be applied.
3
Select the 'Submit for Approval' action from the list of managed actions.
The action property panel opens displaying visibility controls for that specific action.
Visibility rules are applied on a per-action basis within the Dynamic Actions container.
4
Click 'Add Filter' under the Action Visibility settings.
A new visibility rule configuration window/panel appears.
Filter rules control runtime action visibility for different user profiles, records, or device types.
5
Configure filter logic combining Record > Status = 'Escalated' and User > Permissions > Custom Permission = 'Tier 2 Support'.
The action evaluates dynamically based on both record context and user security context.
Dynamic Actions support evaluating both record field values and advanced user context (such as assigned custom permissions).

Key Concept

Configuring Conditional Action Visibility using Dynamic Actions in Lightning App Builder
Question 653Question →

A growing manufacturing company has a custom field, Salary_Range__c, on the Position object. All members of the Human Resources department share a single custom HR Profile. Management requires that two temporary HR interns on this profile be restricted from viewing or editing the Salary_Range__c field, while all other HR team members retain full view and edit access. Which configuration change should the Salesforce Administrator implement to meet this requirement while adhering to Salesforce security best practices?

Show answer & explanation

Answer: Remove Read and Edit permissions for Salary_Range__c on the HR Profile, create a Permission Set granting Read and Edit access to Salary_Range__c, and assign the Permission Set to all HR team members except the two interns.

Answer

Remove Read and Edit permissions for Salary_Range__c on the HR Profile, create a Permission Set granting Read and Edit access to Salary_Range__c, and assign the Permission Set to all HR team members except the two interns.
The option advocating restricting field permissions on the profile and granting them back via a permission set correctly enforces the principle of least privilege. In Salesforce, field-level security must be restricted at the profile level when any user on that profile should not view the data, and permission sets are then assigned to grant access to the remaining users.

Step-by-Step Solution

1
Identify the baseline security level required across the shared profile
Since a subset of users on the profile must not see the field, the baseline profile access for Salary_Range__c must be set to restrict access (no Read, no Edit).
Profiles set the baseline permissions. In Salesforce security, permissions are additive, so base permissions must be restrictive when exceptions require lower access.
2
Design an additive access structure for the remaining team members
Create a Permission Set with Read and Edit Field-Level Security enabled for Salary_Range__c.
Permission sets allow administrators to grant additional access to specific users without modifying their assigned profile.
3
Assign the Permission Set to the appropriate users
Assign the new Permission Set to all regular HR team members, leaving the two interns without the assignment.
This achieves the desired access control cleanly while avoiding the creation of additional custom profiles.

Key Concept

Field-Level Security (FLS) & Permission Set Architecture
Question 654Question →

An administrator is configuring a new Record Type named 'Enterprise Customer' on the Account object for the Sales team. Which two administrative actions must be completed to ensure users assigned to the Sales User profile can utilize this record type with the appropriate page structure and field values? (Choose 2 answers)

Select all that apply

Show answer & explanation

Answer: Assign the Record Type and its corresponding Page Layout to the Sales User profile.; Configure the available picklist values specifically for the 'Enterprise Customer' Record Type.

Answer

Assign the Record Type and its corresponding Page Layout to the Sales User profile, and configure the available picklist values specifically for the 'Enterprise Customer' Record Type.
To make a record type fully usable for a profile, the administrator must assign both the Record Type and Page Layout to that profile, and explicitly define which picklist values are available for that specific Record Type.

Step-by-Step Solution

1
Configure Page Layout assignment for the target profile
Associated the new Record Type and Page Layout with the Sales User profile in Object Manager.
Page Layouts are assigned to profiles in combination with specific Record Types.
2
Modify Picklist Value availability
Selected which master picklist values apply to the new Record Type.
Creating a record type does not automatically assign picklist values; available values must be edited per record type.

Key Concept

Page Layouts and Record Types Assignment
Question 655Question →

A sales operations manager is documenting the standard lead conversion process for new sales representatives. What is the correct order of steps executed when converting a qualified Lead record in Salesforce?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of lead conversion steps is: 1) Qualify the prospect and click Convert on the Lead record, 2) Select or create an Account record, 3) Select or create a Contact record linked to the Account, 4) Optionally create a new Opportunity record.
During standard Salesforce lead conversion, the user first initiates the process from the Lead record. The system then establishes an Account record for the organization, followed by creating or selecting a Contact record linked to that Account. Finally, an Opportunity record can optionally be created to track pending sales pipelines.

Step-by-Step Solution

1
Initiate conversion from the Lead record.
The Lead conversion window opens once the record is marked qualified.
Conversion begins directly from the Lead record interface.
2
Establish the Account record.
Company details from the lead are transferred into a new or existing Account.
The Account acts as the parent object for associated contacts and opportunities.
3
Establish the Contact record.
Individual details are saved to a Contact under the selected Account.
Contacts reflect specific individuals affiliated with the parent Account.
4
Determine Opportunity creation.
A new Opportunity is created unless the user checks the option to suppress opportunity creation.
Opportunity creation is optional based on whether an active deal exists.

Key Concept

Standard Salesforce Lead Conversion Execution Order
Question 656Question →

Match each Salesforce administration requirement regarding record display and business process management with its corresponding Setup action.

Click a left item, then click its matching right item

Items

Assign specific page views to users based on their assigned Profile and the selected Record Type of a record.
Restrict or customize the selectable picklist values for a specific field across different business processes without changing Field-Level Security.
Configure the pre-selected Record Type that automatically populates when a user initiates new record creation.
Control which Record Types a user profile is allowed to select when creating new object records.

Matches

Show answer & explanation

Answer

Assign specific page views corresponds to Page Layout Assignment matrix. Customizing picklist values per process corresponds to Picklists Available for Editing on the Record Type detail page. Setting the pre-selected record type corresponds to Default Record Type settings on the Profile. Controlling allowed record types corresponds to Assigned Record Types in Profile or Permission Set settings.
Each administrative setup action correctly matches its functional capability in Salesforce. Page Layout Assignment maps layout to Profile and Record Type. Record Type Picklist settings determine valid picklist choices per business process. Profile Record Type Settings manage default selection and available record types.

Step-by-Step Solution

1
Identify the relationship between Profile, Record Type, and Page Layout.
Page Layouts are assigned using a two-dimensional matrix combining Profile and Record Type.
Salesforce uses Page Layout Assignment to determine which layout a user sees when viewing a record with a given Record Type.
2
Analyze how picklist values are filtered per business process.
Modifying 'Picklists Available for Editing' under a specific Record Type restricts picklist options.
Record Types allow administrators to offer different picklist values for the same picklist field without altering Field-Level Security.
3
Determine how default record types are selected during record creation.
Default Record Type is configured under Profile Record Type Settings.
When a user clicks 'New', Salesforce automatically selects the designated default Record Type for their profile unless prompted.
4
Determine how record type visibility and creation rights are assigned.
Assigned Record Types in Profiles or Permission Sets determine record type availability.
A user can only create records for Record Types explicitly assigned to their Profile or enabled via Permission Sets.

Key Concept

Page Layouts and Record Types Assignment Matrix and Settings
Question 657Question →

An administrator needs to establish a custom data model for a medical research organization to link Clinical Trials (Clinical_Trial__c) with Investigational Drugs (Investigational_Drug__c). A single trial can involve multiple drugs, and a single drug can be evaluated across multiple trials. If a Clinical Trial record is deleted, all records linking that trial to its associated drugs must be automatically removed. Furthermore, users must possess Read/Write access on the parent Clinical Trial record in order to create, edit, or delete the link records between a trial and a drug. How should the administrator configure the data model to meet these requirements?

Show answer & explanation

Answer: Create a custom junction object with Master-Detail relationships to both Clinical Trial and Investigational Drug, and set the Sharing Setting on the Clinical Trial master-detail field to Read/Write.

Answer

Create a custom junction object with Master-Detail relationships to both Clinical Trial and Investigational Drug, and set the Sharing Setting on the Clinical Trial master-detail field to Read/Write.
Creating a custom junction object with Master-Detail relationships to both parent objects models a many-to-many relationship and enables automatic cascading deletion. Setting the Sharing Setting attribute on the Master-Detail relationship field to Read/Write strictly enforces that users must hold Read/Write edit permissions on the parent Clinical Trial record to create, edit, or delete related junction records.

Step-by-Step Solution

1
Analyze relationship cardinality and deletion requirements.
Because a clinical trial can involve multiple drugs and a drug can belong to multiple trials, a many-to-many relationship modeled via a custom junction object is required. Automatic cascade deletion of junction records upon master deletion necessitates a Master-Detail relationship.
Master-Detail relationships automatically delete detail records when a master record is deleted.
2
Determine child record edit/delete security controls.
The Sharing Setting property on a Master-Detail relationship field specifies the minimum level of access required on the master record to create, edit, or delete child detail records.
Configuring the Sharing Setting on the Master-Detail field to Read/Write prevents users who only have Read access on the master Clinical Trial record from creating, editing, or deleting junction records.
3
Evaluate object sharing behavior.
Detail objects in Master-Detail relationships inherit access controls directly from their master records and do not possess independent Organization-Wide Defaults.
Master-Detail relationships govern security access implicitly through master parent records.

Key Concept

Junction Object Configuration and Master-Detail Sharing Settings
Estimated Time:2m 0s
Question 658Question →

A Salesforce administrator at a specialized medical device manufacturer is configuring lead conversion settings. During conversion testing, sales representatives report an error when trying to create an Opportunity because a required custom Opportunity Stage value is unavailable for selection. The administrator verifies that the Stage picklist field on the Opportunity object contains the required value. What must the administrator do to make this Stage value available during lead conversion?

Show answer & explanation

Answer: Assign the missing Stage value to the Sales Process linked to the Opportunity record type used during conversion.

Answer

Assign the missing Stage value to the Sales Process linked to the Opportunity record type used during conversion.
In Salesforce, available picklist values for the Opportunity Stage field are strictly governed by the Sales Process assigned to the target Opportunity Record Type. Even if a picklist value exists on the Opportunity object field definition, it will not appear during lead conversion unless it has been explicitly added to the appropriate Sales Process.

Step-by-Step Solution

1
Identify the controlling mechanism for Opportunity Stage picklist values.
Recognize that Opportunity Stage values are governed by Sales Processes rather than standard picklist field definitions alone.
Each Opportunity Record Type is associated with a specific Sales Process that filters available stage values.
2
Locate the Sales Process tied to the target Opportunity record type.
Determine that the required stage value is missing from the designated Sales Process configuration.
Lead conversion respects the record type and associated Sales Process of the newly generated Opportunity.
3
Update the Sales Process configuration in Setup.
Add the missing stage value to the active Sales Process and save changes.
This allows the stage value to be selected when an Opportunity is created during Lead conversion.

Key Concept

Opportunity Sales Processes and Lead Conversion Integration
Estimated Time:2m 0s
Question 659Question →

A Salesforce Administrator at CloudScale AI creates a new product record for a software offering named 'Enterprise AI Engine' and sets its status to active. The administrator then attempts to add this product to a newly created custom price book named 'Federal Government Price Book', but the product is not available for selection. Which condition must be met before the product can be added to the custom price book?

Show answer & explanation

Answer: An active standard price entry for the product must be added to the Standard Price Book.

Answer

An active standard price entry for the product must be added to the Standard Price Book.
In Salesforce, a product must have an active price entry in the Standard Price Book before it can be assigned to any custom price book. This requirement preserves base pricing integrity across standard and custom catalogs.

Step-by-Step Solution

1
Analyze the pricing architecture requirements for products in Salesforce.
Salesforce enforces an architecture where standard pricing serves as the foundational base for all product pricing.
Custom price books build upon the baseline entries established in the Standard Price Book.
2
Determine the mandatory prerequisite for adding a product to a custom price book.
The product must first contain an active price entry in the Standard Price Book.
Without an active standard price entry, the system blocks the creation of custom price book entries for that product.

Key Concept

Standard Price Book entry requirement before custom price book assignment
Estimated Time:1m 30s
Question 660Question →

A Salesforce administrator at an industrial aerospace manufacturing company is configuring lead conversion settings to transfer custom qualification data from Lead records to Account and Opportunity records. The Lead object includes a custom picklist field, Deployment_Scope__c, which needs to populate corresponding target records upon conversion. Which two technical constraints and behaviors must the administrator consider when configuring Lead Custom Field Mapping and conversion settings?

Select all that apply

Show answer & explanation

Answer: Custom fields on the Lead object can only be mapped to custom fields on the Account, Contact, or Opportunity objects.; If a target custom picklist field enforces restricted picklists, lead conversion will fail if the converted Lead contains a picklist value that is not active on the target picklist field.

Answer

The correct configurations to consider are that custom Lead fields can only be mapped to custom fields on target objects, and that target picklist fields enforcing restricted picklists will cause conversion to fail if the Lead contains an inactive or unlisted target picklist value.
Lead conversion mapping requires custom fields on the Lead to be mapped strictly to custom fields on Account, Contact, or Opportunity records. Furthermore, when converting data into custom target picklists with restricted picklists enabled, all values transferred from the Lead must exist as active values in the target picklist set; otherwise, the platform will block record creation and throw a conversion error.

Step-by-Step Solution

1
Analyze field mapping target rules in Salesforce Lead Custom Field Mapping setup.
Confirm that custom Lead fields can only map to custom fields on Accounts, Contacts, or Opportunities, and cannot target standard fields.
Salesforce architecture restricts Lead Custom Field Mapping targets strictly to custom fields on the recipient objects.
2
Evaluate data validation behaviors for picklist values during Lead conversion.
Determine that restricted picklist settings on target custom fields enforce value compliance upon lead conversion record creation.
If a target custom picklist has restricted values enabled, passing an non-existent value from the Lead causes record creation to throw a validation failure.
3
Evaluate distractor options regarding standard field targets and record type automation.
Eliminate claims that custom lead fields can map to standard fields or that record type picklist assignments update automatically.
Lead conversion never updates object metadata dynamically nor bypasses target field custom-to-custom mapping limits.

Key Concept

Lead Custom Field Mapping Restrictions & Picklist Validation Rules
PreviousPage 33 / 90Next
All practice questions — Salesforce Certified Administrator | Examkin