Examkin

All practice questions

1784 questions

All types1,784Multiple choice918Multiple select587Matching142Ordering137
Question 961Question →

Solaris Renewable Energy wants to streamline support operations by configuring Salesforce Service Cloud case collaboration features. Match each Salesforce Case Collaboration configuration tool on the left to its corresponding operational business function on the right.

Click a left item, then click its matching right item

Items

Predefined Case Team
Feed Item Visibility Control
Case Team Role
Case Feed Publisher Layout

Matches

Show answer & explanation

Answer

Predefined Case Team matches with grouping standard users and assigning designated collaboration functions; Feed Item Visibility Control matches with restricting feed items from external Experience Cloud users; Case Team Role matches with determining record-level access grants (Private, Read Only, Read/Write); Case Feed Publisher Layout matches with customizing quick actions displayed in the agent workspace.
Each feature is accurately matched to its administrative purpose: Predefined Case Teams group standard members for rapid assignment; Feed Item Visibility protects internal notes from external view; Case Team Roles define record permissions (Read Only vs Read/Write); and Publisher Layouts control available feed actions.

Step-by-Step Solution

1
Analyze the core purpose of a Predefined Case Team.
Identify that Predefined Case Teams save administrative effort by grouping standard users with assigned roles so they can be added to cases in a single action.
Predefined teams are intended for standard cross-functional groups that frequently collaborate on cases.
2
Evaluate the mechanism for restricting external visibility in Case Feed.
Identify Feed Item Visibility control, which permits agents to mark posts and emails as 'Internal Only'.
This prevents sensitive internal collaboration from leaking to Experience Cloud community members.
3
Examine how access rights are established within Case Teams.
Determine that Case Team Roles carry access level configurations (Private, Read Only, or Read/Write).
The access level on the role dictates the actual record access granted to team members.
4
Examine how publisher actions are surfaced on Case Feed pages.
Determine that Publisher Layouts govern which actions appear in the feed editor interface.
Publisher layouts customize the feed interface for different user profiles and record types.

Key Concept

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

A company uses a custom object named Course_Feedback__c to track feedback provided by employees for training courses managed in a custom object named Training_Course__c. Management has specified two key operational requirements:
1. If a Training_Course__c record is deleted, all associated Course_Feedback__c records must be automatically removed from the system.
2. Administrators must display the total count of feedback submissions directly on the Training_Course__c detail page using standard declarative functionality.

Which two configuration steps should the Salesforce Administrator perform to satisfy these requirements? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Create a Master-Detail relationship field on the Course_Feedback__c object that references the Training_Course__c object.; Create a Roll-Up Summary field on the Training_Course__c object to aggregate the total count of related Course_Feedback__c records.

Answer

The administrator must create a Master-Detail relationship field on Course_Feedback__c pointing to Training_Course__c, and create a Roll-Up Summary field on Training_Course__c using the COUNT function.
To satisfy both requirements natively in Salesforce without code, a Master-Detail relationship must be established on the detail object (Course_Feedback__c). This automatically enforces cascading deletion of feedback records whenever a training course is deleted. Additionally, establishing a Master-Detail relationship enables the creation of a standard Roll-Up Summary field on the master object (Training_Course__c) to count related feedback records.

Step-by-Step Solution

1
Analyze the deletion requirement
Automatic deletion of child records when a parent record is deleted requires a Master-Detail relationship rather than a Lookup relationship.
Master-Detail relationships natively support cascade deletion where deleting the master record automatically deletes all associated detail records.
2
Analyze the roll-up count requirement
A native Roll-Up Summary field must be created on the master object (Training_Course__c).
Declarative Roll-Up Summary fields are exclusively available on the master side of a Master-Detail relationship.
3
Select the correct implementation steps
Define the Master-Detail relationship field on Course_Feedback__c and add the Roll-Up Summary field to Training_Course__c.
Custom relationship fields are defined on the child object referencing the parent, while Roll-Up Summary fields are created on the master parent object.

Key Concept

Master-Detail Relationship Capabilities and Roll-Up Summary Field Requirements
Question 963Question →

Apex Health Logistics wants to set up a dedicated internal IT Help Desk workflow on the Case object. The IT team requires a customized case lifecycle with specific Case Status values ('New', 'Assigned', 'In Progress', 'Resolved') that differ from the standard Customer Support case lifecycle. Which sequence of administrative steps must be completed to enforce these specific Case Status picklist values for IT cases?

Show answer & explanation

Answer: Create a new Support Process selecting the required Case Status values, then create a Case Record Type linked to that Support Process.

Answer

