Examkin

All practice questions

1784 questions

All types1,784Multiple choice918Multiple select587Matching142Ordering137
Question 841Question →

Match each Salesforce Case collaboration feature to its primary functional purpose in support management.

Click a left item, then click its matching right item

Items

Case Team Role
Predefined Case Team
Case Feed Publisher Action

Matches

Show answer & explanation

Answer

Case Team Role matches with defining the access level (Read Only or Read/Write) granted to a collaborator; Predefined Case Team matches with providing a pre-configured group of internal users for quick assignment; Case Feed Publisher Action matches with enabling support agents to log calls, post updates, or send emails directly from the feed stream.
Case Team Roles specify record access permissions (Read Only or Read/Write) for individual users on a case. Predefined Case Teams group multiple users together for efficient team assignment. Case Feed Publisher Actions allow agents to perform actions such as logging calls, sending emails, or writing Chatter posts directly within the case feed.

Step-by-Step Solution

1
Analyze the purpose of Case Team Roles.
Identify that roles dictate permissions (Read Only vs Read/Write) for individuals added to case teams.
Salesforce uses Case Team Roles to control access rights for team members on specific records.
2
Analyze the purpose of Predefined Case Teams.
Identify that predefined teams consist of reusable groups of users co-assigned to cases.
Predefined teams save time by eliminating the need to add team members individually.
3
Analyze the purpose of Case Feed Publisher Actions.
Identify that publisher actions streamline agent actions directly inside the feed UI.
Publisher actions give agents direct access to key tasks like email, Chatter posts, and call logging within the Case Feed.

Key Concept

Salesforce Case Collaboration Tools (Case Teams and Case Feed)
Question 842Question →

A Salesforce Administrator at a regional healthcare network is provisioning system access for remote telemetry nurses. Company compliance rules mandate that users with the Telemetry Nurse profile must be completely blocked from logging in whenever their connection originates from outside the hospital's secure VPN IP address range. Which configuration should the administrator implement to meet this security requirement?

Show answer & explanation

Answer: Define the designated IP address range under Login IP Ranges on the Telemetry Nurse Profile.

Answer

Define the designated IP address range under Login IP Ranges on the Telemetry Nurse Profile.
Defining the allowed IP range under Login IP Ranges on the user's Profile explicitly restricts authentication so that any login attempt originating outside the designated IP range is denied completely.

Step-by-Step Solution

1
Analyze the compliance requirement.
The requirement specifies that users must be completely denied access (blocked from logging in) if attempting to connect outside a specific IP range.
Salesforce provides two main places for IP management: Profile Login IP Ranges (restrictive enforcement) and Org-wide Network Access (trusted IP list to bypass identity verification).
2
Evaluate Profile Login IP Ranges capability.
Setting IP ranges on a specific Profile strictly limits user logins to only those specified IP addresses. Any login attempt outside this range is hard-blocked.
Profile-level Login IP Ranges satisfy the mandate to block off-network access for users assigned to that profile.

Key Concept

Profile Login IP Ranges vs. Org Network Access
Question 843Question →

Northern Trail Outfitters enforces a Private Organization-Wide Default (OWD) sharing model for both Account and Opportunity objects. A sales representative creates a high-priority Opportunity associated with an Account owned by an executive. To prepare a technical proposal, the sales representative adds a technical specialist to the Opportunity Team and grants them Read/Write access to the Opportunity.

What access level does the technical specialist automatically receive on the parent Account record as a result of this action?

Show answer & explanation

Answer: Implicit Read-Only access to the parent Account record

Answer

Implicit Read-Only access to the parent Account record
When a user is added to an Opportunity Team, Salesforce implicit sharing automatically grants them Read-Only access to the parent Account record. This allows the team member to view the necessary business context of the parent account without gaining edit rights on the account itself.

Step-by-Step Solution

1
Analyze the Organization-Wide Default (OWD) baseline
Both Account and Opportunity objects are set to Private, restricting access to record owners and users above them in the role hierarchy.
Establishing OWD determines baseline sharing boundaries.
2
Evaluate the effect of adding a member to an Opportunity Team
The team member receives the explicit permission defined on the Opportunity (Read/Write in this case).
Opportunity Teams provide record-level access sharing for team selling collaboration.
3
Determine built-in implicit sharing behavior between child Opportunity and parent Account
Salesforce automatically provisions implicit Read-Only access on the parent Account for any user who gains access to a child Opportunity.
Implicit sharing ensures team members can access parent record context without granting edit capabilities on the parent Account.

