All practice questions

1784 questions

Question 801Question

An organization is setting up a dedicated Return Merchandise Authorization (RMA) handling team. The RMA team requires a specialized set of Case Status picklist values that differ from standard customer support, as well as a restricted list of available Case Origin values. Which TWO administrative configuration steps are required to fulfill these requirements? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Create a custom Support Process to define the specific subset of Case Status picklist values for RMA cases.; Create an RMA Case Record Type linked to the new Support Process, and edit the Record Type picklists to select allowed Case Origin values.

Answer

The correct steps are creating a dedicated Support Process to define the subset of Case Status picklist values, and creating an RMA Case Record Type linked to that Support Process while editing its picklist settings to restrict Case Origin values.
On the Case object, controlling Case Status values requires a dedicated Support Process before assigning it to a Case Record Type. Once the Record Type is created and linked to the Support Process, standard picklist fields like Case Origin can be customized directly on the Record Type detail page.

Step-by-Step Solution

1
Identify prerequisites for custom Case Status lifecycles on the Case object.
Recognize that Case Status picklist values are controlled exclusively through Support Processes, not directly on the record type.
Salesforce mandates a Support Process whenever different case lifecycles/statuses are needed.
2
Configure the Support Process for RMA cases.
A Support Process containing only the relevant RMA status values is created and saved.
This establishes the business process lifecycle needed for the RMA team.
3
Create the RMA Case Record Type and assign picklists.
The Record Type links to the Support Process created in Step 2, and additional standard picklists (such as Case Origin) are customized directly under the Record Type configuration.
Record Types correlate page layouts, support processes, and non-status picklist restrictions.

Key Concept

Configuring Support Processes as a prerequisite for Case Record Types with customized picklists
Question 802Question

Match each Salesforce Service Cloud element to its primary role in configuring customized case management workflows.

Click a left item, then click its matching right item

Items

Support Process
Case Record Type
Page Layout

Matches

Show answer & explanation

Answer

Support Process matches with defining Case Status picklist values; Case Record Type matches with associating a Support Process with profiles and layout assignments; Page Layout matches with controlling field and related list organization.
Support Processes determine which Case Status values are accessible across a case lifecycle. Case Record Types act as the container linking a Support Process and Page Layout to specific user profiles. Page Layouts define the visual organization of fields and components on the page.

Step-by-Step Solution

1
Identify the specific component responsible for Case Status picklist values.
Recognize that Support Processes directly select and limit valid Case Status values.
Before assigning distinct status lifecycles to record types, a Support Process must be created.
2
Identify how Support Processes and layouts are assigned to users.
Associate Case Record Type with tying the Support Process and Page Layout to profile assignments.
Record types allow different business units to see different picklist values and page layouts.
3
Identify the user interface arrangement component.
Associate Page Layout with organizing record fields, sections, and related lists.
Page layouts dictate the visual display and structure of the detail page.

Key Concept

Support Processes and Case Record Type Architecture
Question 803Question

An administrator at Universal Containers is optimizing the Lightning Sales Console to enhance productivity for an inside sales team. The reps need to perform single-click multi-step actions (such as updating an Opportunity Stage and logging a follow-up Task simultaneously) and ensure that when opening related records from an Account, they open nested as subtabs under the primary Account record rather than independent workspace tabs.

Which TWO features or configurations should the administrator implement to fulfill these business requirements? (Select 2 options)

Select all that apply

Show answer & explanation

Answer: Add the Macros component to the app's Utility Bar in the Lightning App Builder.; Configure console tab navigation rules in the App Manager to open child records as subtabs under the parent Account.

Answer

The administrator should add the Macros component to the app's Utility Bar and configure console tab navigation rules to open child records as subtabs under the parent Account workspace tab.
Adding Macros to the Utility Bar allows reps to automate multi-step field updates and activity logging in one click. Setting workspace tab navigation rules ensures child records open nested as subtabs under the parent Account to preserve rep workflow context.

Step-by-Step Solution

1
Evaluate requirement for single-click multi-step activity automation.
Identify Macros in the console Utility Bar as the standard tool for executing sequential field updates and task creations simultaneously.
Macros automate routine user tasks within console applications directly from the Utility Bar.
2
Evaluate requirement for record tab hierarchy context.
Identify Console Navigation Rules in App Settings as the mechanism for nesting records.
Navigation rules dictate whether related child records open as primary workspace tabs or as subtabs beneath the master record.