Create a new Support Process selecting the required Case Status values, then create a Case Record Type linked to that Support Process.
To customize Case Status picklist values for different business processes, a Salesforce Administrator must first build a Support Process to select the relevant status options. Next, the administrator creates a Case Record Type and links it to the newly created Support Process.

Step-by-Step Solution

1
Identify the prerequisite dependency for custom Case Status values.
Recognize that standard Case Status picklist options are controlled by Support Processes.
In Salesforce, business processes (such as Support Processes for Cases or Sales Processes for Opportunities) must exist prior to configuring corresponding Record Types.
2
Determine the mandatory administrative sequence.
First create the Support Process containing the desired status picklist values, then associate that Support Process with the new Case Record Type.
When defining a new Case Record Type, selecting an existing Support Process is a required step to establish the allowable Case Status lifecycle.

Key Concept

Support Process and Case Record Type Dependency
Question 964Question →

Starlight Media uses a custom object named Content_Project__c to manage media production records. The Organization-Wide Default (OWD) for Content_Project__c is set to Private. Executive management wants Regional Producers to share Read/Write access to their Content_Project__c records with assigned Finance Managers across different branches. However, corporate compliance requires that Executive Vice Presidents located above the Finance Managers in the role hierarchy do NOT automatically receive access to these shared records unless explicit permission is granted. Which TWO actions must the Salesforce Administrator take to fulfill these security requirements?

Select all that apply

Show answer & explanation

Answer: Deselect the 'Grant Access Using Hierarchies' checkbox on the Content_Project__c custom object definition.; Create a sharing rule to grant Read/Write access of Content_Project__c records to the Finance Managers role or public group.

Answer

The Salesforce Administrator must deselect 'Grant Access Using Hierarchies' on the custom object definition and create a sharing rule to grant Read/Write access to the Finance Managers role.
Organization-Wide Defaults define the baseline record access when users do not own a record. Setting Content_Project__c to Private prevents unauthorized access. To share records with Finance Managers, a sharing rule is required. To prevent Executive Vice Presidents higher in the role hierarchy from automatically gaining access to records shared with Finance Managers, the 'Grant Access Using Hierarchies' option on the custom object must be unchecked.

Step-by-Step Solution

1
Disable automatic access propagation up the role hierarchy.
Deselecting 'Grant Access Using Hierarchies' on Content_Project__c stops users in superior roles from automatically inheriting record access.
Complies with the strict security requirement preventing Executive Vice Presidents from automatically viewing shared records.
2
Configure a sharing rule for the target user group.
Creating an owner-based or criteria-based sharing rule grants Read/Write access specifically to Finance Managers.
Provides required access to Finance Managers while keeping the OWD baseline at Private.

Key Concept

Role Hierarchy and Sharing Rules
Question 965Question →

Apex Financial Technologies is launching a specialized Wealth Management sales team alongside its existing Retail Banking division. The Wealth Management division requires a customized pipeline with specific Opportunity Stages (such as 'Portfolio Audit' and 'Compliance Review') that differ from standard retail sales stages. The Salesforce administrator has already created the necessary stage picklist values on the Opportunity object.

When attempting to assign these new stage picklist values to a newly created 'Wealth Management' Opportunity Record Type, the administrator notices that the Stage picklist field is not available for editing directly within the Record Type picklist configuration section.

Which administrative action must the administrator perform to resolve this issue and enable the required stages for the Wealth Management record type?

Show answer & explanation

Answer: Create a new Sales Process, select the required Wealth Management stages, and associate that Sales Process with the Wealth Management Opportunity Record Type.

Answer

The administrator must create a new Sales Process, select the specific stage values required for Wealth Management, and assign that Sales Process to the Wealth Management Opportunity Record Type.
In Salesforce, the Opportunity Stage field is a special picklist that cannot be configured directly within Record Type picklist settings. Instead, administrators must create a Sales Process to define the set of stage values (along with probability and forecast category) for a specific sales lifecycle. Once the Sales Process is created, it is assigned to the Opportunity Record Type, which in turn makes those specific stages available to users assigned to that record type.

Step-by-Step Solution

1
Identify the relationship between Opportunity Stages and Record Types.
Recognize that unlike standard picklist fields, the Stage picklist on the Opportunity object is controlled exclusively via Sales Processes rather than direct record type picklist editing.
Salesforce architecture mandates that Opportunity Stages, Lead Statuses, Case Statuses, and Solution Statuses are managed by business process entities.
2
Create a dedicated Sales Process for the new business unit.
Define a Sales Process that filters master stage values down to 'Portfolio Audit', 'Compliance Review', and other relevant stage picklist values.
The Sales Process determines the subset of stages, probability percentages, and forecast categories visible to users for a specific sales path.
3
Associate the Sales Process with the Opportunity Record Type.
Assign the created Sales Process when configuring the 'Wealth Management' Opportunity Record Type.
An Opportunity Record Type cannot exist without an assigned Sales Process, which drives the available stage values for records assigned to that record type.

