All practice questions

1784 questions

Question 1Question

An administrator at a healthcare organization needs to display the total aggregate score of all related child custom object records, Patient_Feedback__c, on the standard Contact object. The business requirements state that if a Contact record is deleted, the associated Patient_Feedback__c records must be retained in the system for auditing purposes. When trying to create a native Roll-Up Summary field on the Contact object, the administrator notices that Patient_Feedback__c is not available in the summarize object dropdown list. Which explanation accounts for this limitation, and what is the recommended declarative solution?

Show answer & explanation

Answer: Native Roll-Up Summary fields require a Master-Detail relationship. To preserve child records upon Contact deletion, the administrator must keep the Lookup relationship and use a Record-Triggered Flow to aggregate and update the total score on the Contact record.

Answer

Native Roll-Up Summary fields require a Master-Detail relationship. To preserve child records upon Contact deletion, the administrator must keep the Lookup relationship and use a Record-Triggered Flow to aggregate and update the total score on the Contact record.
Native Salesforce Roll-Up Summary fields are exclusively supported on the master side of a Master-Detail relationship. However, deleting a master record cascades to delete all child detail records. To meet the requirement of preserving child records when a Contact is deleted, the relationship must remain a Lookup relationship. A declarative Record-Triggered Flow can be used to aggregate field values from the lookup child records and update a custom field on the Contact object.

Step-by-Step Solution

1
Analyze relationship capabilities for roll-up functionality
Standard declarative Roll-Up Summary fields on a parent object are only supported when a Master-Detail relationship exists between the parent and child objects.
Because the objects are linked via a Lookup relationship, the child object does not appear in the Roll-Up Summary wizard.
2
Evaluate deletion cascade behavior
Converting the Lookup to a Master-Detail relationship causes detail records to be permanently deleted when the master record is deleted.
The requirement states that Patient_Feedback__c records must be retained when a Contact is deleted, ruling out a Master-Detail conversion.
3
Determine the optimal declarative solution
Maintain the Lookup relationship and implement a Record-Triggered Flow on Patient_Feedback__c to recalculate the aggregate score on the parent Contact record upon creation, update, or deletion.
This achieves real-time data aggregation without introducing cascade deletion behavior.

Key Concept

Standard and Custom Object Relationship Capabilities and Deletion Behaviors
Question 2Question

An administrator at a maritime logistics company needs to calculate the total freight weight on a custom parent object, Shipment__c, by summarizing weight values from child records on a custom object named Container_Package__c. The Container_Package__c object currently references Shipment__c through a Lookup relationship. When attempting to create a Roll-Up Summary field on Shipment__c, the administrator discovers that Container_Package__c is not available in the list of summarized objects. Which administrative action must be taken to enable the Roll-Up Summary field on the Shipment__c object?

Show answer & explanation

Answer: Convert the existing Lookup relationship field on Container_Package__c to a Master-Detail relationship after verifying that all existing Container_Package__c records have a populated Shipment__c value.

Answer

The administrator must convert the existing Lookup relationship field on Container_Package__c to a Master-Detail relationship after ensuring all existing Container_Package__c records have a populated Shipment__c value.
In Salesforce, Roll-Up Summary fields can only be defined on the master object of a Master-Detail relationship to aggregate data from child detail records. Because the existing relationship is a Lookup relationship, the child object will not appear as an option in the Roll-Up Summary field setup wizard. Converting the Lookup field on the child object to a Master-Detail relationship makes the parent object the master, allowing roll-up summaries to be created. For this conversion to succeed, every child record must currently have a populated lookup value.

Step-by-Step Solution

1
Identify why Container_Package__c is unavailable in the Roll-Up Summary wizard.
Roll-Up Summary fields are natively supported only on the master object in a Master-Detail relationship, not on objects linked via Lookup relationships.
Salesforce requires a Master-Detail relationship to enforce strict parent-child data architecture necessary for automated roll-up calculations.
2
Determine the required data clean-up prerequisite for relationship conversion.
Ensure that every record on the child object (Container_Package__c) has a valid value populated in the existing Lookup field.
A Master-Detail relationship requires the master reference field to be mandatory on all child records.
3
Convert the relationship and create the field.
Convert the Lookup field on Container_Package__c to Master-Detail, then create the Roll-Up Summary field on Shipment__c.
Once converted, Shipment__c becomes the master object and gains the capability to aggregate child field values.

Key Concept

Roll-Up Summary Prerequisites and Relationship Type Conversion
Estimated Time:2m 0s
Question 3Question

