All practice questions

1784 questions

Question 521Question

An administrator at a renewable energy firm is creating a custom object named `Solar_Panel__c` to track equipment installations in Salesforce. Which two statements are true regarding standard fields and capabilities automatically provided upon creating this custom object? (Select 2)

Select all that apply

Show answer & explanation

Answer: A standard Name field is automatically created and can be configured as either a Text or Auto-Number data type.; Standard system audit fields, including Created By and Last Modified By, are automatically generated upon creation.

Answer

The correct statements are that a standard Name field (configured as Text or Auto-Number) and standard system audit fields (such as Created By and Last Modified By) are automatically generated upon custom object creation.
When creating a new custom object in Salesforce, the platform automatically provisions standard system audit fields (Created By, Last Modified By, Created Date, Last Modified Date) as well as a standard Name field configured as either Text or Auto-Number.

Step-by-Step Solution

1
Identify automatic fields generated during custom object creation
Salesforce automatically generates standard audit fields (CreatedBy, LastModifiedBy, CreatedDate, LastModifiedDate) and a standard Name field (Text or Auto-Number).
These default fields ensure basic auditing capability and record naming for all custom objects.
2
Evaluate relationship deletion behavior and visibility configurations
Deleting a master record deletes child detail records (cascading deletion), and Dynamic Forms visibility only controls page layout display, not API or security access.
Understanding the boundaries of Master-Detail cascade behavior and UI-level visibility prevents misconfigurations.

Key Concept

Standard Fields and Capabilities on Custom Objects
Question 522Question

A renewable energy company needs to immediately block system access for a lead solar consultant who has been placed on administrative leave. When the System Administrator attempts to deactivate the user account, Salesforce prevents the deactivation because the consultant is currently configured as the Default Workflow User in Process Automation Settings. The administrator must immediately stop the consultant from logging into Salesforce while taking time to reassign the workflow responsibilities to another team member. Which action should the administrator take to meet these requirements?

Show answer & explanation

Answer: Freeze the user account immediately, reassign the Default Workflow User setting to a different active user, and then deactivate the user account.

Answer

Freeze the user account immediately, reassign the Default Workflow User setting to a different active user, and then deactivate the user account.
Freezing a user account temporarily blocks the user from logging in immediately without altering license usage or breaking system dependencies (such as being assigned as the Default Workflow User). Once the administrator updates Process Automation Settings to point to another active user, the consultant's account can be safely deactivated.

Step-by-Step Solution

1
Identify the immediate security requirement vs system constraint
Access must be blocked instantly, but deactivation is blocked due to the Default Workflow User dependency.
Deactivating a user who is configured as a Default Workflow User or selected in certain custom fields/hierarchy processes will throw a system error.
2
Apply user freezing
The user is frozen immediately from their User Detail page.
Freezing prevents the user from logging into the org instantly without violating system configuration references.
3
Resolve system dependency and complete deactivation
Update Process Automation Settings to designate another user, then uncheck the Active checkbox on the consultant's user record.
Once the user is no longer referenced as the Default Workflow User, deactivation can proceed successfully to free up the license.

Key Concept

Freezing vs. Deactivating Users in Salesforce
Question 523Question

An administrator at a renewable energy firm needs to grant 15 Field Engineers access to a custom object named Solar Grid Assets without modifying their baseline profile. Additionally, the administrator must consolidate this new access with several existing operational permissions into a single assignment, while ensuring the extra access automatically expires after 90 days. Which TWO administrative actions should the administrator take to fulfill these requirements? (Choose 2)

Select all that apply

Show answer & explanation

Answer: Create a Permission Set granting object access to Solar Grid Assets and assign it with an expiration date using Permission Set Expiration.; Combine the new Permission Set with existing operational Permission Sets into a Permission Set Group for streamlined single-assignment management.

Answer

The administrator should create a Permission Set with the required object permissions and assign it with an expiration date, and consolidate the permission sets into a Permission Set Group for streamlined user assignment.
Permission Sets provide additive permissions for specific users without altering profile definitions, and native user assignment expiration dates handle the 90-day access requirement. Combining Permission Sets into a Permission Set Group enables administrators to manage multiple permission sets as a single bundle for assignment.

Step-by-Step Solution