Key Concept

Opportunity Stages and Sales Process Association
Estimated Time:2m 0s
Question 966Question →

Match each Salesforce Opportunity Team feature or sharing configuration setting with its corresponding record access behavior or operational capability.

Click a left item, then click its matching right item

Items

Default Opportunity Team
Opportunity Team Member Read/Write Access
Implicit Parent Account Access
Opportunity Access set to Private on Team Member

Matches

Show answer & explanation

Answer

Default Opportunity Team matches automatically populating a predefined list of collaborators onto new opportunities; Opportunity Team Member Read/Write Access matches allowing team members to view and edit details without grant of delete privileges; Implicit Parent Account Access matches automatically granting Read-Only visibility to the parent Account under Private OWD; Opportunity Access set to Private on Team Member matches restricting the team member from viewing or editing the opportunity record.
Default Opportunity Teams automate setup for newly created records, Read/Write access grants editing without deletion rights, implicit sharing provides parent account Read-Only visibility under Private OWD settings, and Private access blocks opportunity record access for specific members.

Step-by-Step Solution

1
Identify the purpose of Default Opportunity Teams.
Default Opportunity Teams automate team assignment by adding user-configured team members to newly created opportunities.
This streamlines setup for sales reps who consistently collaborate with the same team.
2
Analyze Opportunity Team access permissions.
Read/Write permissions allow viewing and editing opportunity fields but exclude record deletion privileges.
Deletion rights in Salesforce require record ownership, explicit Delete permissions, or Modify All Data.
3
Determine implicit sharing behavior for child records.
Adding a user to an Opportunity Team automatically grants implicit Read-Only access to the associated parent Account record under a Private OWD model.
Salesforce architecture enforces implicit parent sharing so team members have context regarding the associated account.
4
Evaluate the Private team member opportunity access setting.
Setting access level to Private for a team member blocks access to the opportunity record.
Private access overrides opportunity visibility for that designated team member.

Key Concept

Opportunity Teams and Team Selling Access Behaviors
Question 967Question →

A Salesforce Administrator at CloudVibe Systems needs to configure Case Collaboration tools to satisfy several distinct business requirements for the customer support department. Match each Salesforce Case Collaboration feature to its corresponding operational business requirement.

Click a left item, then click its matching right item

Items

Predefined Case Teams
Case Team Roles
Feed Item Visibility
Case Feed Publisher Layouts

Matches

Show answer & explanation

Answer

Predefined Case Teams matches with adding a standard group of cross-functional users to cases. Case Team Roles matches with specifying the record-level access granted to collaborative users. Feed Item Visibility matches with restricting internal Chatter notes from external portal users. Case Feed Publisher Layouts matches with customizing quick actions displayed in the agent feed interface.
Predefined Case Teams allow adding standard groups of users to cases. Case Team Roles specify the record access level granted to members. Feed Item Visibility restricts internal notes from being viewed by external Experience Cloud customers. Case Feed Publisher Layouts configure the publisher actions available in the feed.

Step-by-Step Solution

1
Identify the purpose of Predefined Case Teams.
Predefined Case Teams enable pre-configuring groups of users and their roles for quick attachment to case records.
This satisfies the requirement of efficiently adding a standard set of cross-functional users to high-tier or complex cases.
2
Determine the function of Case Team Roles.
Case Team Roles configure the exact record access level (Read Only, Read/Write) granted to assigned team members.
Record sharing access for team members is governed directly by the role assigned within the Case Team.
3
Analyze how feed privacy is governed between internal staff and external portal customers.
Feed Item Visibility grants control over whether Chatter posts or log entries are marked Internal Only.
This controls visibility, ensuring internal collaborative posts remain invisible to external portal users.
4
Evaluate how actions in the Case Feed are exposed.
Case Feed Publisher Layouts control the specific set of quick action tools (Email, Log a Call, Post) available to agents.
Publisher layouts customize the quick action buttons exposed in the user's feed publisher bar.

Key Concept

Salesforce Case Collaboration Tools (Predefined Case Teams, Case Team Roles, Feed Item Visibility, and Publisher Layouts)
Estimated Time:1m 30s
Question 968Question →

A Salesforce Administrator at Global Logistics Corp is configuring case automation to handle enterprise support inquiries submitted via Web-to-Case and manual record creation. The requirements specify routing inbound cases to dedicated regional support queues, delivering automated confirmation emails to case contacts based on case origin, and monitoring SLA escalation timers for open cases. Which TWO statements accurately describe the execution behavior and configuration rules for Salesforce case automation?