Key Concept

Sales Console Productivity Automation and Tab Navigation Rules
Question 804Question

An enterprise organization has set the Organization-Wide Defaults (OWD) for both Account and Opportunity objects to Private. A sales executive who owns a high-value Opportunity adds a sales specialist as a member of the Opportunity Team with Read/Write access to collaborate on the deal. The sales specialist has standard profile permissions for Accounts but currently has no prior record-level sharing access to the specific Account associated with this Opportunity. Which access capability does the sales specialist automatically receive on the parent Account record upon being added to the Opportunity Team?

Show answer & explanation

Answer: Read-Only access to the associated Account record is automatically granted via implicit sharing.

Answer

Read-Only access to the associated Account record is automatically granted via implicit sharing.
In Salesforce, Opportunities are child records of Accounts. When a user is added to an Opportunity Team, Salesforce automatically grants implicit Read-Only access to the parent Account record if the user lacks existing access, enabling them to view the Account details associated with their Opportunity.

Step-by-Step Solution

1
Analyze the implicit sharing behavior between child Opportunity records and parent Account records in Salesforce.
Salesforce enforces parent-child security dependencies where accessing an Opportunity requires access to its parent Account.
Determining how record access propagates across standard relational objects is essential for access management.
2
Evaluate the specific access level granted on the parent Account when adding a user to an Opportunity Team.
When added to an Opportunity Team, Salesforce grants implicit Read-Only access to the parent Account record if the user does not already have access to that Account.
Implicit sharing ensures users can view necessary context on the parent entity without elevating their permissions to edit the Account itself.

Key Concept

Implicit Account Sharing via Opportunity Teams
Question 805Question

A Salesforce administrator at a cloud software logistics enterprise is documenting the system process execution flow during lead conversion. When a sales representative converts a qualified lead record in Salesforce, system validation, target record instantiation, field mapping, downstream automation, and lead status updates occur in a strict sequential order. Place the following lead conversion system execution 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 execution sequence for Salesforce lead conversion is: 1) Lead validation rules evaluate eligibility, 2) Target Account, Contact, and Opportunity records are created or matched, 3) Lead custom field mapping populates data on target records, 4) Record-triggered flows and automations execute on target records, and 5) The original Lead status updates to Converted and becomes read-only.
The correct sequence begins with evaluating validation rules on the Lead object to verify data accuracy prior to conversion. Next, Salesforce creates or links the target Account, Contact, and optional Opportunity records. Custom field mapping then populates data onto those target records. After target fields are populated, record-triggered flows and automations execute on the destination objects. Finally, the original Lead record status updates to Converted and the record becomes read-only.

Step-by-Step Solution

1
Evaluate Lead Eligibility
Validation rules on the Lead object run prior to any record creation.
If lead validation fails, conversion stops immediately, preventing incomplete downstream record creation.
2
Instantiate Destination Records
Target Account, Contact, and optional Opportunity records are created or matched.
Destination objects must exist in the system to serve as targets for data transfer.
3
Apply Lead Custom Field Mapping
Mapped lead custom field values populate target record fields.
Custom Lead Field Mapping configurations copy lead values onto target records before post-save target automation runs.
4
Execute Target Object Automation
Triggers, workflows, and record-triggered flows fire on Account, Contact, and Opportunity records.
Newly populated target records trigger downstream business automation routines.
5
Update Lead Record Lifecycle Status
The Lead status updates to Converted (IsConverted = true) and becomes read-only.
The lead lifecycle completes after all target records are populated and target automations finish successfully.

Key Concept

Salesforce Lead Conversion Order of Execution
Estimated Time:1m 30s
Question 806Question

Summit Global Solutions uses a custom currency field named Executive_Bonus__c on the Opportunity object. Currently, 20 sales managers and 100 sales representatives share the standard 'Sales User' profile. Business requirements dictate that only the 20 sales managers should be able to view and edit Executive_Bonus__c, while sales representatives must not have access to this field in reports, record pages, or API integrations. Which configuration strategy should the Salesforce Administrator implement to fulfill this requirement?

Show answer & explanation