1
Evaluate the requirement for non-profile additive access and temporary permissions.
Identify that a Permission Set with Permission Set Expiration provides additive object access for a designated time frame without modifying baseline user profiles.
Profiles define base access for entire user groups, while Permission Sets provide flexible, targeted access additions.
2
Evaluate the requirement for managing multiple permission assignments efficiently.
Identify that a Permission Set Group bundles multiple Permission Sets into a single assignable entity.
Permission Set Groups reduce administrative overhead by allowing assignees to receive all required functional permissions in one step.

Key Concept

Permission Sets and Permission Set Groups
Question 524Question

A Salesforce Administrator is configuring a new business process for Tier 3 Support Cases. The administrator creates a new Record Type named 'Enterprise Incident' on the Case object and assigns the 'Enterprise Case Layout' page layout to the Support Manager profile for this record type. After deployment, Support Managers report two issues when working with 'Enterprise Incident' cases:
1. The 'Priority' picklist field displays 'Low' and 'Medium' options, but is missing the newly added 'Urgent Enterprise' picklist value.
2. Users assigned to the 'Tier 3 Specialist' profile report that when they manually edit an existing case's record type to 'Enterprise Incident', the fields displayed on the page layout revert to the default 'Standard Case Layout' instead of the 'Enterprise Case Layout'.

Which combination of configuration adjustments must the administrator make to resolve both issues?

Show answer & explanation

Answer: Edit the 'Priority' picklist settings under the 'Enterprise Incident' Record Type configuration to select 'Urgent Enterprise', and update the Profile Page Layout Assignment matrix to map the 'Enterprise Case Layout' for the 'Enterprise Incident' Record Type across the 'Tier 3 Specialist' profile.

Answer

The administrator must edit the 'Priority' picklist settings directly under the 'Enterprise Incident' Record Type configuration to include 'Urgent Enterprise', and update the Page Layout Assignment matrix to map the 'Enterprise Case Layout' to the 'Enterprise Incident' Record Type for the 'Tier 3 Specialist' profile.
In Salesforce, Record Types control two primary elements: available picklist values for records of that record type, and page layout assignments per profile. Adding a value to a picklist field at the object level does not automatically assign it to a specific Record Type; the administrator must navigate to the Record Type picklist configuration and select the value. Additionally, which page layout a user sees depends on the combination of their Profile and the record's Record Type in the Page Layout Assignment matrix. Updating this matrix for the 'Tier 3 Specialist' profile under the 'Enterprise Incident' record type ensures the correct layout renders.

Step-by-Step Solution

1
Navigate to Object Manager > Case > Record Types > Enterprise Incident > Picklists Available for Editing.
Locate the 'Priority' picklist field within the specific Record Type settings.
Creating a new picklist value at the field level does not automatically enable it for existing or new Record Types. Picklist values must be explicitly selected per Record Type.
2
Move 'Urgent Enterprise' to the Selected Values column and set the appropriate default value if required, then save.
'Urgent Enterprise' becomes selectable when users create or edit records assigned to the 'Enterprise Incident' Record Type.
Record Types dictate picklist value availability independently of global picklist field definitions.
3
Navigate to Object Manager > Case > Page Layouts > Page Layout Assignment.
Open the Page Layout Assignment matrix mapping Profiles against Record Types.
Page layout rendering on standard record pages depends on the profile of the viewing user and the record type of the record being viewed.
4
Edit Assignment and update the intersection cell for the 'Tier 3 Specialist' profile under the 'Enterprise Incident' Record Type to use 'Enterprise Case Layout'.
Users with the 'Tier 3 Specialist' profile see the 'Enterprise Case Layout' whenever a case is assigned to or updated to the 'Enterprise Incident' Record Type.
Without this matrix assignment, Salesforce defaults to the profile's fallback layout or existing assignment for that record type.

Key Concept

Page Layout Assignment Matrix and Record Type Picklist Value Selection
Question 525Question

A Salesforce administrator creates a customized Lightning Record Page for the Account object. The administrator needs to ensure that this custom page serves as the global fallback layout for all users in the organization whenever a more specific app or profile override is not assigned. Which activation level in the Lightning App Builder should the administrator select?

Show answer & explanation

Answer: Org Default

Answer

The administrator should select Org Default as the activation level.
Selecting Org Default makes the Lightning Record Page the baseline default layout for all record views across the entire Salesforce organization, serving as the fallback when no specific App or Profile assignments are configured.

Step-by-Step Solution