Select all that apply

Show answer & explanation

Answer: Salesforce allows only one active Assignment Rule and one active Auto-Response Rule at any given time, with each rule evaluating entries sequentially until a match is found.; Case Escalation Rules evaluate elapsed time using the Business Hours specified directly on the case record, defaulting to organization-wide Business Hours if unassigned.

Answer

The correct statements are that Salesforce enforces only one active Assignment Rule and one active Auto-Response Rule at a time (each with sequential entry criteria evaluation), and that Case Escalation Rules compute elapsed escalation times based on the case's assigned Business Hours or the org default.
The correct options accurately reflect Salesforce's case automation rules: only one assignment rule and one auto-response rule can be active simultaneously on the Case object (evaluating entries sequentially), and case escalation rules determine elapsed target time using the specific case record's assigned Business Hours, falling back to org-wide default business hours when unassigned.

Step-by-Step Solution

1
Analyze rule activation limits and structure for Case Assignment and Auto-Response rules.
Confirm that Salesforce permits only one active Assignment Rule and one active Auto-Response Rule per object, within which multiple rule entries are evaluated in defined numerical order.
This is a fundamental architectural rule for case automation in Salesforce Core Administration.
2
Evaluate the functional distinction between Auto-Response Rules and Assignment Rules.
Identify that Auto-Response Rules only generate auto-acknowledgment emails to external contacts and cannot alter record owner fields or assign cases to queues.
Case owner assignment is the sole responsibility of Case Assignment Rules.
3
Examine Escalation Rule elapsed time calculation mechanics.
Verify that escalation timers calculate SLA thresholds against the Business Hours field on the individual case record or default to org-wide business hours.
Business Hours dictate whether escalation clocks run continuously (24/7) or pause during non-working hours.
4
Verify system Order of Execution for case creation.
Confirm that validation rules run first, followed by Assignment Rules and Auto-Response Rules, before post-save Workflow Rules and record-triggered flows execute.
Assignment rules must assign ownership before subsequent workflow notifications or flows run.

Key Concept

Salesforce Case Automation Rules Architecture and Execution Order
Estimated Time:2m 0s
Question 969Question →

A support operations administrator at a cloud software company observes an issue with after-hours case handling. When high-severity cases enter Salesforce via Email-to-Case outside of standard company business hours, Case Assignment Rules successfully route them to the 'After-Hours Support Queue'. However, a Case Escalation Rule configured to reassign unassigned high-severity cases to an 'Executive Escalation Queue' after 2 hours fails to trigger overnight, only escalating several hours after business hours resume the following morning. The administrator verifies that the Escalation Rule and its rule entries are active and correctly configured. What is the most likely cause of this delayed escalation behavior?

Show answer & explanation

Answer: The Escalation Rule entry is set to evaluate case age using Business Hours, which pauses the escalation timer while the org is outside operational hours.

Answer

The Escalation Rule entry is set to evaluate case age using Business Hours, which pauses the escalation timer while the org is outside operational hours.
Salesforce Case Escalation Rules allow administrators to customize how case age is calculated by associating Business Hours with the rule entry or case record. When Business Hours are enabled for an escalation entry, the escalation clock only ticks during defined working hours. During non-business hours, the clock pauses entirely, causing a 2-hour escalation rule to wait until business hours resume before counting down.

Step-by-Step Solution

1
Analyze how Salesforce Case Escalation Rules process time-based criteria.
Escalation rules check how long a case has been open or unassigned against defined thresholds (e.g., 2 hours).
Understanding the clock calculation mechanism is necessary to debug delayed escalation actions.
2
Evaluate the impact of Business Hours settings on the escalation timer.
If Business Hours are specified on the case or escalation rule entry, elapsed time is counted only during defined business hours. Time elapsed during non-business hours is ignored.
Cases created outside business hours will have their escalation countdown paused until the business hours clock starts.
3
Determine why the case only escalated the following morning.
The 2-hour escalation timer began counting once business hours started the next morning, triggering the escalation action 2 business hours later.
This confirms that Business Hours configuration is the root cause of the observed delay.

Key Concept

Business Hours impact on Case Escalation Rule timers
Question 970Question →

An administrator at a financial consulting firm needs to restrict access to sensitive audit documentation attached to Opportunity records. Even though multiple sales team members have Read/Write access to the Opportunity records, the administrator must ensure that only the file owner and explicit file collaborators can view these attached documents. Which configuration change should the administrator make to satisfy this requirement?

Show answer & explanation

Answer: Set the File Privacy on Records option to Private on Record for the target files.

Answer

Set the File Privacy on Records option to Private on Record for the target files.
The 'File Privacy on Records' feature allows administrators and file owners to override default file inheritance on records. By changing this property to 'Private on Record', users who have access to the Opportunity will no longer automatically see the attached file unless explicitly granted access.