Answer: Remove Read and Edit permissions for Executive_Bonus__c on the Sales User profile, create a Permission Set that grants Read and Edit access to Executive_Bonus__c, and assign the Permission Set to the 20 sales managers.

Answer

Remove Read and Edit permissions for the field on the base profile, create a Permission Set granting Read and Edit access to the field, and assign it to the users who require access.
The correct solution enforces a secure baseline by removing Field-Level Security (FLS) read/edit rights on the common profile, then uses a Permission Set to grant access additively to the sales managers. FLS restricts field visibility universally across reports, APIs, and record detail pages.

Step-by-Step Solution

1
Analyze the baseline access requirement
Since the majority of users (100 sales reps) should not access Executive_Bonus__c, the baseline Field-Level Security (FLS) on the shared profile must restrict both Read and Edit access.
Field-Level Security is the primary control for securing field visibility across all interfaces including UI, reports, and APIs.
2
Determine the optimal authorization method for the subset of users
Create a Permission Set specifically granting Read and Edit access to Executive_Bonus__c and assign it to the 20 sales managers.
Salesforce security architecture relies on profiles for restrictive baselines and permission sets for additive access, avoiding redundant profile maintenance.

Key Concept

Field-Level Security and Permission Sets
Question 807Question

Horizon Healthcare operates two distinct sales divisions: Government Contracts and Commercial Medical Equipment. The Government Contracts division requires a customized sequence of opportunity stages (Qualified, RFP Submitted, Technical Review, Awarded, Closed Lost), whereas the Commercial Medical Equipment division uses the standard Salesforce sales lifecycle. The system administrator must ensure that sales representatives in the Government Contracts division can only view and select their division's specific stage values when working on opportunities.

Which TWO administrative configuration steps must be performed to meet these business requirements?

Select all that apply

Show answer & explanation

Answer: Create a custom Sales Process for Government Contracts and select only the required stage picklist values.; Create an Opportunity Record Type for Government Contracts and associate it with the newly created Sales Process.

Answer

To enforce a unique set of opportunity stages for a specific business unit, an administrator must create a dedicated Sales Process containing the appropriate stage picklist values and then assign that Sales Process to a custom Opportunity Record Type.
In Salesforce, Opportunity Stage values are governed by Sales Processes. To display a tailored set of stages to a specific user group, an administrator must create a custom Sales Process selecting the appropriate stage values, and then assign that Sales Process to an Opportunity Record Type designated for those users.

Step-by-Step Solution

1
Navigate to Setup > Sales Processes and create a new Sales Process specifically for Government Contracts.
Defines the subset of stage picklist values (Qualified, RFP Submitted, Technical Review, Awarded, Closed Lost) required for this business unit.
Opportunity stage picklist availability is controlled at the Sales Process level rather than directly on the object's picklist settings.
2
Navigate to Object Manager > Opportunity > Record Types and create a new Record Type for Government Contracts.
Links the custom Sales Process to the new Record Type.
Record Types associate the defined Sales Process with appropriate page layouts and assign access to user profiles.

Key Concept

Sales Process and Record Type Mapping for Opportunity Stages
Question 808Question

An administrator at a corporate event planning company needs to configure a relationship between the standard Account object and a custom object named Vendor_Contract__c. The business requirement states that deleting an Account record must automatically delete all associated Vendor_Contract__c records. In addition, management requires a roll-up summary field on the Account object to summarize total contract values. Which relationship configuration should the administrator implement?

Show answer & explanation

Answer: Create a Master-Detail relationship on Vendor_Contract__c with Account as the master object.

Answer

Create a Master-Detail relationship on Vendor_Contract__c with Account as the master object.
Creating a Master-Detail relationship on the child object (Vendor_Contract__c) with Account as the master fulfills both business requirements. In a Master-Detail relationship, deleting a master record automatically deletes all associated detail records, and master objects support standard roll-up summary fields to aggregate detail record values.

Step-by-Step Solution

1
Analyze the deletion cascade and summary requirements.
The requirements demand that parent record deletion cascades to detail records and that the parent object supports roll-up summary fields.
Master-Detail relationships natively enforce cascading deletion from master to detail records and enable roll-up summary fields on the master object.
2
Determine object placement for the relationship field.
The custom relationship field must be created on the child object (Vendor_Contract__c) pointing to the parent object (Account).
In Salesforce data modeling, the child detail record always holds the foreign key relationship field to the parent master record.