A logistics enterprise relies on a single baseline profile for all 50 warehouse dispatchers. The administrator needs to grant two senior dispatchers elevated access to export freight records and edit the restricted 'Customs Priority' field on the Freight Manifest custom object, without expanding access for the remaining dispatchers. Which two administrative actions should be taken to meet this requirement following Salesforce security best practices? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Create a permission set granting the Export Reports system permission and Edit access to the Customs Priority field, then assign it to the two senior dispatchers.; Keep all dispatchers assigned to their existing baseline profile to preserve organizational least privilege principles.

Answer

The administrator should create a permission set with the required export and field-level edit permissions for assignment to the two senior dispatchers, while keeping all dispatchers on their standard baseline profile.
The combination of creating a permission set for the specific elevated permissions and leaving all users on their baseline profile adheres to Salesforce best practices. Permission sets allow administrators to extend functionality to specific users on a case-by-case basis while maintaining clean, maintainable profiles.

Step-by-Step Solution

1
Evaluate access requirements
Identify that only two out of fifty users require additional permissions.
Additive, user-specific permissions should be granted without altering the shared baseline for all users.
2
Build a targeted permission set
Configure a permission set containing 'Export Reports' and Edit access for 'Customs Priority'.
Permission sets extend user access privileges selectively without modifying baseline profile settings.
3
Assign the permission set to target users
Assign the new permission set directly to the two senior dispatchers.
This enforces the principle of least privilege while providing the necessary functional access.

Key Concept

Additive permissions via Permission Sets versus profile maintenance
Question 4Question

A pharmaceutical firm tracks sensitive clinical test findings using a custom object called Clinical_Trial_Response__c. Business governance mandates that clinical researchers must only be able to view and edit trial records they personally own. Additionally, managers positioned above the researchers in the role hierarchy must automatically inherit read and edit access to records owned by their subordinates, while researchers in other departments must have no access. Which Organization-Wide Default (OWD) setting and configuration satisfies these access requirements?

Show answer & explanation

Answer: Set the Organization-Wide Default to Private and keep 'Grant Access Using Hierarchies' enabled.

Answer

Set the Organization-Wide Default to Private and keep 'Grant Access Using Hierarchies' enabled.
Setting the Organization-Wide Default to Private establishes the most restrictive baseline access so that users only see records they own. Keeping 'Grant Access Using Hierarchies' selected ensures users above the record owner in the role hierarchy automatically inherit access to those records.

Step-by-Step Solution

1
Determine the baseline access requirement for non-owners in different departments.
Since non-owner researchers in other departments must have no access to records, the baseline Organization-Wide Default (OWD) must be set to Private.
OWD defines the most restrictive baseline level of access across the organization.
2
Evaluate role hierarchy requirements for managers above record owners.
Higher-level roles require access to records owned by subordinates.
For custom objects, keeping 'Grant Access Using Hierarchies' checked ensures that users higher in the role hierarchy automatically inherit the access rights of record owners below them.

Key Concept

Organization-Wide Defaults (OWD) and Role Hierarchy access propagation for custom objects
Question 5Question

A Salesforce Administrator needs to provision access for 15 new regional auditors. All 15 auditors require the base access provided by the standard 'Read Only' profile. However, 5 of these auditors also require permissions to create and edit records on a custom object named 'Compliance Audit', while the remaining 10 auditors must not have access to modify this object. How should the administrator provision these users to meet the security requirements while minimizing administrative maintenance?

Show answer & explanation

Answer: Assign all 15 auditors the standard Read Only profile, and create and assign a Permission Set granting Create and Edit access on the Compliance Audit object to the 5 auditors who require it.

Answer

Assign all 15 auditors the standard Read Only profile, and create and assign a Permission Set granting Create and Edit access on the Compliance Audit object to the 5 auditors who require it.
Assigning all users a common baseline profile and using a Permission Set for the 5 users who need extra permissions adheres strictly to Salesforce security architecture guidelines. Profiles establish the base privileges, and Permission Sets grant incremental permissions without cluttering the org with multiple single-purpose profiles.

Step-by-Step Solution

1
Identify baseline user access requirements across all target users.
All 15 auditors require identical baseline read-only access.
Establishing a single common profile minimizes administrative complexity.
2
Evaluate the additive permission requirements for the subset of users.
5 auditors require additional Create and Edit access on the custom 'Compliance Audit' object.
Profiles should define baseline access, while Permission Sets extend access for specific sub-groups.
3
Select the appropriate Salesforce security component to grant the extra access.
Create a Permission Set with object-level Create and Edit permissions for 'Compliance Audit' and assign it to the 5 specific auditors.
This adheres to the principle of least privilege and Salesforce best practices for access management.