Step-by-Step Solution

1
Identify the file sharing behavior in Salesforce Lightning Experience when files are attached to records.
By default, files attached to a record inherit access from the parent record ('Visible to Anyone with Access to the Record').
Standard record sharing grants visibility of attached Salesforce Files to anyone who can view the record.
2
Determine the appropriate Salesforce Files property to override parent record access inheritance.
The 'File Privacy on Records' property can be modified on the file detail page or via API to 'Private on Record'.
This setting restricts file visibility so that users with access to the record cannot view the file unless they are the file owner or have explicit file sharing permissions.

Key Concept

File Privacy on Records in Salesforce Files
Estimated Time:2m 0s
Question 971Question →

A support team lead at a telecommunications enterprise requires the ability to publish draft articles in Salesforce Knowledge. The Salesforce administrator has already granted the user Read, Create, Edit, and Delete object permissions on Knowledge articles via a permission set, and data category visibility is correctly configured. However, the user still cannot publish draft articles. Which configuration requirement must the administrator complete to enable article publishing capabilities for this user?

Show answer & explanation

Answer: Check the Knowledge User feature license checkbox on the user's detail record.

Answer

Check the Knowledge User feature license checkbox on the user's detail record.
In Salesforce Knowledge, users must be explicitly assigned the 'Knowledge User' feature license on their User record to create, edit, publish, archive, or delete articles. Even if a user has full object permissions and permission set permissions, publishing actions remain disabled without this feature license.

Step-by-Step Solution

1
Identify the missing requirement for publishing Knowledge articles.
Publishing articles requires both proper object/article permissions and an assigned Knowledge User feature license.
Salesforce Knowledge authoring and publishing features are locked until the user's account is provisioned with a Knowledge User license.
2
Locate where feature licenses are assigned in Salesforce Setup.
Navigate to Setup > Users > Users and edit the target user's record.
Feature licenses like Knowledge User are enabled via a simple checkbox on the user detail page.
3
Enable the Knowledge User checkbox.
The user is now licensed to use Knowledge authoring capabilities, including publishing draft articles.
Enabling the feature license activates article publishing tools in the UI when paired with existing permissions.

Key Concept

Knowledge User Feature License Assignment
Question 972Question →

Vanguard Solar Tech maintains an Organization-Wide Default (OWD) of Private for Cases. Support operations requires a mechanism to allow Tier 2 support engineers and third-party contractors to collaborate on complex cases on a per-case basis without changing case ownership. Contractors require Read Only access, whereas Tier 2 engineers require Read/Write access. Additionally, support agents using the Case Feed must be able to publish posts that are visible exclusively to internal staff, while keeping other posts visible to Experience Cloud portal customers.

Which two administrative configurations should be implemented to fulfill these collaboration and visibility requirements? (Select 2)

Select all that apply

Show answer & explanation

Answer: Define Case Team Roles with explicit access levels (Read Only for contractors and Read/Write for Tier 2 engineers) and utilize Predefined Case Teams.; Enable Feed Item Visibility on the Case layout to allow support agents to specify post visibility as either Internal Users or All Users.

Answer

The correct configurations are defining Case Team Roles with predefined access levels (Read Only and Read/Write) via Predefined Case Teams, and enabling Feed Item Visibility on Case Publisher Layouts to manage post visibility between internal users and external portal users.
Case Teams directly fulfill the requirement for dynamic, per-case sharing with distinct access levels (Read Only vs Read/Write) based on configured Case Team Roles and Predefined Case Teams. Simultaneously, Feed Item Visibility enables agents to control whether Chatter posts on the Case Feed are restricted to internal staff or shared with external community users.

Step-by-Step Solution

1
Analyze access requirements for case collaboration
Different user roles require distinct access levels (Read Only for contractors, Read/Write for Tier 2 engineers) on an ad-hoc/per-case basis.
When Case OWD is Private, standard sharing rules cannot dynamically assign varying access levels per case to individual users based on role.
2
Identify the appropriate Case Collaboration feature for record access
Case Teams (using Case Team Roles and Predefined Case Teams) allow adding users with specific access levels (Read Only or Read/Write) directly to individual cases.
Case Teams satisfy record sharing needs without changing ownership or overriding Private OWD globally.
3
Analyze feed visibility requirements
Agents need to toggle Chatter post visibility between internal employees and Experience Cloud portal customers.
Enabling Feed Item Visibility allows agents to choose 'Internal Users' or 'All Users' on each publisher post in the Case Feed.

Key Concept

Case Collaboration Tools (Case Teams and Case Feed Item Visibility)
Question 973Question →