Key Concept

Master-Detail Relationship Capabilities and Limitations
Question 809Question

A sales manager needs a solutions architect to collaborate on a complex opportunity deal. The Organization-Wide Default for Opportunities is set to Private. The manager wants the opportunity owner to easily grant the solutions architect Read/Write access to this specific deal without giving them access to all opportunities across the organization. Which Salesforce feature should the administrator enable to meet this requirement?

Show answer & explanation

Answer: Opportunity Teams

Answer

Opportunity Teams should be enabled to allow deal-level collaborative access.
Opportunity Teams enable team selling, allowing opportunity owners to add cross-functional team members (such as solutions architects) to individual deals and grant them specific access permissions (Read Only or Read/Write).

Step-by-Step Solution

1
Analyze requirement
Access is required for a specific opportunity record without altering org-wide access.
The scenario requires ad-hoc, record-level sharing for team collaboration.
2
Evaluate features
Opportunity Teams allow opportunity owners to manually invite users and assign Read Only or Read/Write access to individual deals.
This directly fulfills the requirement of deal-specific sharing while preserving overall Private OWD settings.

Key Concept

Opportunity Teams and Team Selling Access
Question 810Question

A marketing administrator is setting up a new campaign to track event attendees. The marketing manager wants to ensure that reports accurately reflect which prospects actively engaged with the campaign. Which setting on the Campaign Member Status determines whether a member is counted as a response in campaign reporting?

Show answer & explanation

Answer: The Responded checkbox field on the Campaign Member Status value

Answer

The Responded checkbox field on the Campaign Member Status value determines whether a campaign member is counted as a response in reporting.
The correct option is the Responded checkbox on the Campaign Member Status value. In Salesforce, each Campaign Member Status (such as Sent, Responded, or Attended) can be marked with a Responded boolean flag. When a campaign member is updated to a status where Responded is checked, Salesforce automatically increments response counts on campaign reports and metrics.

Step-by-Step Solution

1
Identify the object responsible for tracking individual prospect engagement states within a campaign.
Campaign Member Status defines the member state (such as Sent, Responded, Attended).
Campaign response metrics aggregate members whose current status is flagged as an official response.
2
Locate the administrative setting that flags a status value as an official response.
The Responded checkbox on the Campaign Member Status record.
When checked, any campaign member assigned that status increments the Total Responses and Response Rate fields on the campaign.

Key Concept

Campaign Member Status Responded Flag
Estimated Time:1m 0s
Question 811Question

A Salesforce Administrator at a medical device manufacturing company needs to calculate and display the total number of completed service inspections on the custom parent object Medical_Device__c using data from the custom child object Inspection_Log__c. The two objects are currently connected via a Lookup relationship. When attempting to create a Roll-Up Summary field on Medical_Device__c, the Administrator finds the Roll-Up Summary field type disabled. Which two statements correctly explain this behavior or describe the required resolution steps? (Select 2 answers.)

Select all that apply

Show answer & explanation

Answer: Roll-Up Summary fields are supported only on the master object of a Master-Detail relationship and cannot be created over a Lookup relationship.; The Lookup field on Inspection_Log__c must be populated for all existing records before converting the relationship to Master-Detail.

Answer

Roll-Up Summary fields require a Master-Detail relationship, and converting an existing Lookup relationship to Master-Detail requires that all child records have a populated lookup field value.
Native Salesforce Roll-Up Summary fields are exclusively available on the master object of a Master-Detail relationship. To enable this capability when objects are connected by a Lookup relationship, the Administrator must convert the Lookup field to a Master-Detail relationship field. A prerequisite for converting a Lookup field to Master-Detail is ensuring that every existing child record contains a value in the lookup field.

Step-by-Step Solution

1
Identify the relationship requirement for Roll-Up Summary fields in Salesforce.
Native Roll-Up Summary fields can only be defined on the master object in a Master-Detail relationship.
Lookup relationships do not enforce strict parent-child data dependency required for standard roll-up calculations.
2
Determine the necessary steps to convert the existing Lookup relationship to a Master-Detail relationship.
Ensure all child Inspection_Log__c records have a parent Medical_Device__c assigned, then change the field type of the lookup to Master-Detail.
Master-Detail fields are mandatory on detail records, so converting a Lookup field requires zero null values in that field across all existing records.