Key Concept

Implicit Account Sharing via Opportunity Teams
Question 844Question →

A Field Service Administrator at a manufacturing enterprise is configuring Lightning Experience for equipment maintenance operations. When service technicians view a custom object record for Equipment_Maintenance__c, they require a streamlined mechanism directly on the record page highlights panel to create a child Service_Ticket__c record. The new ticket must automatically populate the parent Equipment_Maintenance__c lookup field and pre-assign the ticket Priority field to 'High'. Which configuration solution should the administrator implement to meet these requirements?

Show answer & explanation

Answer: Create an Object-Specific Quick Action on Equipment_Maintenance__c that creates a Service_Ticket__c record, configure Predefined Field Values for the lookup and Priority fields, and add the action to the record page layout.

Answer

Create an Object-Specific Quick Action on Equipment_Maintenance__c targeting Service_Ticket__c, configure Predefined Field Values for the parent lookup and Priority fields, and add the action to the page layout.
An Object-Specific Quick Action created on the parent object (Equipment_Maintenance__c) inherently possesses context of the source record. Using Predefined Field Values within the action configuration allows administrators to automatically populate both the parent lookup field (linking the new Service_Ticket__c to the originating Equipment_Maintenance__c record) and standard picklist values such as Priority = 'High' without developer intervention or unsupported JavaScript.

Step-by-Step Solution

1
Analyze action context requirement
Creating a child record from a parent record requires object context to pass the parent ID.
Global actions lack record context, whereas Object-Specific Quick Actions carry the source record ID implicitly.
2
Evaluate field pre-population capabilities
Predefined Field Values on Object-Specific Quick Actions can set target fields (Priority = 'High') and relational fields (Service_Ticket__c.Equipment_Maintenance__c = Equipment_Maintenance__c.Id).
This avoids requiring custom code or unsupported JavaScript solutions in Lightning Experience.
3
Deploy action to user interface
Add the created action to the Salesforce Mobile and Lightning Experience Actions section of the Equipment_Maintenance__c page layout or Dynamic Actions panel.
This exposes the action directly on the record highlights panel for technicians.

Key Concept

Object-Specific Quick Actions with Predefined Field Values
Estimated Time:2m 0s
Question 845Question →

A System Administrator at Nova Logistics needs to set up a custom sales pipeline for a new Renewable Energy division. This team requires a distinct set of Opportunity Stage picklist values that differ from the existing sales pipeline. Which administrative step must the administrator perform first before associating these stages with a new Opportunity record type?

Show answer & explanation

Answer: Create a new Sales Process to select the available Opportunity Stage picklist values.

Answer

The System Administrator must first create a new Sales Process and select the required Opportunity Stage picklist values.
The Opportunity object requires a Sales Process to manage the Stage picklist field. A Sales Process must be created first to select the active stage values before it can be assigned to an Opportunity Record Type.

Step-by-Step Solution

1
Navigate to Setup and open Sales Processes.
Access the Sales Process management interface.
Sales Processes determine which stage picklists are active for a specific sales workflow.
2
Create a new Sales Process and select the desired stage picklist values.
A defined Sales Process containing the specific stages needed for the Renewable Energy team.
Opportunity stage picklists are controlled at the Sales Process level rather than directly on the record type.
3
Create or edit the Opportunity Record Type and assign the newly created Sales Process.
The Record Type displays only the stages specified in the associated Sales Process.
Every Opportunity Record Type must link to an existing Sales Process to display valid stages.

Key Concept

Sales Processes and Opportunity Stage Picklist Mapping
Question 846Question →

An administrator at a non-profit organization needs to design a data model connecting Grant Programs (`Grant_Program__c`) and Grant Applications (`Grant_Application__c`). The organization requires that deleting a Grant Program record automatically removes all related Grant Application records. Additionally, the administrator must display the total count of submitted applications directly on the parent Grant Program record without writing custom code. Which TWO actions must the administrator take to accomplish this? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Create a Master-Detail relationship field on the Grant Application object that references the Grant Program object.; Create a Roll-Up Summary field on the Grant Program object using the COUNT aggregate function on related Grant Applications.