1
Navigate to Activation settings in Lightning App Builder
Open the Activation dialog for the custom Account Lightning Record Page.
Record pages must be activated before they can be displayed to users.
2
Select the activation scope
Choose Org Default to assign the page as the organization-wide baseline page.
Org Default ensures the page is used across the entire org unless overridden by App Default or App/Record Type/Profile assignments.

Key Concept

Lightning Record Page Activation Levels
Question 526Question

A Salesforce administrator at a logistics company wants to create an aggregate calculation on the custom Equipment__c object to display the total maintenance cost of all associated Work_Order__c records. Currently, Work_Order__c is linked to Equipment__c via a Lookup relationship. Which two statements describe the configurations or behavior required when creating a native Roll-Up Summary field for this scenario? (Select 2)

Select all that apply

Show answer & explanation

Answer: The existing Lookup relationship must be converted to a Master-Detail relationship before a native Roll-Up Summary field can be created on Equipment__c.; Converting to a Master-Detail relationship causes all associated Work_Order__c records to be automatically deleted if their parent Equipment__c record is deleted.

Answer

The existing Lookup relationship must be converted to a Master-Detail relationship before a native Roll-Up Summary field can be created, and converting to a Master-Detail relationship causes associated detail records to be automatically deleted if the master record is deleted.
Native Roll-Up Summary fields are supported strictly on the master object within Master-Detail relationships, which requires converting the current Lookup relationship. Additionally, converting to a Master-Detail relationship implies cascading deletion, where deleting a master record automatically removes linked detail records.

Step-by-Step Solution

1
Analyze relationship requirements for native Roll-Up Summary fields.
Roll-Up Summary fields require a Master-Detail relationship.
Lookup relationships do not support native declarative roll-up summary fields.
2
Identify cascading deletion behavior in Master-Detail relationships.
Deleting the master Equipment__c record deletes linked detail records.
Detail records inherit access and lifecycle management strictly from the master record.

Key Concept

Roll-Up Summary Field Prerequisites and Master-Detail Deletion Behavior
Question 527Question

A support administrator is managing global service operations with distinct regional Business Hours and customized Holiday schedules. Case Escalation Rules are configured to determine when unassigned support tickets must be escalated to tier-2 managers. Which TWO statements correctly describe how Salesforce evaluates Business Hours, Holidays, and Time Zones during case escalation processing?

Select all that apply

Show answer & explanation

Answer: Escalation rule timers pause calculation outside of the active Business Hours designated for the case or escalation rule entry.; Holidays must be explicitly associated with a Business Hours schedule to suspend case escalation timing on designated holiday dates.

Answer

Escalation rule timers pause calculation outside of active Business Hours, and Holidays must be explicitly associated with a Business Hours schedule to suspend case escalation timing.
Case escalation rule timers only run during the active windows specified in the applicable Business Hours schedule. Furthermore, holidays suspend escalation clocks only when they are explicitly linked to that specific Business Hours schedule.

Step-by-Step Solution

1
Analyze how Business Hours affect Case Escalation Rules.
Escalation timers adhere strictly to the Business Hours specified on the case (or escalation rule entry). When outside active hours, the timer pauses.
This prevents support tickets from escalating unexpectedly overnight or during weekends.
2
Evaluate how Holidays interact with Business Hours.
Holidays must be linked to specific Business Hours schedules to take effect.
Different global regions observe different holidays; associating holidays at the Business Hours level ensures regional compliance.
3
Review user time zone rendering behavior.
Date/Time fields are displayed in the logged-in user's personal time zone.
Salesforce converts underlying UTC values to the user's localized time zone upon display.

Key Concept

Business Hours and Holiday association rules with Case Escalation Timers
Question 528Question

A Salesforce administrator at Cloud Logistics needs to grant access to view and edit the sensitive Account_Balance__c custom field on the Account object for two specific members of the finance team. Currently, Field-Level Security (FLS) restricts visibility of this field for all users assigned to the Standard User profile. Which two actions should the administrator take to achieve this requirement securely without affecting other Standard User profile members? (Choose 2 answers)

Select all that apply

Show answer & explanation

Answer: Create a permission set that grants Read and Edit field-level security access to the Account_Balance__c field.; Assign the permission set containing the field access to the two finance team members.

Answer

The administrator should create a permission set granting Read and Edit access to the Account_Balance__c field and assign that permission set to the two finance team members.
The correct solution involves creating a permission set that grants Read and Edit Field-Level Security (FLS) for the Account_Balance__c field and assigning that permission set to the two finance team members. In Salesforce, profiles establish baseline access, while permission sets are used to grant additive privileges to specific users without increasing profile management overhead.