A Salesforce Administrator at an environmental consultancy needs to immediately suspend access for a departing Field Analyst. When trying to deactivate the user record, the administrator receives a system error because the user is currently assigned as the Default Web-to-Lead Creator and is selected in a custom hierarchy field. Which two administrative actions should the administrator take to immediately revoke login access and resolve the issue? (Select 2 options.)

Select all that apply

Show answer & explanation

Answer: Freeze the user account from the user detail page to immediately prevent the analyst from logging in.; Reassign the system dependencies to another active user before unchecking the Active checkbox on the analyst's user record.

Answer

The administrator should freeze the user account immediately to block login access, and reassign all system dependencies to another active user before completing the deactivation.
Freezing a user account immediately blocks authentication when deactivation is prevented by active system dependencies. Reassigning those dependencies allows the user account to be successfully deactivated afterward, releasing the license.

Step-by-Step Solution

1
Freeze the user account
Login access for the departing analyst is blocked immediately.
Freezing prevents authentication without validating or breaking background configuration dependencies.
2
Reassign default creator and hierarchy references
System dependencies are removed from the departing user record.
Salesforce prevents deactivation if a user is referenced in settings such as Default Web-to-Lead Creator or active workflow references.
3
Deactivate the user account
The user record is deactivated and the user license is released back to the org pool.
Once all blocking references are transferred, deactivation can be completed successfully.

Key Concept

User Freezing vs. User Deactivation
Estimated Time:1m 30s
Question 974Question →

A Salesforce administrator at a renewable energy enterprise is configuring Lead Custom Field Mapping. The administrator creates a custom picklist field named 'Inverter Compatibility' on the Lead object and wants to map its value to a custom field on the Contact object during lead conversion. However, the newly created custom field on the Contact object does not appear in the dropdown menu under Lead Custom Field Mapping. What is the most likely cause of this issue?

Show answer & explanation

Answer: The custom field on the Contact object was created as a formula field, which is read-only and cannot receive mapped data during lead conversion.

Answer

The custom field on the Contact object was created as a formula field, which is read-only and cannot receive mapped data during lead conversion.
In Salesforce, Lead Custom Field Mapping allows custom fields on the Lead object to be converted into custom fields on the Account, Contact, or Opportunity objects. However, target fields must be editable custom fields of compatible data types. Formula fields are read-only dynamically calculated fields, so Salesforce automatically excludes them from being selected as target fields in the conversion mapping interface.

Step-by-Step Solution

1
Analyze the lead conversion custom field mapping requirements
Lead custom fields can only be mapped to custom fields on Account, Contact, or Opportunity objects.
Target fields must be writeable custom fields with compatible data types.
2
Identify constraints on target custom fields during conversion mapping
Formula fields, system fields, and standard fields cannot be targeted for custom lead field mapping.
Formula fields derive their values dynamically and cannot accept static data inputs during record creation or conversion.
3
Determine the cause of the missing Contact target field in the mapping UI
The Contact field was created as a formula field, causing Salesforce to filter it out from the available mapping target options.
Only eligible, writeable fields of compatible data types appear in the Lead Custom Field Mapping dropdown.

Key Concept

Salesforce Lead Custom Field Mapping rules and target field eligibility restrictions
Estimated Time:1m 0s
Question 975Question →

A Salesforce administrator at a maritime shipping firm is reviewing schema management settings for a new custom object named Container Audit alongside existing standard objects like Account and Shipments. Which TWO statements accurately describe the administrative capabilities and limitations when managing standard versus custom objects? (Select 2)

Select all that apply

Show answer & explanation

Answer: Custom objects can be deleted from the organization if they have no dependencies, whereas standard objects cannot be deleted.; Standard object tab labels and display names can be renamed to match company terminology, but the standard objects themselves cannot be deleted.

Answer

Custom objects can be deleted if they have no active dependencies while standard objects cannot be deleted, and standard object tab labels and display names can be renamed to match company terminology.
Custom objects can be deleted from an organization provided they do not have active software dependencies or references. Furthermore, standard object tab and field labels can be renamed in Setup to match organizational terminology, even though the standard object itself remains permanent.

Step-by-Step Solution

1
Evaluate deletion capabilities for standard and custom objects
Custom objects can be deleted from the org if unused, whereas standard objects are permanent components of the Salesforce schema.
Salesforce allows administrators to delete custom objects that contain no data or dependencies, but standard objects cannot be deleted.
2
Evaluate renaming capabilities for standard objects
Administrators can rename standard object labels and tab names in Setup under Rename Tabs and Labels.
This enables org customization to align standard terminology (such as Account or Contact) with company-specific domain terms.
3
Analyze standard field deletion and roll-up summary restrictions
Standard fields cannot be deleted from any object, and roll-up summary fields cannot be built on standard lookup relationships.
Standard fields are core schema elements, and roll-up summary functionality strictly requires a master-detail relationship structure.