Key Concept

Roll-Up Summary Fields Relationship Requirements and Conversion Rules
Question 812Question

An organization configures a Lightning record page for a custom object using Dynamic Forms. To satisfy internal data privacy requirements, the administrator sets a component visibility rule on the Sensitive Details field section so that it only displays on the UI when the viewing user has the HR Specialist profile. A sales representative whose profile grants Read access to all fields on the custom object generates and exports a standard report containing these records. What will occur regarding the Sensitive Details field when the sales representative views the exported report?

Show answer & explanation

Answer: The Sensitive Details field data remains visible in the report because Dynamic Forms component visibility filters affect UI rendering on the record page only and do not restrict data access in reports or APIs.

Answer

The Sensitive Details field data remains visible in the report because Dynamic Forms component visibility filters affect UI rendering on the record page only and do not restrict data access in reports or APIs.
Dynamic Forms component visibility rules are presentation-layer filters configured in Lightning App Builder. They dictate whether fields or field sections are displayed to a user when viewing a Lightning record page. However, they do not enforce database security. Because the user's Profile grants Field-Level Security (FLS) Read access to the field, standard reports and API exports will continue to show the field data regardless of page layout visibility filters.

Step-by-Step Solution

1
Analyze the scope of Dynamic Forms component visibility rules on Lightning record pages.
Dynamic Forms visibility filters strictly govern whether a field section or field component renders visually on a specific Lightning App Builder record page.
UI component visibility is decoupled from database-level security mechanisms.
2
Evaluate the user's data access permissions via Field-Level Security (FLS) and Profile settings.
The sales representative's profile provides explicit Read access to the field on the underlying object.
Reports fetch record data directly based on object permissions and Field-Level Security, bypassing page layout component visibility.
3
Determine the outcome in the exported standard report.
The field data will be fully populated in the exported report for the sales representative.
Because FLS grants read access, hiding the field visually on a Lightning page using Dynamic Forms does not obscure or sanitize field values in reports.

Key Concept

Decoupling of Dynamic Forms UI Component Visibility from Database Field-Level Security (FLS)
Question 813Question

A financial services firm tracks compliance evaluations using a custom object named Risk_Assessment__c. The Organization-Wide Default (OWD) for Risk_Assessment__c is set to Private, and Grant Access Using Hierarchies is enabled. The system administrator needs to meet the following access requirements:
1. Compliance Senior Managers must automatically view and edit Risk Assessment records owned by Compliance Officers who report beneath them.
2. External Risk Auditors must have Read access to all Risk Assessment records where the Risk Level picklist field is set to 'High', regardless of record ownership.

Which two administrative actions are required to satisfy these security requirements? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Rely on the default Role Hierarchy structure, ensuring Compliance Senior Managers occupy roles above Compliance Officers.; Create a criteria-based sharing rule on Risk_Assessment__c that shares records with Risk Level equal to 'High' with External Risk Auditors.

Answer

The requirement is met by leveraging the existing Role Hierarchy for manager-subordinate record access and creating a criteria-based sharing rule to grant access to External Risk Auditors based on the Risk Level field value.
Role hierarchy access naturally rolls record access upward to users higher in the role structure when Grant Access Using Hierarchies is enabled. Additionally, criteria-based sharing rules selectively share records based on field values (e.g., Risk Level = 'High') to target groups or roles.

Step-by-Step Solution

1
Evaluate record access via Role Hierarchy for requirement 1.
Since Organization-Wide Defaults are Private and Grant Access Using Hierarchies is enabled, users higher in the role hierarchy inherit access to records owned by users below them.
This natively fulfills the requirement for Compliance Senior Managers to view and edit records owned by reporting Compliance Officers without extra rules.
2
Evaluate record access based on field values for requirement 2.
Create a criteria-based sharing rule specifying the criterion Risk_Level__c = 'High' and share with the public group or role containing External Risk Auditors.
Criteria-based sharing rules grant Read or Read/Write access to records meeting specified field criteria regardless of ownership.

Key Concept