Step-by-Step Solution

1
Identify the base security requirement and the scope of users requiring elevated access.
Recognized that only two users out of a larger profile group need access to the Account_Balance__c field.
Profiles define baseline access, whereas additive access for specific individual users should be handled via permission sets.
2
Configure a permission set with the appropriate Field-Level Security.
Created a permission set that enables Read and Edit permissions for Account_Balance__c.
Field-Level Security in permission sets expands visibility for assigned users without modifying profile settings for others.
3
Assign the created permission set to the target finance team members.
The two finance team members gain field access, while all other Standard User profile members remain restricted.
Direct permission set assignment ensures secure, targeted privilege delegation.

Key Concept

Using Permission Sets for Additive Field-Level Security
Estimated Time:1m 0s
Question 529Question

Helios Energy Solutions maintains a sensitive custom field, Audit_Status__c, on the Account object. Currently, twelve employees share the standard Sales User profile, but only two of these users serve as compliance auditors who require Read and Edit access to Audit_Status__c. The remaining ten sales representatives must be restricted from accessing this field across all interfaces, including reports, list views, and API integrations. Which administrative action represents the optimal configuration to meet these requirements following Salesforce security best practices?

Show answer & explanation

Answer: Restrict Field-Level Security (FLS) on Audit_Status__c for the Sales User profile, create a Permission Set granting Read and Edit access to the field, and assign it to the two compliance auditors.

Answer

Restrict Field-Level Security on the custom field for the base profile, then create and assign a Permission Set to grant Read and Edit access specifically to the compliance auditors.
The optimal solution is to restrict Field-Level Security (FLS) on the custom field at the profile level so that sales reps cannot access the field via any channel. Then, a Permission Set granting Read and Edit permissions on the field should be assigned to the two compliance auditors. This follows Salesforce best practices by keeping profiles clean and using permission sets for additive access.

Step-by-Step Solution

1
Evaluate the baseline security configuration requirement for the general user population.
Since ten out of twelve users on the Sales User profile must not see or edit Audit_Status__c anywhere in Salesforce, the field must be hidden at the Profile level using Field-Level Security (FLS).
Field-Level Security enforced at the profile level restricts visibility across all entry points, including reports, list views, search results, and API queries.
2
Determine the optimal mechanism to grant elevated access to the sub-group of two compliance auditors.
Create a Permission Set with Read and Edit access enabled for Audit_Status__c and assign it directly to the two compliance auditors.
Salesforce security architecture relies on Profiles for base restrictive/default access and Permission Sets for granting additive permissions to specific users.

Key Concept

Profiles establish restrictive baseline security while Permission Sets grant additive field and object access.
Question 530Question

A wealth advisory firm uses a custom object named Investment_Portfolio__c to track high-net-worth client asset allocations. The company's security policy mandates that portfolio advisors should only view and edit portfolios they personally own. However, regional directors above those advisors in the role hierarchy must automatically inherit full view and edit access to all portfolios owned by their direct and indirect subordinates. Peer advisors in different branches must have no access to each other's portfolio records. Which TWO configurations must the administrator implement to establish this baseline access model? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Set the Default Internal Access for the Investment_Portfolio__c object to Private.; Ensure the Grant Access Using Hierarchies setting remains selected for the Investment_Portfolio__c object.

Answer

To enforce the required security model, the administrator must set the Default Internal Access for Investment_Portfolio__c to Private and ensure that Grant Access Using Hierarchies is checked.
Setting the Default Internal Access to Private ensures that record access is restricted to record owners by default. Keeping Grant Access Using Hierarchies enabled ensures that managers situated higher in the role hierarchy automatically inherit access to records owned by their subordinates.

Step-by-Step Solution

1
Determine the most restrictive baseline access required for peer users.
Since peer advisors must not see each other's records, the baseline Organization-Wide Default (OWD) must be set to Private.
OWD is the only mechanism that sets the base level of record-level access across the organization.
2
Evaluate manager access requirements above record owners in the reporting structure.
Keep the 'Grant Access Using Hierarchies' checkbox selected on the custom object configuration.
For custom objects, Grant Access Using Hierarchies is checked by default and allows users above the record owner in the role hierarchy to automatically inherit access.

Key Concept

Organization-Wide Defaults (OWD) and Role Hierarchy Record Access
Question 531Question