Answer

The administrator must create a Master-Detail relationship field on the Grant Application object referencing the Grant Program object, and create a Roll-Up Summary field on the Grant Program object using the COUNT function.
To satisfy both the cascade deletion requirement and the automatic count calculation on the parent object without custom code, a Master-Detail relationship must be configured on the child object (`Grant_Application__c`) pointing to the parent (`Grant_Program__c`). Furthermore, a Roll-Up Summary field must be added to the master object (`Grant_Program__c`) using the COUNT function.

Step-by-Step Solution

1
Analyze the relationship deletion and aggregation requirements
Requirements specify cascade deletion and record count aggregation on the parent record
Master-Detail relationships are required whenever parent deletion must trigger detail deletion and when native Roll-Up Summary fields are needed.
2
Define the relationship field location and type
Place a Master-Detail relationship field on the child object (`Grant_Application__c`) pointing to `Grant_Program__c`
Relationship fields are always created on the detail/child object in Salesforce.
3
Configure the aggregation field on the parent object
Create a Roll-Up Summary field on `Grant_Program__c` using the COUNT operation
Roll-Up Summary fields exist on the master object to aggregate metrics from detail records.

Key Concept

Master-Detail Relationships and Roll-Up Summary Fields
Question 847Question →

A Salesforce Administrator at AeroPulse Systems is configuring a newly introduced hardware product, 'FlightSense 360', to be sold across regional markets with custom pricing. Which two administrative actions must be completed before sales representatives can select and add this product to an Opportunity using a custom price book? (Select 2 answers.)

Select all that apply

Show answer & explanation

Answer: Create an active price entry for the product in the Standard Price Book.; Set the Product record status to Active.

Answer

To allow sales representatives to add 'FlightSense 360' to an opportunity from a custom price book, the administrator must ensure the Product record is active and create an active standard price entry in the Standard Price Book.
For a product to be available on an opportunity via a custom price book, the product record itself must be marked as Active, and an active Standard Price Book entry must exist. The standard price serves as the baseline before custom price book entries can be created and utilized.

Step-by-Step Solution

1
Verify product status
Confirm the product record is active so it is accessible in search and record selection.
Inactive products cannot be added to opportunities.
2
Establish standard pricing
Add a standard price entry to the Standard Price Book and mark it active.
Salesforce mandates that a product must have an active standard price before it can be included in any custom price books.

Key Concept

Products and Price Book Entry Prerequisites
Question 848Question →

An administrator at a financial services company creates a new Campaign record to track attendee engagement for an upcoming seminar. The marketing team requires a custom Campaign Member status named 'Session Attended' that should be factored into the campaign's ROI and response metrics. The administrator adds the 'Session Attended' status value to the Campaign Member Statuses related list and updates 150 members to this new status. However, campaign metrics indicate that 'Total Responded' remains 0, and campaign performance reports do not count these members as responded. Which action must the administrator take to ensure these members are accurately included in response calculations?

Show answer & explanation

Answer: Edit the 'Session Attended' status entry on the Campaign Member Statuses related list and check the 'Responded' box.

Answer

Edit the 'Session Attended' status entry on the Campaign Member Statuses related list and check the 'Responded' box.
In Salesforce, creating a custom Campaign Member status value does not automatically designate it as a response. To ensure that members assigned a custom status (such as 'Session Attended') are counted toward campaign response metrics—such as 'Num Responded in Campaign' and summary report metrics—an administrator must edit the status in the Campaign Member Statuses related list and enable the 'Responded' checkbox.

Step-by-Step Solution

1
Identify why campaign statistics report zero responded members.
Realize that adding a custom member status value does not automatically treat that status as a positive campaign response.
Salesforce requires each campaign member status to specify whether it signifies a 'Responded' member.
2
Navigate to the Campaign record's Campaign Member Statuses related list.
Locate the custom status value named 'Session Attended'.
Member statuses are configured per campaign on the Campaign Member Statuses related list or via campaign templates.
3
Edit the status entry and select the 'Responded' checkbox.
Salesforce updates campaign statistics and automatically recalculates 'Num Responded in Campaign' to include members with this status.
Enabling the 'Responded' flag signals Salesforce to count member records with that status in campaign response summaries and reports.