Role Hierarchy and Criteria-Based Sharing Rules
Question 814Question

A Salesforce Administrator at Apex Global Logistics needs to configure a newly launched service package, 'FleetTrack Pro', so sales representatives can add it to enterprise opportunities using the 'EMEA Enterprise' custom price book. Arrange the administrative configuration steps below into the correct sequential order from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with creating the active Product record, followed by establishing an active entry in the Standard Price Book. Next, the 'EMEA Enterprise' custom price book is created and activated, followed by adding an active custom price book entry for the product. Finally, the price book is selected on the Opportunity so the product can be added as an Opportunity Line Item.
The correct order follows Salesforce's data architecture dependencies: Product record creation → Standard Price Book active entry → Custom Price Book creation/activation → Custom Price Book entry → Opportunity Line Item creation. Creating a standard price entry is a required prerequisite before a custom price book entry can be established.

Step-by-Step Solution

1
Create and activate the Product record
The Product record ('FleetTrack Pro') is established in the system.
You cannot associate price book entries with a product until the base Product record exists.
2
Create an active Standard Price Book entry
The product has a baseline standard list price.
Salesforce enforces a strict dependency requiring an active Standard Price Book entry prior to custom price book assignment.
3
Create and activate the custom price book
The 'EMEA Enterprise' custom price book is available for entry assignment.
A custom price book must exist and be active in order to contain custom price entries.
4
Add the active custom price book entry
'FleetTrack Pro' is priced within the 'EMEA Enterprise' price book.
The custom entry links the product to the custom price book with regional pricing.
5
Associate price book and add Opportunity Line Item
Sales reps can successfully quote and sell 'FleetTrack Pro' on opportunities.
An opportunity must be assigned a price book before products from that price book can be selected as line items.

Key Concept

Standard Price Book entry prerequisites and custom price book deployment order
Question 815Question

An administrator needs to enable roll-up summary fields on the custom object Project__c to aggregate financial metrics from a related child custom object, Project_Milestone__c. Currently, Project_Milestone__c has an existing Lookup relationship to Project__c with existing records in the organization. The administrator also needs to ensure that deleting a Project__c record automatically deletes all related Project_Milestone__c records. Which TWO actions must the administrator take to fulfill these requirements? (Choose 2 answers)

Select all that apply

Show answer & explanation

Answer: Populate the Project__c lookup field on all existing Project_Milestone__c records.; Change the relationship field type on Project_Milestone__c from Lookup to Master-Detail.

Answer

The administrator must populate the lookup field on all existing child records and then convert the relationship field type from Lookup to Master-Detail.
To create roll-up summary fields and inherit cascading delete behavior, the relationship must be converted from Lookup to Master-Detail. Salesforce requires all existing child records to have a populated parent lookup field before this conversion can take place.

Step-by-Step Solution

1
Verify and populate existing child record lookup fields
All child records have a valid parent reference
Master-Detail relationship fields are required on all child records, so any existing null lookup fields will prevent relationship conversion.
2
Convert the relationship field type from Lookup to Master-Detail
The relationship is converted to Master-Detail
This relationship type natively enables roll-up summary fields on the parent object and enforces cascading record deletion.

Key Concept

Converting Lookup to Master-Detail relationships and prerequisites for roll-up summary functionality
Question 816Question

An administrator at Cloud Kicks is configuring a multi-tier Campaign Hierarchy to evaluate performance across a multi-channel product launch. The marketing manager observes that while several child campaigns have recorded new campaign members, the aggregate Total Responses in Hierarchy field on the root Parent Campaign record continues to show zero. Further inspection reveals that custom statuses were created on the child campaigns to track attendee engagement. Which administrative action should be taken to ensure the hierarchy rollup metrics accurately aggregate engagement data?

Show answer & explanation

Answer: Edit the custom Campaign Member Status values on the child campaigns and enable the Responded checkbox for engagement statuses.

Answer

Edit the custom Campaign Member Status values on the child campaigns and enable the Responded checkbox for engagement statuses.
The correct answer addresses the root cause of zero response counts in campaign hierarchy rollup fields. Aggregate campaign statistics such as 'Total Responses in Hierarchy' sum up campaign members whose status value has the 'Responded' checkbox enabled. When administrators create custom member statuses without checking this box, Salesforce treats those interactions as non-responses, leading to zero values in rollup statistics across the hierarchy.