Key Concept

Profiles vs. Permission Sets for additive access management
Question 6Question

A renewable energy company manages confidential bidding proposals using a custom object named Partner_Bidding_Proposal__c. Executive leadership mandates that sales managers should only be able to view and edit bidding proposals owned by their direct reports. Users outside the owner's management hierarchy must have no access to these records unless explicitly shared. Additionally, the system administrator needs to ensure the baseline security configuration follows Salesforce best practices without creating unnecessary maintenance overhead. Which two administrative steps must the system administrator take to satisfy these security requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set the Organization-Wide Default (OWD) for Partner_Bidding_Proposal__c to Private.; Ensure the 'Grant Access Using Hierarchies' checkbox remains selected on the custom object's sharing settings.

Answer

The correct configuration requires setting the Organization-Wide Default for Partner_Bidding_Proposal__c to Private and ensuring the 'Grant Access Using Hierarchies' setting is enabled.
To achieve a baseline where only owners and their manager hierarchy can access records, the Organization-Wide Default must be configured to Private. Concurrently, keeping 'Grant Access Using Hierarchies' enabled on the custom object allows managers above the owner in the role hierarchy to automatically inherit visibility and editing privileges.

Step-by-Step Solution

1
Determine the required baseline record visibility
Since users outside the owner's hierarchy must have no access by default, set the Organization-Wide Default (OWD) internal access to Private.
OWD defines the most restrictive baseline access level for records an employee does not own.
2
Evaluate role hierarchy propagation for the custom object
Keep 'Grant Access Using Hierarchies' checked on the custom object.
For custom objects, 'Grant Access Using Hierarchies' is enabled by default and ensures managers above record owners automatically inherit access without requiring custom sharing rules.

Key Concept

Organization-Wide Defaults (OWD) and Role Hierarchy Inheritance
Question 7Question

A Salesforce administrator is tasked with summarizing child record data on a parent record. Specifically, the business requires a Roll-Up Summary field on the parent object to automatically calculate total sales volume from related child records. Which type of object relationship must be established to enable this functionality?

Show answer & explanation

Answer: A Master-Detail relationship where the field is created on the child object

Answer

A Master-Detail relationship where the field is created on the child object
Native Roll-Up Summary fields require a Master-Detail relationship between the parent and child objects, with the relationship field residing on the child object.

Step-by-Step Solution

1
Identify the key requirement
The requirement calls for creating a native Roll-Up Summary field on a parent record.
Roll-Up Summary fields aggregate data from child records to parent records.
2
Evaluate relationship types for roll-up summary eligibility
Native Roll-Up Summary fields are exclusively available when objects are linked via a Master-Detail relationship.
Lookup relationships do not support native Roll-Up Summary fields without custom development or third-party tools.
3
Determine field placement for the relationship
The custom Master-Detail field must reside on the child object pointing to the master parent object.
Child records reference their master record via the relationship field created on the child object.

Key Concept

Roll-Up Summary Field Eligibility and Master-Detail Relationships
Question 8Question

A Salesforce Administrator at a financial services firm needs to secure access to a custom field, Tax_Identification_Number__c, on the Account object. All users assigned to the Standard Support profile must be prevented from viewing or editing this field. However, two designated support lead users require Read access to this field. Additionally, all users on the Standard Support profile must be blocked from logging in when outside the corporate network IP range. Which two administrative actions should be implemented to fulfill these security requirements? (Choose 2 answers)

Select all that apply

Show answer & explanation

Answer: Deselect the Visible and Read-Only checkboxes for Tax_Identification_Number__c on the Standard Support profile, and assign a Permission Set granting Read access on the field to the two support lead users.; Add the corporate network IP addresses to the Login IP Ranges section on the Standard Support profile settings.

Answer

To satisfy the security requirements, the administrator should deselect visibility for the custom field on the profile and grant Read access via a permission set to designated leads, as well as configure Login IP Ranges on the profile to restrict network access.
Field-Level Security (FLS) configured at the profile level ensures that users on that profile cannot access the field in UI, reports, or APIs. A permission set can then additively grant read access to specific individuals without altering the base profile. Furthermore, setting Login IP Ranges directly on the profile restricts users on that profile to logging in exclusively within the specified IP range.