An administrator at a renewable energy firm is building an inspection tracking architecture using a custom object named Solar_Inspection__c, which links to a parent custom object named Solar_Site__c. The business requirement demands calculating the aggregate total count of inspections directly on the Solar_Site__c record. However, when the administrator attempts to create a new field on Solar_Site__c, the Roll-Up Summary field type option is greyed out and unavailable. Which scenario explains why this field type is unavailable, and what prerequisite step is required to enable it?

Show answer & explanation

Answer: The relationship between Solar_Inspection__c and Solar_Site__c is currently configured as a Lookup relationship; the administrator must convert it to a Master-Detail relationship after ensuring all Solar_Inspection__c records have a populated lookup value.

Answer

The relationship between Solar_Inspection__c and Solar_Site__c is currently configured as a Lookup relationship; the administrator must convert it to a Master-Detail relationship after ensuring all Solar_Inspection__c records have a populated lookup value.
In Salesforce Core Administration, declarative Roll-Up Summary fields are exclusively available on the master object of a Master-Detail relationship. When a Lookup relationship is used, the system grey-outs the Roll-Up Summary option. To convert a Lookup relationship to a Master-Detail relationship, all existing child records must have a value in the lookup field.

Step-by-Step Solution

1
Identify the relationship type between the child object (Solar_Inspection__c) and the parent object (Solar_Site__c).
Determine that Roll-Up Summary fields are strictly limited to the parent/master side of a Master-Detail relationship.
Salesforce standard functionality prohibits Roll-Up Summary fields across standard Lookup relationships without custom code or declarative automation tools.
2
Verify data completeness across existing child records.
Ensure that every existing Solar_Inspection__c record contains a valid, non-null reference to a Solar_Site__c record.
Converting a Lookup field to a Master-Detail relationship will fail if any existing child record has a blank parent lookup field, as Master-Detail relationships require mandatory parent linkage.
3
Convert the relationship field type in Object Manager and create the Roll-Up Summary field on Solar_Site__c.
The Roll-Up Summary field type becomes available for selection on the master object once the relationship is Master-Detail.
Master-Detail relationships enforce tight coupling and data integrity required for real-time declarative aggregation calculations.

Key Concept

Roll-Up Summary Field Eligibility and Relationship Conversion Prerequisites
Question 532Question

A Salesforce administrator wants to create a field on the custom Invoice object to display the total monetary amount of all related Invoice Line Item records. While launching the Custom Field wizard on the Invoice object, the administrator notices that the Roll-Up Summary field type option is disabled (greyed out). What is the primary cause of this issue?

Show answer & explanation

Answer: The Invoice Line Item object is linked to the Invoice object using a Lookup relationship rather than a Master-Detail relationship.

Answer

The Roll-Up Summary field type is disabled because Roll-Up Summary fields require a Master-Detail relationship, whereas the objects currently use a Lookup relationship.
In Salesforce, Roll-Up Summary fields can only be created on the master object of a Master-Detail relationship. If two objects are connected via a standard Lookup relationship, the Roll-Up Summary option will be greyed out and unavailable during field creation.

Step-by-Step Solution

1
Identify the relationship requirement for Roll-Up Summary fields in Salesforce.
Roll-Up Summary fields can only be created on the master object in a Master-Detail relationship.
Salesforce platform architecture does not support native Roll-Up Summary fields across standard Lookup relationships without declarative automation or Apex.
2
Analyze why the Roll-Up Summary field type is disabled on the Invoice object.
The Invoice object is not defined as the master object in a Master-Detail relationship with Invoice Line Item.
If the relationship is a Lookup relationship, Salesforce disables the Roll-Up Summary option during custom field creation.

Key Concept

Roll-Up Summary Field Relationship Prerequisites
Question 533Question

A Salesforce Administrator needs to calculate the total cost of maintenance records on a parent custom object, Equipment__c. However, when attempting to create a new custom field on Equipment__c, the Roll-Up Summary field type option is greyed out and unavailable. Which relationship configuration explains why the Roll-Up Summary field cannot be created?

Show answer & explanation

Answer: The child object is linked to Equipment__c through a Lookup relationship.

Answer

The child object is linked to Equipment__c through a Lookup relationship.
In Salesforce, Roll-Up Summary fields can only be created on the master object in a Master-Detail relationship. When objects are connected via a Lookup relationship, the Roll-Up Summary field type is unavailable because lookup relationships do not maintain the strict parent-child data dependency required for native summary aggregations.