Step-by-Step Solution

1
Analyze how Salesforce calculates hierarchy aggregate fields.
Identify that fields like 'Total Responses in Hierarchy' aggregate member records where the 'Responded' flag is set to true on their status.
Salesforce relies on the binary 'Responded' flag on Campaign Member Status records to determine whether a member count contributes to campaign response metrics.
2
Inspect the custom Campaign Member Status settings on child campaigns.
Determine that new custom statuses (e.g., 'Attended', 'Registered') were added without checking the 'Responded' box.
When creating custom campaign member statuses, the 'Responded' checkbox is unchecked by default unless explicitly selected during configuration.
3
Update status configurations and check the 'Responded' checkbox for appropriate engagement statuses.
The parent campaign automatically recalculates 'Total Responses in Hierarchy' to reflect accurate response counts.
Marking engagement statuses as 'Responded' allows standard rollup summary logic across the campaign hierarchy to evaluate correctly.

Key Concept

Campaign Hierarchy Rollup Summaries and Campaign Member Status Responded Tracking
Question 817Question

Cloud Prism Solutions recently established a dedicated Operations Escalations team that handles specialized hardware replacement workflows. The administrator created a new Case Page Layout with custom hardware fields and a new Case Record Type for this team. However, during testing, the administrator discovers that the Case Status picklist displays all default system status values instead of the streamlined status values specifically needed for hardware replacements. Furthermore, when attempting to edit available picklist values on the Record Type detail page, the Case Status field is missing from the list of customizable picklists. What is the root cause of this configuration issue?

Show answer & explanation

Answer: The administrator assigned the Page Layout to the Case Record Type without first creating a dedicated Support Process to select the allowed Case Status values and linking that process to the Record Type.

Answer

The administrator assigned the Page Layout to the Case Record Type without first creating a dedicated Support Process to select the allowed Case Status values and linking that process to the Record Type.
In Salesforce, the standard Case Status picklist is governed exclusively by a Support Process. Before creating a Case Record Type that requires a custom set of status values, an administrator must first create a Support Process that defines which status values are active. When creating or editing the Case Record Type, the administrator links it to the corresponding Support Process. Because of this architectural dependency, Case Status is not available under the standard 'Picklists Available for Editing' section on the Record Type detail page.

Step-by-Step Solution

1
Identify how Case Status picklist values are controlled in Salesforce Service Cloud.
Recognize that unlike standard custom picklist fields, the standard Case Status field values are driven by a Support Process.
Support Processes define the lifecycle stages (status values) for cases across different business units.
2
Analyze why the Case Status field was missing from the Record Type picklists edit list.
Determine that Salesforce intentionally hides Case Status from the Record Type picklist configuration section because it must be linked via a Support Process.
A Support Process acts as an essential prerequisite layer between Case Status master values and Case Record Types.
3
Determine the necessary administrative step to resolve the issue.
Create a new Support Process selecting the specific hardware replacement status values, then assign this Support Process when configuring or editing the Case Record Type.
Linking the Support Process to the Record Type enforces the desired status picklist lifecycle.

Key Concept

Support Process Prerequisite for Case Record Types
Question 818Question

A Salesforce administrator at a commercial real estate advisory firm creates a custom picklist field named 'Investment Strategy' on the Lead object. The operations team requests that when a lead converts, the selected 'Investment Strategy' value populates a custom picklist field of the same name on the resulting Contact record. During initial testing, the Lead converts successfully, but the 'Investment Strategy' field on the newly created Contact record remains blank. Which administrative action is required to ensure this data populates correctly upon conversion?

Show answer & explanation

Answer: Configure Lead Custom Field Mapping under the Lead object settings to map the Lead field to the Contact field.

Answer

Configure Lead Custom Field Mapping under the Lead object settings to map the Lead field to the Contact field.
To transfer custom Lead field data to Account, Contact, or Opportunity records during lead conversion, an administrator must manually map the custom fields under Object Manager > Lead > Fields & Relationships > Map Lead Fields. Data types must match or be compatible.

Step-by-Step Solution