Step-by-Step Solution

1
Analyze field-level access requirements for profile and specific users
Disabling visibility on the profile restricts access for all standard support users, while assigning a permission set grants Read access specifically to the two support leads.
Profiles define baseline access, while Permission Sets selectively grant additional permissions to specific users.
2
Evaluate login IP restriction requirements
Configuring Login IP Ranges on the profile strictly prevents profile users from logging in outside the designated corporate IP range.
Profile-level IP ranges enforce hard login restrictions, whereas org-wide Network Access ranges only manage identity verification challenges.

Key Concept

Profiles establish maximum baseline restrictions and profile-level IP limits, whereas Permission Sets grant additive field permissions to targeted users.
Question 9Question

An administrator is setting up a new custom object in Salesforce to track corporate IT asset inventory. Which two standard components or system fields are automatically created on every new custom object? (Select 2)

Select all that apply

Show answer & explanation

Answer: A standard Record Name field configured as either Text or Auto-Number; Standard system audit fields including CreatedById, LastModifiedById, and SystemModstamp

Answer

The correct options are the standard Record Name field (Text or Auto-Number) and standard system audit fields (CreatedById, LastModifiedById, and SystemModstamp).
Upon custom object creation, Salesforce provisions standard audit fields (such as CreatedById, LastModifiedById, and SystemModstamp) and requires the configuration of a standard Record Name field (either Text format or Auto-Number sequence) for record identification.

Step-by-Step Solution

1
Identify automatic object creation features in Salesforce.
When a custom object is created, Salesforce automatically generates standard system fields including Name, CreatedBy, LastModifiedBy, Owner (for private/read-write objects), and SystemModstamp.
System fields maintain platform governance, auditing, and basic data identification.
2
Evaluate relationship and record type requirements.
Custom relationships (such as Master-Detail or Lookup) and Record Types are not created by default; they require manual setup.
Salesforce enforces schema flexibility by leaving custom business logic configurations to the administrator.

Key Concept

Custom Object Standard System Fields
Question 10Question

An administrator at a wealth management firm is configuring a custom object named Portfolio__c linked to the standard Account object. Compliance regulations mandate that deleting an Account record must NOT result in the deletion of associated Portfolio__c records. However, business leadership requires a standard roll-up calculation on the Account record to display the sum of total asset values from related Portfolio__c records. Which relationship architectural consideration must the administrator present to leadership?

Show answer & explanation

Answer: Standard Roll-Up Summary fields are strictly supported on Master-Detail relationships, which force cascading record deletion; a Lookup relationship with automated record updates (such as Flow) is required to meet both constraints.

Answer

Standard Roll-Up Summary fields are strictly supported on Master-Detail relationships, which force cascading record deletion; a Lookup relationship with automated record updates (such as Flow) is required to meet both constraints.
The solution correctly identifies the fundamental trade-off between Salesforce relationship types. Standard Roll-Up Summary fields require a Master-Detail relationship, but Master-Detail relationships enforce cascading deletion of child records when the master is deleted. To comply with the non-deletion business constraint, the administrator must implement a Lookup relationship and use Flow automation or apex/custom tooling to handle summary calculations on the parent Account.

Step-by-Step Solution

1
Analyze the deletion retention requirement
Identified that child Portfolio__c records must survive if the parent Account is deleted.
Master-Detail relationships automatically execute cascading deletes on child records when a parent record is deleted.
2
Evaluate standard Roll-Up Summary field capabilities
Determined that standard Roll-Up Summary fields are exclusively supported on the master object in a Master-Detail relationship.
Lookup relationships do not support standard native declarative Roll-Up Summary fields.
3
Synthesize architectural recommendation
Selected a Lookup relationship to guarantee child record retention and recommended declarative automation (Flow) to calculate totals.
This combination satisfies both the non-deletion compliance rule and the summary reporting requirement.

Key Concept

Master-Detail vs. Lookup Relationship Capabilities and Deletion Behavior
Estimated Time:2m 0s
Question 11Question

A company tracks software feature requests using a custom child object named Enhancement_Request__c, which currently connects to a custom parent object, Product_Module__c, through a Lookup relationship. The product management team requires real-time count metrics on Product_Module__c to track total feature requests. When the Salesforce Administrator attempts to convert the existing Lookup relationship field into a Master-Detail relationship field to build a Roll-Up Summary field, Setup returns an error preventing the schema change. What is the root cause of this error, and how should the administrator resolve it?

Show answer & explanation