Step-by-Step Solution

1
Identify the relationship requirements for Roll-Up Summary fields.
Roll-Up Summary fields require a Master-Detail relationship between the parent (master) and child (detail) objects.
Salesforce native summary aggregation relies on the strict parent-child relationship enforced by Master-Detail relationships.
2
Analyze why the Roll-Up Summary option is unavailable on Equipment__c.
The target child object is connected to Equipment__c via a Lookup relationship.
Lookup relationships are loosely coupled and do not support standard native Roll-Up Summary fields.

Key Concept

Roll-Up Summary fields are only supported on the master object in a Master-Detail relationship.
Question 534Question

An administrator at Cloud Kicks needs to track maintenance history on custom machinery. Currently, a custom child object named Maintenance_Log__c connects to a custom parent object named Machine__c via a standard Lookup relationship. The business analyst specifies two new requirements: first, the Machine__c record must automatically display the total cost of all related maintenance logs using a declarative aggregate field; second, deleting a Machine__c record must automatically remove all of its associated Maintenance_Log__c records. When attempting to create the aggregate field on Machine__c, the administrator notices that the Roll-Up Summary field type is unavailable. Which action must the administrator take to satisfy both business requirements?

Show answer & explanation

Answer: Ensure every existing Maintenance_Log__c record has a populated Machine__c lookup value, then convert the relationship field type on Maintenance_Log__c from Lookup to Master-Detail.

Answer

Ensure every existing Maintenance_Log__c record has a populated Machine__c lookup value, then convert the relationship field type on Maintenance_Log__c from Lookup to Master-Detail.
To create a declarative Roll-Up Summary field on a parent object, a Master-Detail relationship must be present. Additionally, converting an existing Lookup relationship to a Master-Detail relationship requires that all existing child records contain populated parent lookup values. Once the field is converted to Master-Detail, cascading deletion of child records is automatically enforced upon master record deletion.

Step-by-Step Solution

1
Analyze the business requirements for data aggregation and deletion behavior.
Requirements call for a declarative Roll-Up Summary field on the parent object and automatic cascade deletion of child records when a parent is deleted.
Roll-Up Summary fields and cascading deletion are capabilities inherent strictly to Master-Detail relationships, not Lookup relationships.
2
Identify the prerequisite conditions for converting a Lookup relationship to a Master-Detail relationship.
All existing child records (Maintenance_Log__c) must have a non-null reference in the lookup field before conversion is permitted.
Master-Detail relationships enforce data integrity where child records cannot exist without a valid master parent.
3
Perform the relationship conversion and configure the Roll-Up Summary field.
Once converted to Master-Detail, the Roll-Up Summary field type becomes available on Machine__c, and deletion of a Machine__c record automatically cascades to related Maintenance_Log__c records.
This single configuration change fulfills both business requirements declaratively.

Key Concept

Master-Detail Relationship Capabilities and Conversion Requirements
Estimated Time:2m 0s
Question 535Question

A Salesforce administrator at a software firm attempts to deactivate a user record for a departing employee. However, deactivation fails because the user is specified in a custom hierarchy field used by an active approval process. The administrator must immediately prevent this employee from logging into the organization while reconfiguring the approval workflow.

Which action should the administrator take to fulfill this immediate requirement?

Show answer & explanation

Answer: Freeze the user account.

Answer

The administrator should freeze the user account.
Freezing a user account is the designated feature to temporarily or immediately prevent a user from logging into Salesforce when the user cannot be deactivated right away due to dependencies like approval processes, workflow rules, or apex scripts.

Step-by-Step Solution

1
Identify the administrative constraint preventing account deactivation.
Deactivation is blocked because the user is referenced in a custom hierarchy field tied to an active approval process.
Salesforce prevents direct deactivation when a user is tied to specific active system components such as custom hierarchy fields or default workflow owners.
2
Select the appropriate alternative mechanism to immediately block login access.
Freezing the user account prevents login access immediately.
Freezing temporarily stops a user from logging in while preserving their license and allowing administrators time to update system references before performing full deactivation.

Key Concept

Freezing versus Deactivating Users in Salesforce
Estimated Time:45s
Question 536Question

A Salesforce Administrator at a commercial wholesale distributor is configuring calculations between a custom master object, Purchase_Order__c, and a custom detail object, Purchase_Order_Line__c, connected via a Master-Detail relationship. The business requires displaying the aggregated total value of line items on the purchase order record, where line item unit prices are derived from a cross-object formula referencing a related Product2 record. Which TWO considerations and system limitations must the administrator account for when implementing this calculation? (Select 2)