Key Concept

Campaign Member Status Responded Flag
Question 849Question →

A Salesforce Administrator at a software-as-a-service (SaaS) platform needs to display the total number of active software licenses from related custom Subscription records directly on the parent Account record. The Subscription object currently has a Lookup relationship to Account. When attempting to create a Roll-Up Summary field on Account, the administrator notices the field type option is disabled. Which TWO configuration steps or requirements must the administrator address to successfully create the Roll-Up Summary field?

Select all that apply

Show answer & explanation

Answer: Convert the existing Lookup relationship on the Subscription object to a Master-Detail relationship before creating the Roll-Up Summary field on Account.; Ensure that every existing Subscription record has a populated Account lookup field value prior to converting the relationship.

Answer

The administrator must ensure all existing Subscription records have populated Account values and convert the Lookup relationship to a Master-Detail relationship.
In Salesforce, Roll-Up Summary fields are exclusively supported on the parent object of a Master-Detail relationship. Therefore, the existing Lookup relationship must first be converted to a Master-Detail relationship. Additionally, Salesforce enforces that a Lookup relationship can only be converted to a Master-Detail relationship if every existing child record has a non-null parent lookup value populated.

Step-by-Step Solution

1
Identify relationship prerequisites for Roll-Up Summary fields.
Determine that Roll-Up Summary fields require a Master-Detail relationship between the parent and child objects.
Salesforce declarative Roll-Up Summary fields cannot aggregate records linked via standard Lookup relationships.
2
Verify existing record data integrity on the child object.
Confirm that every Subscription record has a populated parent Account record field.
Salesforce blocks converting a Lookup relationship to a Master-Detail relationship if any existing child record contains a null parent lookup field.
3
Convert the relationship and create the field.
Change the lookup field type to Master-Detail on Subscription, then create the Roll-Up Summary field on Account.
Once the Master-Detail relationship is established, the Roll-Up Summary field type becomes available on the parent Account object.

Key Concept

Master-Detail Relationship Requirement for Roll-Up Summary Fields
Question 850Question →

A Salesforce administrator at an agricultural technology company is designing a custom data model. The management team requests a relationship between the standard Contract object and a new custom object named Crop_Inspection__c. The requirement specifies that Crop_Inspection__c must serve as the master object and Contract must serve as the detail object so that inspection records directly control contract access and lifecycle. Which statement correctly explains why this configuration cannot be implemented in Salesforce?

Show answer & explanation

Answer: Standard objects cannot be placed on the detail side of a Master-Detail relationship with a custom object.

Answer

Standard objects cannot be placed on the detail side of a Master-Detail relationship with a custom object.
In Salesforce, standard objects cannot be on the detail side of a Master-Detail relationship with a custom object. While standard objects can act as the master in a Master-Detail relationship with custom objects, they cannot inherit ownership and security from a custom object as a detail record.

Step-by-Step Solution

1
Analyze the requested data model structure.
The requirement asks for the standard object (Contract) to act as the detail record and the custom object (Crop_Inspection__c) to act as the master record.
Understanding the proposed roles for standard and custom objects is essential to evaluate platform limitations.
2
Evaluate Salesforce platform rules for Master-Detail relationships.
Salesforce allows custom objects to be on the detail side of a relationship with standard or custom master objects, but standard objects can NEVER be on the detail side of a Master-Detail relationship.
Standard objects have built-in security and ownership models that cannot be overridden by being a detail child of a custom object.
3
Select the correct architectural explanation.
The statement regarding standard objects not being allowed on the detail side accurately reflects platform capabilities.
This platform rule directly prevents the proposed configuration.

Key Concept

Standard and Custom Object Master-Detail Limitations
Question 851Question →