1
Identify the mechanism used by Salesforce to transfer custom Lead data during conversion.
Salesforce requires explicit mapping between custom fields on the Lead object and custom fields on the Account, Contact, or Opportunity objects.
Custom lead fields are not automatically mapped upon conversion, regardless of API names or picklist values.
2
Navigate to the Lead Object settings in Object Manager.
Access 'Fields & Relationships' and select 'Map Lead Fields'.
This tool defines how lead custom fields map to target custom fields during conversion.
3
Map the Lead 'Investment Strategy' picklist field to the corresponding Contact 'Investment Strategy' picklist field.
The value selected on the Lead will reliably transfer to the Contact record upon conversion.
Explicit custom field mapping completes the required configuration.

Key Concept

Lead Custom Field Mapping during Lead Conversion
Estimated Time:1m 30s
Question 819Question

CloudArmor Security provides two distinct service offerings: standard Enterprise Helpdesk support and a specialized Hardware Replacement service. The Hardware Replacement workflow requires specific Case Status picklist values ('Received at Depot', 'Under Inspection', and 'Replacement Shipped') that should not appear for standard Enterprise Helpdesk tickets. An administrator added these new status values to the Case Status master picklist and configured a new Case Record Type called 'Hardware Replacement'. However, support agents creating 'Hardware Replacement' cases report that the new status values are missing from the status dropdown menu. Which configuration step did the administrator fail to complete?

Show answer & explanation

Answer: Creating a dedicated Support Process containing the new status values and associating it with the Hardware Replacement Case Record Type.

Answer

The administrator must create a dedicated Support Process that includes the required custom Case Status picklist values and associate that Support Process with the Hardware Replacement Case Record Type.
On the Case object, the Case Status picklist values available to users are determined by a Support Process. Creating the values in the master picklist and creating a Record Type is insufficient; an administrator must create a Support Process containing the specific status values and assign that Support Process to the Case Record Type.

Step-by-Step Solution

1
Identify the dependency requirement for Case Status selection.
Recognize that Case Status is a special picklist controlled specifically by a Support Process rather than directly by Record Types or Page Layouts.
In Salesforce, Case Status picklist values available to users are determined by the Support Process associated with the Case Record Type.
2
Evaluate the administrative configuration steps taken.
The administrator added values to the master picklist and created a Record Type, but omitted creating and linking the Support Process.
Creating a Case Record Type requires selecting an active Support Process that defines the exact lifecycle stages available.
3
Determine the corrective action.
Build a new Support Process featuring 'Received at Depot', 'Under Inspection', and 'Replacement Shipped', then assign it to the 'Hardware Replacement' record type.
Without linking a Support Process containing these specific values, the record type defaults to standard or unconfigured status lifecycles.

Key Concept

Support Process Prerequisite for Case Record Types
Estimated Time:2m 0s
Question 820Question

Cloud Kicks recently launched a dedicated Warranty Claims unit that requires a distinct set of case lifecycle stages compared to standard customer support. A Salesforce administrator created a custom Case record type and assigned a custom page layout, but agents report that the new warranty-specific Case Status values are missing when creating new records. Which configuration step was omitted by the administrator?

Show answer & explanation

Answer: Creating a dedicated Support Process containing the new Case Status values and associating it with the Warranty Claims record type.

Answer

The administrator omitted creating a dedicated Support Process containing the new Case Status values and associating it with the Warranty Claims record type.
On the Case object, Case Status picklist values are governed by Support Processes. Before creating a Case Record Type with a distinct lifecycle, an administrator must create a Support Process selecting the appropriate status values. Assigning that Support Process to the Case Record Type ensures agents see the intended status options.

Step-by-Step Solution

1
Identify the prerequisite component for Case Status picklist values.
Recognize that Case Status values are tied specifically to a Support Process in Service Cloud.
Unlike standard picklist fields whose values can be edited directly on Record Types, Case Status values must first be selected within a Support Process.
2
Associate the Support Process with the target Case Record Type.
Link the newly created Support Process to the Warranty Claims record type during or after record type creation.
A Case Record Type references a Support Process to determine which Case Status values are accessible to users assigned to that record type.

Key Concept

Support Process and Case Record Type Prerequisites
Estimated Time:1m 30s
PreviousPage 41 / 90Next
All practice questions — Salesforce Certified Administrator | Examkin