Select all that apply

Show answer & explanation

Answer: Roll-Up Summary fields cannot aggregate a custom formula field on a detail object if that formula references fields from another related object across a lookup relationship.; Native Roll-Up Summary functionality is available for this requirement because Purchase_Order__c and Purchase_Order_Line__c share a Master-Detail relationship rather than a Lookup relationship.

Answer

The administrator must account for the restriction that Roll-Up Summary fields cannot aggregate cross-object formulas on detail records, and recognize that native Roll-Up Summary capability is available specifically because the objects share a Master-Detail relationship.
The correct statements correctly identify the fundamental relationship prerequisite for native Roll-Up Summary fields (Master-Detail) and the specific system limitation regarding cross-object formulas on detail objects. When a detail record's formula field references another object via a lookup relationship, it cannot be targeted by a Roll-Up Summary field on the master record.

Step-by-Step Solution

1
Evaluate relationship type requirements for native Roll-Up Summary fields.
Confirm that native Roll-Up Summary fields are built on the master object in a Master-Detail relationship, which is satisfied by Purchase_Order__c being the master.
Salesforce platform limits native roll-up summary creation strictly to Master-Detail relationships.
2
Analyze formula field limitations within Roll-Up Summary field definitions.
Identify that if Purchase_Order_Line__c uses a formula field referencing Product2 (a cross-object lookup reference), that formula field cannot be selected in a SUM roll-up calculation.
Declarative roll-up summaries cannot dynamically calculate values derived from cross-object spans on child records.

Key Concept

Roll-Up Summary Field Requirements and Cross-Object Formula Restrictions
Question 537Question

Solaris Clean Energy uses a custom object named Site_Inspection__c to log site safety reviews. The Organization-Wide Default (OWD) for Site_Inspection__c is configured as Private. To comply with privacy requirements for individual inspection reports, the System Administrator deselects the 'Grant Access Using Hierarchies' setting for Site_Inspection__c.

Later, to facilitate management oversight of urgent compliance issues, the administrator creates a criteria-based sharing rule that shares all Site_Inspection__c records where Safety_Risk__c = 'High' with the 'Regional Safety Lead' role, granting Read/Write access. A user assigned to the 'VP of Operations' role—which sits directly above the 'Regional Safety Lead' role in the role hierarchy—attempts to open a 'High' risk inspection record owned by a field auditor.

Which statement accurately describes the level of access the VP of Operations will have to this record?

Show answer & explanation

Answer: The VP of Operations will have no access to the record because deselecting Grant Access Using Hierarchies prevents automatic upward access inheritance through the role hierarchy.

Answer

The user in the VP of Operations role will have no access to the record because deselecting Grant Access Using Hierarchies for a custom object disables automatic upward access inheritance, even for records shared via sharing rules.
For custom objects in Salesforce, the 'Grant Access Using Hierarchies' option can be deselected. When deselected, users higher in the role hierarchy do NOT automatically gain access to records owned by or shared with users below them in the hierarchy. Consequently, the executive role receives no access to the record shared with the regional role.

Step-by-Step Solution

1
Evaluate the baseline Organization-Wide Default (OWD) and hierarchy settings.
The OWD for Site_Inspection__c is Private, and 'Grant Access Using Hierarchies' is unchecked (disabled).
For standard objects, hierarchy access is always enabled. For custom objects, deselecting this option stops users higher in the role hierarchy from automatically inheriting record access owned by or shared with subordinate roles.
2
Analyze the scope of the criteria-based sharing rule.
The rule shares 'High' risk records directly with the 'Regional Safety Lead' role with Read/Write access.
The rule explicitly grants access to members of the Regional Safety Lead role.
3
Determine whether the VP of Operations inherits access from the Regional Safety Lead role.
Because 'Grant Access Using Hierarchies' is disabled on the custom object, the VP of Operations role does not inherit access granted to the lower role via the sharing rule.
Disabling hierarchy access for custom objects blocks all implicit upward inheritance for both record ownership and shared record access.

Key Concept

Custom Object Hierarchy Access Control
Estimated Time:1m 30s
Question 538Question