An administrator at Cloud Horizon Inc. is configuring record access for a custom object named Project_Audit__c. The Organization-Wide Default (OWD) for Project_Audit__c is set to Private. The administrator must grant read access to project audits under specific business requirements. Which two statements correctly describe how Salesforce record access mechanisms behave for this custom object? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Users in roles above the record owner in the role hierarchy automatically inherit read access to Project_Audit__c records when 'Grant Access Using Hierarchies' is enabled.; A criteria-based sharing rule can grant access to Project_Audit__c records to a Public Group based on field values, regardless of who owns the records.

Answer

The correct statements are that users above the record owner in the role hierarchy automatically inherit access when 'Grant Access Using Hierarchies' is enabled, and that criteria-based sharing rules can share records with public groups based on field values regardless of record ownership.
In Salesforce data security, when Organization-Wide Defaults are set to Private, record access can be opened up using the role hierarchy and sharing rules. Enabling 'Grant Access Using Hierarchies' ensures superiors automatically inherit access to records owned by subordinates. Additionally, criteria-based sharing rules allow access to be granted to target groups based on record field values rather than owner assignments.

Step-by-Step Solution

1
Evaluate role hierarchy inheritance for custom objects
When OWD is Private and 'Grant Access Using Hierarchies' is enabled, users above the owner in the role hierarchy automatically gain record access.
Salesforce security architecture automatically rolls up record access through the role hierarchy unless explicitly turned off for a custom object.
2
Evaluate criteria-based sharing rule behavior
Criteria-based sharing rules grant read or read/write access to designated public groups or roles based on field conditions.
Criteria-based sharing operates independently of record ownership.

Key Concept

Role Hierarchy and Sharing Rules Interaction with OWD
Question 852Question →

Universal Containers is implementing a comprehensive Salesforce Files and Content Management architecture. Match each Salesforce Content feature or security control on the left with the business scenario on the right that requires its specific configuration.

Click a left item, then click its matching right item

Items

Content Delivery
Library Workspace Permissions
File Privacy on Records
Asset Files

Matches

Show answer & explanation

Answer

Content Delivery matches external web link sharing with expiration and tracking; Library Workspace Permissions matches defining granular administrative rights in collateral repositories; File Privacy on Records matches hiding attached files from users who have parent record access; Asset Files matches storing lightweight corporate branding graphics without consuming standard storage limits.
Each feature maps precisely to its functional domain in Salesforce Content: Content Deliveries enable tracked/secure external URL access; Library Workspace Permissions handle library metadata and administration; File Privacy on Records restricts file access regardless of parent record access; and Asset Files provide reusable UI/branding images exempt from file storage quotas.

Step-by-Step Solution

1
Analyze the requirement for external sharing with tracking, expiration, and password security.
Identify that Content Delivery creates web-accessible URLs from Salesforce Content with build-in password protection, auto-expiration, and view tracking capabilities.
Standard file attachments and Chatter shares do not natively support password-protected expiration links with view tracking for external non-Salesforce users.
2
Evaluate record-level attachment visibility constraints for confidential audit documents.
Map this requirement to the 'File Privacy on Records' attribute set to 'Private on Record'.
By default, users with access to a parent record inherit view rights to attached files. Setting the privacy flag overrides parent record inheritance.
3
Determine the control mechanism for managing files, tagging, and folder structures in content repositories.
Select Library Workspace Permissions as the controlling layer.
Salesforce CRM Content uses library permission sets (Viewer, Author, Library Admin) assigned to members to govern repository-level file operations.
4
Identify the file solution optimized for branding graphics and system design elements.
Associate Asset Files with corporate logos used across Lightning components and site headers.
Asset files optimize image delivery across apps/portals and do not count against regular Salesforce Files storage allocations.

Key Concept

Salesforce Files Architecture & Content Security Controls
Question 853Question →

A financial services institution is setting up a new specialized Tier 3 Technical Support unit alongside its existing Customer Operations team. The Tier 3 team requires a distinct case lifecycle with specific status values (such as 'In Engineering Review' and 'Patch Pending') that should not be visible to general customer service representatives. The system administrator creates the new custom picklist values on the Case Status field, creates a dedicated Page Layout, and then opens the Case Record Type creation wizard. However, the administrator discovers that the wizard requires selecting an existing process, and the new Tier 3 status values cannot be associated with the new Record Type. Which prerequisite step did the administrator fail to perform before creating the Case Record Type?

Show answer & explanation