Key Concept

Standard vs. Custom Object Management and Capabilities
Estimated Time:1m 30s
Question 976Question →

A Salesforce Administrator needs to update an existing data model. Currently, a custom object named `Project_Task__c` references a custom object named `Project_Plan__c` using a Lookup relationship. The business requirements state that deleting a `Project_Plan__c` record must automatically delete all associated `Project_Task__c` records. In addition, the administrator must display the total estimated hours from all related tasks on the `Project_Plan__c` record using a standard Roll-Up Summary field. Which sequence of actions should the administrator perform to fulfill these requirements?

Show answer & explanation

Answer: Verify that all `Project_Task__c` records have a populated `Project_Plan__c` field, convert the Lookup relationship to a Master-Detail relationship on `Project_Task__c`, and then create a Roll-Up Summary field on `Project_Plan__c`.

Answer

Verify that all existing child records contain a value in the lookup field, convert the Lookup relationship on the child object to a Master-Detail relationship, and create the Roll-Up Summary field on the parent object.
To calculate aggregate values via native Roll-Up Summary fields and ensure automatic deletion of child records when a parent is deleted, a Master-Detail relationship is required. Before converting an existing Lookup relationship field to Master-Detail, every child record (`Project_Task__c`) must have a value in that lookup field. Once converted, Roll-Up Summary fields can be created on the master object (`Project_Plan__c`).

Step-by-Step Solution

1
Ensure data completeness on the detail object
Every `Project_Task__c` record has a non-null value in the `Project_Plan__c` lookup field.
Salesforce requires all child records to have a parent reference before converting a Lookup relationship to a Master-Detail relationship.
2
Change field type from Lookup to Master-Detail
The relationship is updated to Master-Detail, automatically establishing cascade deletion behavior.
Master-Detail relationships natively enforce cascade deletion of detail records when a master record is deleted.
3
Create Roll-Up Summary field on `Project_Plan__c`
The total estimated hours are aggregated automatically on the master record.
Roll-Up Summary fields require a Master-Detail relationship to calculate aggregate values from detail records.

Key Concept

Lookup to Master-Detail Relationship Conversion & Roll-Up Summary Prerequisites
Question 977Question →

A sales representative at Cloud Kicks owns a high-value opportunity and adds a solution engineer to the Opportunity Team with Read/Write access to help close the deal. The Organization-Wide Default (OWD) for Accounts and Opportunities is set to Private. Despite being added to the team, the solution engineer receives an access denied error when attempting to open the parent Account record associated with the opportunity. What is the root cause preventing the solution engineer from viewing the Account record?

Show answer & explanation

Answer: The solution engineer lacks object-level Read permission for the Account object in their assigned profile or permission set.

Answer

The solution engineer lacks object-level Read permission for the Account object in their assigned profile or permission set.
In Salesforce security architecture, object-level permissions (configured via Profiles or Permission Sets) override record-level sharing settings. Opportunity Teams provide implicit record-level read access to parent Account records. However, if a user does not have Read permission on the Account object at the profile or permission set level, they cannot view any Account records regardless of team membership or sharing rules.

Step-by-Step Solution

1
Evaluate Object-Level Security vs Record-Level Sharing in Salesforce.
Object-level permissions (CRUD) defined in Profiles and Permission Sets act as the ultimate gateway; sharing rules and team access only determine which specific records a user can see if they already have object access.
Record sharing mechanisms cannot bypass object-level permissions.
2
Analyze the implicit sharing behavior of Opportunity Teams.
Adding a user to an Opportunity Team automatically grants implicit Read-Only record sharing access to the associated parent Account record.
Implicit sharing allows team members to view contextual account details.
3
Identify why implicit sharing fails in this scenario.
Because the user's Profile or Permission Set denies 'Read' permission on the Account object, the implicit record share cannot be utilized.
Without object-level Read access, Salesforce prevents users from viewing any records of that object type.

Key Concept

Interaction between Object-Level Security (Profile/Permission Set) and Record-Level Implicit Sharing in Opportunity Teams
Question 978Question →

A Salesforce Administrator needs to configure Entitlement Management with Milestone tracking to enforce Service Level Agreements (SLAs) for customer support cases. Arrange the administrative setup steps in the correct chronological order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence for configuring Entitlement Management is: 1. Enable Entitlement Management in Setup, 2. Create Milestones, 3. Create an Entitlement Process and add Milestones and Milestone Actions, and 4. Activate the Entitlement Process and associate it with customer Entitlement records.
The configuration of Entitlement Management follows a logical dependency order: First, Entitlement Management must be enabled in Setup. Next, individual Milestones representing target resolution metrics must be created. Once milestones exist, an Entitlement Process is built to group those milestones with specific warning or violation actions. Finally, the Entitlement Process is activated and linked to Entitlement records to govern incoming support cases.