Answer: Existing child records contain null values in the Lookup field; the administrator must populate the lookup field on all existing Enhancement_Request__c records before converting the data type.

Answer

Populate the Lookup field on all existing child records with a valid parent record reference, then convert the lookup field to a master-detail relationship.
To convert an existing Lookup relationship to a Master-Detail relationship, every existing record on the child object must contain a populated value in the lookup field. Because Master-Detail relationships strictly enforce parent record reference requirements (detail records cannot exist without a master), Salesforce prevents field conversion if any child record has a blank/null lookup value. Populating these records allows the conversion to complete successfully, which in turn enables the creation of Roll-Up Summary fields on the parent object.

Step-by-Step Solution

1
Identify the mandatory requirements for converting a Lookup field to a Master-Detail field in Salesforce.
Recognize that Master-Detail relationships require every detail record to be linked to a master record (the relationship field cannot be blank).
Salesforce enforces database integrity for master-detail relationships, ensuring no orphan detail records exist.
2
Analyze why changing the field data type failed during Setup configuration.
Determine that existing child records in the custom object contain null (blank) values in the existing lookup field.
If any child record lacks a value in the lookup field, Salesforce blocks the data type conversion to prevent master-detail integrity violations.
3
Formulate the correct administrative resolution strategy.
Populate valid parent record references across all existing child records via Data Loader or mass update, then execute the field type conversion in Object Manager.
Once all child records possess a non-null relationship value, the system permits conversion from Lookup to Master-Detail, subsequently allowing Roll-Up Summary field creation.

Key Concept

Converting Lookup Relationships to Master-Detail Relationships
Estimated Time:2m 0s
Question 12Question

Match each security and access control scenario for Global Logistics Corp to the appropriate Salesforce profile or field-level security (FLS) configuration setting.

Click a left item, then click its matching right item

Items

Completely restrict visibility of the sensitive field 'Executive_Audit_Notes__c' across all standard users regardless of page layout modifications.
Grant Read-Only visibility of the custom field 'Credit_Limit__c' to the Standard User profile while allowing full edit capability on the Finance profile.
Prevent users assigned to a specific custom profile from logging into Salesforce entirely when outside corporate network IP ranges.
Allow Sales Representatives to create, view, and modify custom 'Freight_Contract__c' records while explicitly revoking their capability to delete them.

Matches

Show answer & explanation

Answer

Each scenario maps to its underlying security level in Salesforce: sensitive field access to FLS hiding, profile-specific field editing to FLS visibility/read-only controls, network login enforcement to Profile Login IP Ranges, and record deletion restrictions to Object Permissions (CRUD).
Each business requirement aligns directly with Salesforce security controls: Field-Level Security governs data access at the field level regardless of UI controls, Object Permissions define baseline record CRUD privileges on profiles, and Profile Login IP Ranges enforce absolute network login restrictions.

Step-by-Step Solution

1
Analyze field-level security vs. page layout security requirements.
Field accessibility across APIs, reports, and search requires FLS settings rather than page layout adjustments.
Page layouts only hide fields on the user interface; FLS secures the field at the data layer.
2
Evaluate object-level CRUD permissions.
Disabling record deletion for a group of users requires unchecking Delete under Object Permissions on their assigned profile.
Object permissions define the baseline record operations (Create, Read, Edit, Delete) available to users with that profile.
3
Differentiate between Profile Login IP Ranges and Organization-Wide Trusted IP Ranges.
Profile Login IP Ranges restrict login access completely outside specified ranges, whereas Org-Wide Trusted IP Ranges only bypass multi-factor authentication challenges.
Profile-level IP restrictions strictly enforce network boundaries for authentication.

Key Concept

Profiles and Object/Field-Level Security
Estimated Time:2m 0s
Question 13Question

An administrator needs to deploy a custom Account Lightning Record Page so that it is displayed exclusively to Support Agent profile users working on Enterprise record type accounts within the Service Console application. Other departments using the Enterprise record type in different applications must retain their existing page assignments. Which page activation option should the administrator configure in Lightning App Builder to achieve this?

Show answer & explanation

Answer: Assign the page as App, Record Type, and Profile, selecting the Service Console application, the Enterprise record type, and the Support Agent profile.

Answer

The correct option is to assign the page at the App, Record Type, and Profile level, selecting the Service Console application, the Enterprise record type, and the Support Agent profile.
Assigning the Lightning Record Page at the granular App, Record Type, and Profile level allows administrators to override Org and App defaults for a specific subset of users in a particular application context without disturbing existing layout assignments for other apps or profiles.