Answer: Creating a dedicated Support Process containing the required Case Status picklist values.

Answer

The administrator failed to create a custom Support Process containing the required Case Status values prior to defining the Case Record Type.
In Salesforce, the Case Status field is a special business process field. Unlike standard picklist fields, Case Status values associated with a specific Case Record Type are determined by a Support Process. The required sequence of operations is to create the custom Case Status picklist values, define a Support Process that includes those specific status values, and then create the Case Record Type while selecting the newly created Support Process. Omitting the Support Process step prevents associating custom status values with the new record type.

Step-by-Step Solution

1
Identify the relationship between Case Status, Support Processes, and Record Types in Salesforce.
Recognize that Case Status is a special picklist field linked to business processes, similar to Opportunity Stage and Lead Status.
In Salesforce Core Administration, special lifecycle picklist fields cannot be assigned directly to Record Types without an intermediate process object.
2
Determine the required administrative workflow for configuring new Case lifecycles.
The correct sequence is: (1) Add custom Case Status picklist values, (2) Create a Support Process to select available Case Status values, (3) Create the Case Record Type and associate it with the Support Process, (4) Assign Page Layouts.
Creating a Record Type on the Case object explicitly requires selecting an existing Support Process in the setup wizard.
3
Evaluate the cause of the administrator's roadblock during configuration.
Because no dedicated Support Process was created for Tier 3 Support, the administrator could only select existing Support Processes which lacked the new status values.
Omitting the Support Process creation step prevents new Case Status values from being assigned to the new Case Record Type.

Key Concept

Support Processes pre-requisite for Case Record Types
Question 854Question →

An organization is launching a specialized Tier 3 Infrastructure Support team to work alongside its general IT Service Desk. The Tier 3 team requires a distinct lifecycle for cases, including custom Case Status picklist values such as 'Vendor Investigation' and 'Patch Pending' that should not be visible to general IT agents. When the Salesforce administrator attempts to configure a new Case Record Type for Tier 3 Support, the required Case Status values are unavailable for selection during record type creation. What must the administrator do first to make these specific status values available for the new case record type?

Show answer & explanation

Answer: Create a custom Support Process that includes the required status values and assign it to the new Case Record Type.

Answer

Create a custom Support Process containing the required status values and select it when defining the new Case Record Type.
On the standard Case object, the Case Status field is controlled by a Support Process. To make unique Case Status picklist values available to a specific Case Record Type, an administrator must first create a Support Process that includes those values. Once created, the Support Process is assigned during the Case Record Type setup.

Step-by-Step Solution

1
Identify the dependency architecture for Case lifecycle stages in Salesforce.
Recognize that Case Status is a special picklist field tied directly to Support Processes.
Unlike standard custom picklists, Case Status options cannot be filtered solely at the Record Type level without an underlying Support Process.
2
Define a new Support Process.
Select and save the specific subset of Case Status values ('Vendor Investigation', 'Patch Pending', etc.) required for the Tier 3 team.
The Support Process acts as the master filter for case lifecycle stages.
3
Associate the Support Process with the new Case Record Type.
The new Record Type inherits the status picklist values configured in the designated Support Process.
Creating the Record Type requires selecting an active Support Process as its structural baseline.

Key Concept

Support Process as a Prerequisite for Case Record Types
Question 855Question →

A Salesforce administrator at an enterprise telecommunications provider is configuring custom field mapping for lead conversion. The administrator needs to map a custom Lead picklist field named 'Bandwidth Requirement' to a custom field on the Account object. However, during setup in Lead Custom Field Mapping, the target Account field does not appear in the dropdown list for selection. Which of the following explains why the Account field is unavailable for mapping?

Show answer & explanation

Answer: The target field on the Account object is a Lookup relationship field type.

Answer

The target field on the Account object is a Lookup relationship field type.
In Salesforce, Lead Custom Field Mapping requires compatible data types between source Lead fields and target Account, Contact, or Opportunity fields. A custom Lead Picklist field can only be mapped to a custom Picklist or custom Text field on the Account object. It cannot be mapped to a Lookup relationship field, causing the Lookup field to be omitted from the mapping selection dropdown.

Step-by-Step Solution