A financial firm requires custom password security controls for users assigned to the Support Specialist profile. Specifically, these users must have their passwords expire every 30 days, and their accounts must lock out after 3 invalid login attempts. All other users in the organization must retain the default organization-wide settings. Which TWO administrative actions should the Salesforce administrator take to enforce these profile-specific requirements? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Set the User Password Expires In setting to 30 days within the Support Specialist profile Password Policies.; Set the Maximum Invalid Login Attempts setting to 3 within the Support Specialist profile Password Policies.

Answer

The administrator must configure both the User Password Expires In setting to 30 days and the Maximum Invalid Login Attempts setting to 3 within the Support Specialist profile Password Policies.
In Salesforce, password policies configured at the profile level override organization-wide default password policies. Setting 'User Password Expires In' to 30 days and 'Maximum Invalid Login Attempts' to 3 within the Support Specialist profile Password Policies enforces these security rules strictly for assigned users without altering password policies for the rest of the organization.

Step-by-Step Solution

1
Identify the target profile requiring non-default password policy settings.
Determined that the updated expiration and lockout requirements apply exclusively to the Support Specialist profile.
Profile-level password policies allow administrators to override org-wide defaults for specific user groups.
2
Navigate to the Password Policies section of the Support Specialist profile.
Opened the profile-specific security settings interface.
Custom password rules must be set directly on the profile to avoid affecting other profiles.
3
Update the password expiration and invalid login attempt settings.
Set User Password Expires In to 30 days and Maximum Invalid Login Attempts to 3.
These two parameters satisfy the compliance mandate while leaving org-wide defaults intact for all other users.

Key Concept

Profile-level Password Policies override Organization-Wide Password Policies and cannot be managed using Permission Sets.
Estimated Time:1m 30s
Question 539Question

A global aviation maintenance company has 20 Aircraft Fleet Managers assigned to a standard baseline profile named 'Fleet Operations User'. Due to new regulatory guidelines, 4 of these managers need Read and Edit access to a custom object named 'Aircraft Inspection Logs' to record compliance data, while the remaining 16 managers should not have access to this object. Which administrative solution efficiently fulfills this access requirement without granting unnecessary permissions?

Show answer & explanation

Answer: Create a Permission Set granting Read and Edit access to the Aircraft Inspection Logs object and assign it to the 4 Fleet Managers who require the access.

Answer

Create a Permission Set granting Read and Edit access to the Aircraft Inspection Logs object and assign it to the 4 Fleet Managers who require access.
Permission Sets allow administrators to grant flexible, additive permissions (such as Object-Level Read and Edit access) to individual users or subsets of users without altering their underlying profile or creating new profiles.

Step-by-Step Solution

1
Analyze the access baseline and requirement scope.
All 20 users share a single baseline profile, but only a subset (4 users) requires additional object access.
Salesforce security best practice specifies using profiles for baseline permissions common to all users and Permission Sets for granting additive permissions to subset populations.
2
Evaluate administrative overhead and scalability.
Creating a single Permission Set avoids profile proliferation and avoids granting unintended permissions to the other 16 users.
Modifying or cloning profiles to manage small groups of users creates unnecessary maintenance overhead.

Key Concept

Using Permission Sets to grant additive object permissions to a subset of users sharing a profile
Question 540Question

A Salesforce administrator configures component visibility on a Lightning Record Page to hide a rich text field containing sensitive data from users who do not have the 'System Administrator' profile. A team member asserts that this configuration fully secures the data against unauthorized user access. Why is this assertion incorrect?

Show answer & explanation

Answer: Component visibility rules on Lightning pages only control UI display and do not restrict data access via reports, list views, or APIs.

Answer

Component visibility rules on Lightning pages only control UI display and do not restrict data access via reports, list views, or APIs.
Lightning App Builder component visibility filters control rendering on record pages, but they do not secure the underlying data. Users with field-level access can still view the field via reports, SOQL/APIs, or list views.

Step-by-Step Solution

1
Analyze the purpose of Lightning App Builder component visibility filters.
Recognize that visibility filters hide or reveal components dynamically on the user interface based on specified criteria.
Component visibility rules are designed for user interface customization, not security enforcement.
2
Evaluate data access mechanisms in Salesforce.
Understand that users can still query, report on, or view fields via list views or API integrations if they hold Field-Level Security (FLS) access.
True data security is governed by Object Permissions, Field-Level Security, and Sharing Rules.

Key Concept

Lightning App Builder Component Visibility vs. Field-Level Security
PreviousPage 27 / 90Next
All practice questions — Salesforce Certified Administrator | Examkin