Step-by-Step Solution

1
Analyze the scope of the business requirement.
The requirement restricts page visibility based on three distinct criteria: Application (Service Console), Record Type (Enterprise), and User Profile (Support Agent).
Salesforce Lightning App Builder provides distinct activation levels to handle varying degrees of assignment granularity.
2
Evaluate activation precedence rules.
App, Record Type, and Profile combination assignment takes precedence over App Default and Org Default assignments.
Selecting all three criteria ensures only users meeting all specific conditions view the customized layout while all other user combinations maintain their default page assignments.

Key Concept

Lightning Record Page Activation Levels and Assignment Precedence
Question 14Question

A Salesforce administrator at an agricultural technology company is configuring custom fields on a custom object, 'Field Telemetry', and setting up field mappings for lead processing. The administrator must enable aggregate metrics on a parent custom object, 'Farm Station', and ensure custom fields on Lead records transfer seamlessly when converting qualified leads to opportunities. Which two statements correctly describe the administration considerations and capabilities for configuring these custom fields and data type mappings? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: To create a Roll-Up Summary field on the parent 'Farm Station' object, 'Field Telemetry' must be connected to 'Farm Station' using a Master-Detail relationship.; Custom Lead fields can be mapped to custom fields on Account, Contact, or Opportunity objects if the target fields have compatible data types.

Answer

Roll-Up Summary fields require a Master-Detail relationship to aggregate child data onto a parent object, and custom Lead fields must be mapped to compatible custom fields on Account, Contact, or Opportunity records during lead conversion.
Native Roll-Up Summary fields require a Master-Detail relationship between the parent and child objects. Additionally, when setting up Lead conversion, custom Lead fields can be mapped to custom fields on the Account, Contact, or Opportunity objects as long as the data types are compatible.

Step-by-Step Solution

1
Evaluate relationship requirements for Roll-Up Summary fields
Identify that declarative Roll-Up Summary fields are exclusively supported on the master object in a Master-Detail relationship.
Lookup relationships do not support native declarative roll-up summary fields.
2
Evaluate custom Lead field conversion mapping capabilities
Confirm that custom Lead fields map to custom fields on Account, Contact, or Opportunity objects with compatible data types.
Salesforce requires explicit mapping between compatible custom fields and does not automatically map custom Lead fields to standard target fields.

Key Concept

Custom Field Capabilities and Master-Detail vs Lookup Relationship Constraints
Question 15Question

An enterprise customer support organization recently transferred a Senior Support Manager to an unassociated international subsidiary. The Salesforce Administrator needs to immediately restrict this user's ability to log in to the org during an offboarding security evaluation. However, during an administrative check, the administrator discovers that the manager is currently designated as the Default Case Owner in Support Settings and is referenced as the target user in several active Case Escalation Rule actions. Which action should the administrator take to prevent log-in access immediately without disrupting existing automated case management processes?

Show answer & explanation

Answer: Freeze the user account immediately, reassign the Default Case Owner setting and Escalation Rule actions to another active user, and then deactivate the user account.

Answer

Freeze the user account immediately, reassign the Default Case Owner setting and Escalation Rule actions to another active user, and then deactivate the user account.
Freezing a user account immediately blocks login access while leaving license allocation and system references unchanged. This allows the administrator to address system dependencies—such as the Default Case Owner setting in Support Settings and active Case Escalation Rules—without leaving an active security vulnerability. Once dependencies are reassigned to another active user, the account can be safely deactivated.

Step-by-Step Solution

1
Evaluate immediate access restriction requirements vs administrative system dependencies.
Identified that immediate login prevention is required while the user is still referenced in Support Settings and Case Escalation Rules.
Direct deactivation is blocked when a user is set as Default Case Owner or tied to active escalation rule actions.
2
Select Freezing as the initial action.
The user's login access is blocked immediately without triggering system dependency validation errors.
Freezing stops user login capability without requiring immediate removal of workflow, setting, or hierarchy references.
3
Reassign system dependencies and execute deactivation.
Support Settings and Escalation Rules are updated to a valid active user, freeing the target user account for full deactivation.
Deactivation releases the Salesforce user license once all blocking administrative references are cleared.

Key Concept

Freezing vs. Deactivating Users with System Dependencies
Estimated Time:2m 0s
Question 16Question

A Salesforce administrator at a solar energy equipment manufacturer is configuring custom fields on custom objects tracking installation projects. The administrator must also plan for field data type conversions and lead mapping settings. Which two statements correctly describe Salesforce custom field capabilities and data type behaviors? (Select 2 answers.)