1
Analyze Lead Custom Field Mapping requirements in Salesforce.
Lead custom field mapping requires exact or compatible data type matching between source Lead custom fields and target Account, Contact, or Opportunity custom fields.
Salesforce enforces strict data type compatibility when converting leads.
2
Evaluate data type compatibility for a custom Picklist field.
A custom Picklist field on the Lead object can map to a target custom Picklist (single-select) or Text field, but cannot map to Lookup, Roll-Up Summary, Formula, or Auto-Number fields.
Lookup fields store 18-character Salesforce record IDs rather than string/picklist values.
3
Identify why the field is missing from the selection dropdown.
Because Lookup relationship fields are incompatible with Picklist source fields, Salesforce automatically filters them out of the mapping dropdown list.
Only compatible target custom fields are rendered in the mapping interface.

Key Concept

Data type compatibility rules in Salesforce Lead Custom Field Mapping
Question 856Question →

A support manager at Cloud Kicks wants incoming customer support cases automatically routed and assigned to specific support queues based on the value in the Case Origin field upon case creation. Which Salesforce feature should the administrator configure to meet this requirement?

Show answer & explanation

Answer: Case Assignment Rules

Answer

Case Assignment Rules should be configured to route newly created cases to specific queues based on criteria like Case Origin.
Configuring Case Assignment Rules allows administrators to set criteria (such as Case Origin = Web or Email) and automatically route new cases to specific users or queues upon record creation.

Step-by-Step Solution

1
Identify the business requirement
The requirement asks for automatic initial ownership routing of cases to specific queues based on record field values (Case Origin).
Determining whether the goal is initial assignment, customer communication, or time-based escalation dictates the automation tool.
2
Evaluate Salesforce case automation features
Case Assignment Rules are designed specifically to assign ownership (users or queues) of incoming cases based on specified rule criteria.
Assignment rules run during case creation to ensure records immediately reach the correct team.

Key Concept

Case Assignment Rules specify how cases are assigned to users or queues based on defined criteria upon record creation.
Question 857Question →

A Support Manager at Cloud Kicks wants team members to automatically see updates in the Case Feed whenever the Case Status field is changed by another user. Which Salesforce feature should an administrator configure to fulfill this requirement?

Show answer & explanation

Answer: Enable Feed Tracking for the Case Status field in Chatter settings.

Answer

Enable Feed Tracking for the Case Status field in Chatter settings.
Enabling Feed Tracking for the Case object and selecting specific fields (such as Status) causes Salesforce to automatically post a feed item in the Case Feed whenever those field values are updated.

Step-by-Step Solution

1
Identify the requirement for record collaboration and activity tracking.
The requirement asks for automatic posts in the Case Feed when specific field values change.
Tracking field updates directly within record Chatter feeds requires Chatter Feed Tracking configuration.
2
Locate Feed Tracking settings in Setup.
Navigate to Setup → Chatter → Feed Tracking, select the Case object, and check the Status field.
Feed Tracking enables automated system posts for selected standard and custom field changes.

Key Concept

Chatter Feed Tracking on Cases
Question 858Question →

Apex Financial Services recently launched an internal IT Help Desk alongside its existing Client Services team. The administrator needs to configure the Case object so that IT Help Desk cases follow a specific lifecycle with custom Case Status picklist values ('New', 'Triage', 'In Progress', 'Resolved'). However, when creating a new Case Record Type for the IT Help Desk, the administrator notices that Case Status picklist values cannot be customized directly within the Record Type configuration page. Which administrative action must be completed first to enable these custom status values for the new record type?

Show answer & explanation

Answer: Create a new Support Process selecting the specific Case Status values, and associate it when defining the Case Record Type.

Answer

Create a new Support Process selecting the specific Case Status values, and associate it when defining the Case Record Type.
On the Case object, available Case Status picklist values are controlled by Support Processes. An administrator must first create a Support Process containing the required status values before creating and linking a Case Record Type.

Step-by-Step Solution