Step-by-Step Solution

1
Enable foundational feature settings.
Entitlement Management features become accessible in Setup.
Salesforce feature dependencies require Entitlement Management to be enabled before creating related records and processes.
2
Define SLA milestone metrics.
Milestones like 'First Response' or 'Resolution Time' are created.
Milestones act as building blocks that must exist prior to building entitlement timelines.
3
Assemble the Entitlement Process.
An Entitlement Process incorporates the created milestones and specifies milestone actions.
The process establishes the logic and timing rules for case handling under an SLA.
4
Deploy and assign the process.
The activated Entitlement Process is linked to Entitlement records.
Entitlement processes only apply to cases once activated and assigned to relevant entitlement records.

Key Concept

Salesforce Entitlement Management Setup Sequence
Question 979Question →

The customer support manager at Vanguard Global Freight needs support agents to easily collaborate with technical specialists on complex delivery issues. The manager specifies that case owners must be able to add a standardized group of internal experts (such as a logistics analyst and a legal counsel) to individual cases with predefined access levels (Read Only or Read/Write) and send automated email alerts upon assignment. Which feature should the Salesforce Administrator implement to satisfy these business requirements?

Show answer & explanation

Answer: Predefined Case Teams with custom Case Team Roles and member notifications enabled

Answer

Predefined Case Teams with custom Case Team Roles and member notifications enabled
Predefined Case Teams allow Salesforce Administrators to assemble groups of users who frequently work together on cases. Administrators define Case Team Roles, assign specific access levels (Private, Read Only, or Read/Write) to each role, and enable automatic email notifications so team members are alerted when added to a case.

Step-by-Step Solution

1
Analyze the operational requirement
Identified the need for case owners to grant record-level access (Read Only/Read-Write) to a standardized group of users on specific cases with automated notification.
The requirement asks for ad-hoc collaborative access for a group of specialists on individual cases.
2
Evaluate Salesforce collaboration features
Case Teams allow defining specific roles (with associated access levels) and creating predefined teams that can be added to cases in one step, alongside sending assignment notifications.
Standard Sharing Rules or Public Groups apply globally based on criteria, whereas Chatter feed tracking does not grant record access permissions.
3
Select the correct administrative configuration
Configure Case Team Roles, set up Predefined Case Teams, and enable case team member notification preferences.
This directly fulfills all specified criteria in the scenario without over-granting permissions.

Key Concept

Case Teams and Case Collaboration Tools
Question 980Question →

A Salesforce Administrator at Quantum Dynamics is setting up distinct case management processes for technical support and billing inquiries. Match each Salesforce Service Cloud administrative element on the left with its precise operational role in configuring these case workflows on the right.

Click a left item, then click its matching right item

Items

Support Process
Case Record Type
Page Layout
Custom Picklist Field

Matches

Show answer & explanation

Answer

Support Process matches with filtering available Case Status picklist values; Case Record Type matches with linking a Support Process to profiles and non-Status picklists; Page Layout matches with controlling field and section placement; Custom Picklist Field matches with defining category options editable per Record Type.
Each administrative component handles a distinct layer of case management: Support Processes define the valid Case Status lifecycle stages, Record Types bind a Support Process with Page Layouts and non-Status picklists, Page Layouts govern page design and field arrangement, and Custom Picklist Fields define configurable field values across record types.

Step-by-Step Solution

1
Identify the element responsible for Case Status picklist filtering.
Recognize that the Support Process controls Case Status values exclusively.
Record Types cannot filter Case Status directly; they require a underlying Support Process to define status values.
2
Identify the element linking Support Processes, Page Layouts, and non-Status picklists.
Associate Case Record Type with this umbrella configuration function.
Record Types serve as the primary bridge connecting Page Layouts, non-Status picklist value assignments, and Support Processes.
3
Determine which component controls visual structure on record pages.
Match Page Layout to field, section, and related list arrangement.
Page Layouts govern user interface layout structure rather than picklist business logic.
4
Determine how custom object-level picklist values are categorized.
Match Custom Picklist Field to category options configured per Record Type.
Standard and custom picklists (excluding Case Status) are edited directly at the Record Type configuration level.

Key Concept

Prerequisite sequence and functional separation between Support Processes, Case Record Types, and Page Layouts.
PreviousPage 49 / 90Next
All practice questions — Salesforce Certified Administrator | Examkin