Select all that apply

Show answer & explanation

Answer: Converting a custom Text Area (Long) field to a standard Text field truncates existing data if record values exceed 255 characters.; Converting a custom field from Number to Text preserves existing numeric data without loss of information.

Answer

Converting a custom Text Area (Long) field to a standard Text field truncates data exceeding 255 characters, and converting a custom field from Number to Text preserves existing numeric data.
Converting a Text Area (Long) field to a standard Text field limits character capacity to 255 characters, causing longer entries to be truncated. Converting a Number field to a Text field preserves existing numeric entries as text characters without data loss.

Step-by-Step Solution

1
Analyze field data type conversion rules in Salesforce.
Changing from Text Area (Long) to standard Text reduces maximum length to 255 characters, truncating longer values. Converting Number to Text safely retains digits as string characters.
Salesforce enforces data length caps on standard Text fields and allows non-destructive conversion from Number to Text.
2
Evaluate relationship types, record types, and lead mapping rules against the distractors.
Roll-up summary fields require Master-Detail relationships. Picklist values must be assigned per Record Type. Lead conversion mapping requires matching/compatible field data types.
Salesforce architecture restricts roll-ups on lookups, mandates picklist assignment per record type, and requires compatible data types for lead field mapping.

Key Concept

Custom Field Data Type Behavior and Conversion Rules
Question 17Question

A company wants to roll out a new streamlined Home page layout to every user in the company, regardless of their assigned Lightning app or job role. Which activation option in Lightning App Builder must the administrator select to achieve this requirement?

Show answer & explanation

Answer: Org Default

Answer

Assign as Org Default in Lightning App Builder.
Selecting Org Default sets the newly built Home page as the organization-wide default for all users who access Salesforce, fulfilling the business requirement to apply the page universally across all apps and roles.

Step-by-Step Solution

1
Identify the target scope of the Home page activation requirement.
The requirement requests a default layout for every user across the entire organization regardless of app or role.
Determining the scope helps select the appropriate activation tier in Lightning App Builder.
2
Evaluate Lightning App Builder Home page activation options.
Org Default applies the Home page globally to all users in the org.
Higher-specificity options like App Default or Profile assignments restrict the scope to specific apps or roles.

Key Concept

Lightning Home Page Activation Options
Question 18Question

A Salesforce administrator is customizing the user experience for a custom object named Work_Order__c within a dedicated app called Field_Service_App. The administrator must fulfill two specific operational requirements:
1. Ensure a customized Lightning Record Page displays only when users access Work_Order__c records assigned to the 'Emergency' Record Type while working in the Field_Service_App under the 'Field Technician' Profile.
2. Restrict visibility of a custom financial summary component on the page so it is displayed exclusively to users with the 'Financial_Auditor' custom permission, without altering object field permissions.

Which TWO statements correctly describe the valid configuration steps and behaviors in Lightning App Builder to achieve these requirements? (Select 2 choices)

Select all that apply

Show answer & explanation

Answer: The custom Lightning Record Page must be activated using the 'App, Record Type, and Profile' assignment level, selecting Field_Service_App, the Emergency record type, and the Field Technician profile.; The financial summary component's visibility can be filtered using a Client/User filter criteria based on the $Permission.CustomPermission system variable for Financial_Auditor.

Answer

The correct options are: (1) Activating the custom Lightning Record Page using the 'App, Record Type, and Profile' assignment level to target the specific application, record type, and profile combination; and (2) Filtering the financial summary component's visibility using a User filter criteria based on the custom permission system variable ($Permission.CustomPermission).
The requirement to target a custom page to a specific App, Record Type, and Profile combination directly matches the three-tier activation option available for Lightning Record Pages in the Activation Wizard. Furthermore, component visibility filters in Lightning App Builder can evaluate custom user permissions via $Permission, satisfying the requirement to show the financial summary component conditionally without altering global Field-Level Security.

Step-by-Step Solution