1
Identify the prerequisite for configuring custom Case Status lifecycles.
Recognize that Case Status picklist values are controlled by a Support Process on the Case object.
Salesforce enforces a Support Process as a mandatory prerequisite before creating or mapping Case Record Types with specific status values.
2
Create the Support Process.
Select the required subset of Case Status picklist values ('New', 'Triage', 'In Progress', 'Resolved').
The Support Process defines the business lifecycle stages for a specific business unit.
3
Link the Support Process to the Case Record Type.
Associate the newly created Support Process during Case Record Type setup.
Each Case Record Type requires exactly one assigned Support Process to determine its active status picklist values.

Key Concept

Support Processes and Case Record Type Prerequisites
Question 859Question →

An administrator needs to deploy a customized Case Lightning Record Page specifically for escalation specialists working in the Service Console application on high-priority cases. Other agents using the Service Console must continue seeing the standard App Default page. Which activation option in Lightning App Builder should the administrator select to fulfill this requirement?

Show answer & explanation

Answer: Assign the page as App, Record Type, and Profile default, selecting the Service Console application, the high-priority case record type, and the escalation specialist profile.

Answer

Assign the page as App, Record Type, and Profile default, selecting the Service Console application, the high-priority case record type, and the escalation specialist profile.
Activating the Lightning Record Page as an App, Record Type, and Profile default ensures that the custom page is displayed only when an escalation specialist views a high-priority case inside the Service Console. All other combinations continue to fall back to the App Default or Org Default assignments.

Step-by-Step Solution

1
Identify the target scope for page activation
The requirement specifies restriction by specific App (Service Console), specific Record Type (high-priority case), and specific user role/profile (escalation specialist).
Lightning App Builder supports three activation levels: Org Default, App Default, and App + Record Type + Profile.
2
Evaluate activation precedence rules
App + Record Type + Profile assignment overrides both App Default and Org Default assignments for matching users.
Combining App, Record Type, and Profile ensures other agents retain their existing App Default page while targeting only the specified user subset.

Key Concept

Lightning Record Page Activation Precedence (App, Record Type, and Profile Assignment)
Estimated Time:1m 15s
Question 860Question →

A Salesforce Administrator needs to configure appropriate access controls and security settings for several distinct operational requirements. Match each business security requirement to the correct Salesforce administrative feature.

Click a left item, then click its matching right item

Items

Completely deny login access to users of a specific profile when they attempt to log in outside approved shift hours.
Hide a sensitive custom field on the Contact record from all users assigned to a profile regardless of page layout assignments.
Restrict profile users from logging in from unrecognized IP addresses by denying access completely rather than prompting for identity verification.
Grant Read and Edit object permissions on a custom Project object to two specific sales reps without modifying their existing profile.

Matches

Show answer & explanation

Answer

Each security requirement matches its dedicated security control: Shift hour login restriction matches Profile Login Hours; sensitive field hiding matches Field-Level Security (FLS); strict IP login restriction with total denial matches Profile Login IP Ranges; and granting extra permissions to specific users matches Permission Sets.
Matching security requirements to Salesforce administrative capabilities requires evaluating the layer of security targeted: Profile Login Hours control authentication timeframes; Field-Level Security (FLS) controls field access globally regardless of layout; Profile Login IP Ranges enforce strict network boundary denials; and Permission Sets provide flexible, targeted permission extensions without profile duplication.

Step-by-Step Solution

1
Analyze time-based access control requirement
Identified Profile Login Hours as the feature that enforces hard login window boundaries per profile.
Profile Login Hours prevent users from authenticating outside specified schedules.
2
Analyze data sensitivity requirement for specific fields
Identified Field-Level Security (FLS) as the authoritative control for hiding fields across all interfaces.
Page layouts only control layout visibility, whereas FLS enforces security across API, reports, and detail pages.
3
Evaluate network security restriction mechanisms
Identified Profile Login IP Ranges as the feature that denies access outside specified IP bounds.
Organization-wide Network Access allows logins outside IP ranges via identity verification, whereas Profile Login IP Ranges explicitly deny access.
4
Determine method for granting selective access expansion
Identified Permission Sets as the mechanism to add object access to selected users.
Profiles establish baseline access; permission sets grant incremental access to specific individual users adhering to the principle of least privilege.

Key Concept

Salesforce Security Layering: Profiles, Permission Sets, FLS, and Login Restrictions
PreviousPage 43 / 90Next
All practice questions — Salesforce Certified Administrator | Examkin