1
Evaluate record page activation hierarchy options for target user targeting.
Salesforce Lightning Record Pages support three activation levels: Org Default, App Default, and App + Record Type + Profile combination. To restrict a page to a specific App, Record Type, and Profile simultaneously, the administrator must use the App, Record Type, and Profile activation option.
This guarantees that users see the custom page layout only when viewing Emergency record type records within Field_Service_App under the Field Technician profile.
2
Evaluate dynamic component visibility criteria capabilities.
Lightning App Builder supports dynamic component visibility filters driven by record fields, user attributes, and system context (such as $Permission.CustomPermission).
Filtering by $Permission.CustomPermission.Financial_Auditor dynamically renders the component on the page layout for authorized users without modifying Field-Level Security (FLS) settings on the profile.
3
Analyze distractor statements regarding data security and activation limits.
Dynamic UI visibility does not enforce data-level security (FLS/SOQL/Reports). Additionally, Home Pages cannot be assigned by Record Type, and record page assignments do not alter picklist value options.
Underlying data access and picklist configurations remain managed via Field-Level Security and Object Record Type definitions respectively.

Key Concept

Lightning Record Page Activation Precedence and Dynamic Component Visibility Rules
Question 19Question

A Salesforce administrator is configuring component visibility on a Contact Lightning Record Page using Dynamic Forms to hide sensitive identifying information from support users. Which two statements accurately describe the behavior and limitations of Dynamic Forms visibility rules compared to Field-Level Security (FLS)? (Select 2 choices.)

Select all that apply

Show answer & explanation

Answer: Dynamic Forms component visibility rules control the visual display of fields on the Lightning Record Page layout without restricting API access or reports.; Field-Level Security (FLS) enforces data access rules system-wide, ensuring users without field access cannot view the field in reports, API calls, or page layouts.

Answer

Dynamic Forms component visibility rules only control the visual rendering of fields on the specific Lightning Record Page layout without restricting API or reporting access, while Field-Level Security (FLS) enforces data security system-wide across reports, search, and API calls.
Dynamic Forms visibility rules selectively show or hide fields on a Lightning Record Page based on filter criteria, but do not alter object permissions or FLS. Field-Level Security is the authoritative mechanism for securing data across reports, APIs, list views, and search.

Step-by-Step Solution

1
Analyze the scope of Dynamic Forms visibility filters.
Dynamic Forms rules conditionally render UI components/fields on a page layout but do not affect database permissions or external accessibility.
UI visibility is layer-separated from security enforcement.
2
Analyze the scope of Field-Level Security (FLS).
FLS operates at the platform level, restricting data visibility across all interfaces including reports, dashboards, list views, and API calls.
FLS is mandatory platform security.
3
Identify the two accurate statements reflecting this distinction.
The statements confirming UI-only rendering for Dynamic Forms and system-wide enforcement for FLS are correct.
These statements accurately represent Salesforce platform security and UI architecture.

Key Concept

Dynamic Forms Visibility vs Field-Level Security
Question 20Question

A Salesforce Administrator needs to convert a standard Record Detail component on a custom object record page to Dynamic Forms. What is the correct sequence of steps the administrator must take within the Lightning App Builder to complete this migration?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence to convert a page layout to Dynamic Forms is: 1) Open the record page in Lightning App Builder, 2) Select the standard Record Detail component on the canvas, 3) Click 'Upgrade Now' in the component properties pane, 4) Select the source page layout to import fields and sections and complete the wizard, 5) Save and activate the Lightning Record Page.
To migrate an existing record page to Dynamic Forms, an administrator opens the record page in Lightning App Builder, selects the Record Detail component on the canvas, clicks the 'Upgrade Now' action in the properties pane, chooses the source page layout to import existing fields and sections, and finally saves and activates the page.

Step-by-Step Solution

1
Navigate to Lightning App Builder for the target object's record page.
The Lightning App Builder canvas loads with the current page components.
Dynamic Forms setup and page customization take place directly within the Lightning App Builder interface.
2
Click on the standard Record Detail component on the canvas.
The right-hand panel opens, displaying the properties for the Record Detail component.
The migration feature is initiated from the properties panel of the existing Record Detail component.
3
Click the 'Upgrade Now' button in the properties panel.
The Dynamic Forms migration wizard launches.
This action initiates the guided process to break down the monolithic layout into flexible field section components.
4
Select the desired page layout to migrate and complete the wizard steps.
Fields and Field Section components are placed onto the canvas automatically based on the selected layout.
Selecting an existing page layout allows Salesforce to automatically extract fields and sections without manual reconstruction.
5
Save the page and activate it for the appropriate profiles, apps, or org default.
The newly upgraded Dynamic Forms page is deployed to end users.
Changes in Lightning App Builder must be saved and activated before they become visible to users in Salesforce.

Key Concept

Upgrading Record Detail to Dynamic Forms in Lightning App Builder
Estimated Time:1m 30s
Page 1 / 90Next