All practice questions

1784 questions

Question 401Question

An organization requires a custom data model to track equipment assignments between technicians and tools. A single equipment assignment record must link one technician to one tool, forming a many-to-many relationship between technicians and tools. The business analyst specifies the following operational rules:
1. If a technician record is deleted, all associated equipment assignment records must be automatically removed.
2. If a tool record is deleted, associated equipment assignment records must remain in the system for auditing purposes.
3. Executive leadership must be able to view total assigned equipment counts directly on technician records using standard declarative aggregate fields.

Which TWO configuration steps must the administrator implement on the Equipment_Assignment__c custom object to meet these requirements? (Choose 2 answers)

Select all that apply

Show answer & explanation

Answer: Define a Master-Detail relationship field on Equipment_Assignment__c that references Technician__c.; Define a Lookup relationship field on Equipment_Assignment__c that references Tool__c.

Answer

The administrator must create a Master-Detail relationship pointing to Technician__c and a Lookup relationship pointing to Tool__c on the Equipment_Assignment__c junction object.
To satisfy all requirements, Equipment_Assignment__c acts as a junction object. Configuring a Master-Detail relationship to Technician__c ensures automatic deletion cascade when a technician is removed and allows standard Roll-Up Summary fields on Technician__c. Configuring a Lookup relationship to Tool__c prevents tool deletions from cascading to equipment assignments, preserving assignment history.

Step-by-Step Solution

1
Analyze deletion cascade requirements for Technician__c
Technician__c must be the master in a Master-Detail relationship with Equipment_Assignment__c so that deleting a technician record automatically cascades deletion to detail records.
Master-Detail relationships enforce parent-child deletion cascade behavior.
2
Analyze deletion behavior and auditing requirements for Tool__c
Equipment_Assignment__c must use a Lookup relationship to reference Tool__c.
Lookup relationships allow child records to persist independently when parent records are deleted.
3
Analyze standard Roll-Up Summary capabilities on Technician__c and Tool__c
Roll-Up Summary fields are natively supported on Technician__c because it is the master object, whereas Tool__c cannot use standard Roll-Up Summary fields due to the Lookup link.
Salesforce platform rules strictly limit standard Roll-Up Summary fields to the master side of Master-Detail relationships.

Key Concept

Designing Many-to-Many Junction Objects with Mixed Master-Detail and Lookup Relationships
Estimated Time:3m 0s
Question 402Question

An administrator needs to ensure that users assigned to the Standard User profile cannot view or edit the custom field Bonus_Amount__c on Opportunity records across reports, list views, and API integrations. Which configuration change should the administrator make to fulfill this requirement?

Show answer & explanation

Answer: Set the Field-Level Security for Bonus_Amount__c to hidden on the Standard User profile by removing Read and Edit access.

Answer

Set the Field-Level Security for Bonus_Amount__c to hidden on the Standard User profile by removing Read and Edit access.
Field-Level Security (FLS) is the authoritative security mechanism in Salesforce for controlling field visibility and editability across the entire platform, including reports, list views, and API calls. Removing Read access via FLS ensures the field is completely hidden from users assigned to that profile.

Step-by-Step Solution

1
Identify the security scope required by the scenario.
The requirement demands restricting access across all user interfaces, reports, list views, and API calls.
UI-only restrictions (such as page layouts or Dynamic Forms) do not restrict access in reports or API calls.
2
Select the appropriate access control mechanism in Salesforce.
Field-Level Security (FLS) on the profile directly controls visibility and editability across all surfaces.
Removing Read access via FLS completely hides the field from the specified profile.

Key Concept

Field-Level Security (FLS) enforcement vs UI visibility
Question 403Question

A corporate training firm uses a custom object named Certification_Attempt__c to track employee exam results. Executive leadership mandates that test results must remain confidential: individual employees should only see their own exam records, while managers higher in the role hierarchy must be able to view and edit records owned by their direct reports. No other users should have access to records they do not own. Which Organization-Wide Default (OWD) configuration meets these security requirements?

Show answer & explanation

Answer: Set the Default Internal Access for Certification_Attempt__c to Private and keep Grant Access Using Hierarchies selected.

Answer

Set the Default Internal Access for Certification_Attempt__c to Private and keep Grant Access Using Hierarchies selected.
Setting the Organization-Wide Default (OWD) to Private restricts baseline record access so users can only view and edit records they own. Leaving 'Grant Access Using Hierarchies' enabled ensures that users higher in the role hierarchy automatically inherit the owner's access level, fulfilling the requirement for manager access without exposing data to peers.

Step-by-Step Solution

1
Determine the most restrictive baseline access required by the business scenario.
Since employees must not see records owned by peers, the Organization-Wide Default (OWD) must be set to Private.
OWD defines the baseline level of access for all users in the org.
2
Evaluate how managerial access should be granted.
Retain the default setting 'Grant Access Using Hierarchies' enabled.
For custom objects, Grant Access Using Hierarchies is checked by default and allows users above the record owner in the role hierarchy to inherit the owner's access level.
3
Verify that profiles or permission sets are not being used to restrict baseline access.
Confirm that OWD provides the restrictive foundation, rather than attempting profile-level restrictions.
In the Salesforce security model, profiles and permission sets grant permissions and cannot revoke access provided by OWD.

Key Concept

Organization-Wide Defaults (OWD) establish the baseline record-level access. Setting an OWD to Private ensures users only access records they own, while Grant Access Using Hierarchies automatically propagates access up the role hierarchy.
Question 404Question

An administrator is designing fields to summarize child record data on a parent object. Which two capabilities or requirements apply to Roll-Up Summary fields? (Select 2)

Select all that apply

Show answer & explanation

Answer: Roll-Up Summary fields can only be created on the master object in a Master-Detail relationship.; Roll-Up Summary fields support aggregation operations such as SUM, MIN, MAX, and COUNT.

Answer

Roll-Up Summary fields require a Master-Detail relationship and can perform SUM, MIN, MAX, and COUNT aggregations on detail records.
Roll-Up Summary fields can only be created on the master object in a Master-Detail relationship and allow administrators to calculate aggregate values including SUM, MIN, MAX, and COUNT of related child records.

Step-by-Step Solution

1
Identify the relationship requirement for Roll-Up Summary fields.
Roll-Up Summary fields are strictly supported on the master object within a Master-Detail relationship, not on Lookup relationships.
Salesforce architecture requires tight data coupling provided by Master-Detail relationships to automatically calculate roll-ups.
2
Determine the available aggregate functions.
Supported roll-up functions include COUNT, SUM, MIN, and MAX.
These built-in functions allow administrators to aggregate numeric, currency, date, and field count values from child records.

Key Concept

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

Cloud Kicks tracks custom Project__c records that are linked to the standard AccountAccount object via a Lookup relationship, allowing independent record ownership and security settings. The executive team requires a real-time field on the AccountAccount record displaying the total budget of all related active projects. When attempting to create a new field on AccountAccount, the administrator observes that the Roll-Up Summary field type is disabled. What is the fundamental cause of this behavior, and how should the administrator meet the requirement using declarative functionality?

Show answer & explanation

Answer: Roll-Up Summary fields require a Master-Detail relationship; the administrator should create a custom currency field on Account and use a Record-Triggered Flow on Project__c to recalculate the total upon record creation, update, or deletion.

Answer

Roll-Up Summary fields require a Master-Detail relationship; the administrator should create a custom currency field on Account and use a Record-Triggered Flow on Project__c to recalculate the total upon record creation, update, or deletion.
The correct response identifies that declarative Roll-Up Summary fields are structurally limited to Master-Detail relationships. Because the business requirement explicitly demands independent record ownership and security on the child object (which Lookup relationships provide), converting the relationship to Master-Detail would violate sharing and deletion requirements. Therefore, creating a custom target field on the parent object updated via a Record-Triggered Flow on the child object is the proper declarative solution.

Step-by-Step Solution

1
Analyze the relationship model requirements
Identified that independent record ownership and security settings require a Lookup relationship rather than a Master-Detail relationship.
Master-Detail relationships inherit sharing and security from the master record and do not allow independent owner assignment on child records.
2
Evaluate platform limits for Roll-Up Summary fields
Confirmed that native Roll-Up Summary fields are disabled because the parent object is linked via a Lookup relationship.
Salesforce declarative Roll-Up Summary fields are supported only on the master side of Master-Detail relationships.
3
Design the declarative automation solution
Selected a combination of a custom numeric/currency field on Account and a Record-Triggered Flow on Project__c to update the total asynchronously/synchronously on record changes.
Record-Triggered Flows provide declarative aggregation capability without compromising the underlying object relationship structure.

Key Concept

Roll-Up Summary Field Eligibility and Lookup Aggregation Strategies
Question 406Question

A company uses a custom object named Project_Proposal__c with an Organization-Wide Default (OWD) set to Private. The administrator needs to ensure that managers automatically gain record access to proposals created by their direct subordinates in the role hierarchy, and that all members of the Finance team have read-only access to all proposals. Which two administration settings will fulfill these requirements? (Select 2)

Select all that apply

Show answer & explanation

Answer: Ensure 'Grant Access Using Hierarchies' remains enabled for the Project Proposal custom object.; Create a sharing rule to share all Project Proposal records with the Finance role or public group with Read-Only access.

Answer

The correct configurations are ensuring 'Grant Access Using Hierarchies' remains enabled for automatic manager access via the role hierarchy, and creating a sharing rule granting Read-Only access to the Finance role or public group.
For custom objects with Private OWD, enabling 'Grant Access Using Hierarchies' ensures managers inherit record visibility from subordinate record owners. Additionally, a sharing rule is the standard mechanism to grant access to a broader group of users like the Finance team beyond OWD.

Step-by-Step Solution

1
Evaluate record access requirements for managers.
Manager access up the role hierarchy is provided by default when 'Grant Access Using Hierarchies' is enabled on custom objects.
This setting ensures superior roles automatically inherit record access granted to direct and indirect subordinate roles.
2
Evaluate record access requirements for the Finance team across the organization.
Creating an owner-based or criteria-based sharing rule grants Read-Only access to the designated Finance role or public group.
Sharing rules extend record-level access above OWD defaults to specified groups or roles.
3
Distinguish object-level permissions from record-level sharing.
Permission sets only open object/field access, not individual record visibility.
Object permissions allow users to view the object type, but OWD and sharing mechanisms determine which specific records are accessible.

Key Concept

Role Hierarchy and Sharing Rules record access expansion
Estimated Time:1m 0s
Question 407Question

A Salesforce administrator at an aviation maintenance company is configuring custom fields on the custom object Aircraft_Inspection__c. The object uses multiple record types to differentiate routine maintenance from emergency repairs. After creating a new picklist custom field named Inspection_Grade__c with five values, the administrator notices that end users are unable to see the new picklist values when creating records under specific record types. Which action should the administrator take to resolve this issue?

Show answer & explanation

Answer: Edit each record type configuration on the object to select and enable the specific picklist values available for that record type.

Answer

The administrator must edit each record type configuration on the Object Manager to explicitly select and assign the active picklist values allowed for that record type.
In Salesforce, when an object utilizes Record Types, the availability of picklist values is controlled at the Record Type level. Creating a custom picklist field adds values to the master picklist definition, but administrators must explicitly edit each Record Type configuration to choose which picklist values should be available to users assigned to that record type.

Step-by-Step Solution

1
Identify the cause of missing picklist values on specific record types.
When an object has multiple record types, adding new picklist values or custom picklist fields requires manual assignment of those values to each relevant record type.
Record types control which picklist values are accessible to users assigned to those record types.
2
Navigate to Object Manager for Aircraft_Inspection__c and select Record Types.
Locate the specific record types (e.g., Routine Maintenance, Emergency Repair).
Picklist value availability is configured independently for each record type on the object.
3
Edit the Inspection_Grade__c picklist settings under each Record Type detail page.
Move the newly created picklist values from the Available list to the Selected list and save.
This grants access to the specific values for users creating or editing records assigned to that record type.

Key Concept

Record Type Picklist Value Assignment
Question 408Question

An administrator at Cloud Kicks is tasked with creating a summary field on the custom object Project__c to display the total monetary value of related child Project_Expense__c records. Currently, Project_Expense__c is connected to Project__c via a standard Lookup relationship. When attempting to create the new field on Project__c, the administrator notices that the Roll-Up Summary field type option is disabled. Which statement accurately explains why this option is unavailable and identifies the solution required to fulfill the business requirement?

Show answer & explanation

Answer: Roll-Up Summary fields are only supported on the parent object of a Master-Detail relationship; the administrator must convert the existing Lookup relationship on Project_Expense__c to a Master-Detail relationship.

Answer

Roll-Up Summary fields are only supported on the parent object of a Master-Detail relationship; the administrator must convert the existing Lookup relationship on Project_Expense__c to a Master-Detail relationship.
In Salesforce, standard declarative Roll-Up Summary fields are strictly supported on the Master side of a Master-Detail relationship. Because the two custom objects are currently connected via a Lookup relationship, the option to create a Roll-Up Summary field on the parent object is disabled. Converting the Lookup relationship on the child object to a Master-Detail relationship enables the creation of Roll-Up Summary fields on the parent object.

Step-by-Step Solution

1
Analyze the relationship requirement for Roll-Up Summary fields in Salesforce.
Salesforce declarative Roll-Up Summary fields can only be defined on the master object in a Master-Detail relationship.
Standard declarative roll-up summaries are not natively available over standard Lookup relationships.
2
Identify the relationship type between Project__c and Project_Expense__c in the scenario.
The objects are currently linked using a Lookup relationship.
Because the objects use a Lookup relationship, the Roll-Up Summary data type is disabled on Project__c.
3
Determine the configuration change required to enable Roll-Up Summary functionality.
Convert the Lookup field on Project_Expense__c to a Master-Detail field.
Converting the relationship field on the child object to Master-Detail (ensuring all existing child records have parent values populated) makes Roll-Up Summary fields available on Project__c.

Key Concept

Roll-Up Summary Field Relationship Requirements
Question 409Question

A Salesforce Administrator at Velocity Logistics has defined corporate IP addresses (192.0.2.0192.0.2.0 to 192.0.2.255192.0.2.255) under Organization-Wide Network Access. The Field Sales Profile has no IP ranges defined under its Profile Login IP Ranges section. A sales representative assigned to the Field Sales Profile attempts to log into Salesforce from home using an unrecognised IP address (203.0.113.45203.0.113.45) with valid username and password credentials. What will occur during this login attempt?

Show answer & explanation

Answer: The user is allowed to log in successfully after passing identity verification (such as entering a verification code).

Answer

The user is allowed to log in successfully after passing identity verification (such as entering a verification code).
When no Login IP Ranges are configured on a user's Profile, Organization-Wide Network Access settings dictate identity challenge requirements. Logging in from an IP address outside the trusted Network Access range prompts the user for identity verification (activation code), but does not block the login attempt.

Step-by-Step Solution

1
Evaluate Profile-Level Login IP Restrictions
No IP ranges are set on the Field Sales Profile.
If Profile Login IP Ranges are defined, any login attempt outside those ranges is restricted and hard-blocked immediately. Since none are defined, profile-level blocking does not apply.
2
Evaluate Organization-Wide Network Access Settings
The user's home IP address (203.0.113.45203.0.113.45) is outside the trusted Network Access IP range (192.0.2.0192.0.2.0 - 192.0.2.255192.0.2.255).
Network Access IP ranges define trusted IP locations where multi-factor/identity verification challenges can be bypassed.
3
Determine Login Challenge Behavior
Identity verification is activated.
Because the IP address is outside the org-wide trusted ranges (and no profile-level IP restriction blocks it), Salesforce requires the user to complete identity verification to successfully log in.

Key Concept

Difference between Profile Login IP Ranges (Hard Restriction) and Org Network Access (Identity Verification Bypass)
Question 410Question

A Salesforce Administrator at a cloud security enterprise needs to provision access for a newly hired internal audit team. The audit team members require standard platform permissions. However, corporate compliance mandates that these specific users must be strictly prohibited from logging into Salesforce when working outside the corporate network range (203.0.113.0/24203.0.113.0/24). Attempting to log in from an unauthorized IP address must result in immediate access denial rather than triggering an identity verification challenge. Which configuration should the administrator implement to meet these requirements?

Show answer & explanation

Answer: Configure the allowed login IP ranges directly on the profile assigned to the internal audit team members.

Answer

Configure the allowed login IP ranges directly on the profile assigned to the internal audit team members.
Configuring Login IP Ranges at the Profile level strictly enforces location-based login controls. If a user assigned to that profile attempts to authenticate from an IP address outside the configured range, Salesforce denies access immediately without issuing an identity verification challenge.

Step-by-Step Solution

1
Analyze the security requirement.
The requirement specifies blocking login access entirely when users are outside a designated IP range (203.0.113.0/24203.0.113.0/24), rather than prompting for multi-factor/identity verification.
Salesforce provides two distinct mechanisms for handling IP restrictions: Organization-Wide Network Access and Profile Login IP Ranges.
2
Evaluate Profile-level vs. Org-level IP settings.
Organization-wide Network Access defines trusted IP ranges where activation challenges are skipped, but allows logins from elsewhere after verification. Profile Login IP Ranges strictly restrict access, denying login completely if the user's IP is outside the specified range.
Profile-level IP restrictions directly satisfy the requirement to prohibit login attempts outside the corporate range.
3
Determine the proper administrative implementation.
Navigate to the custom profile assigned to the audit team and add the range 203.0.113.0203.0.113.0 to 203.0.113.255203.0.113.255 under the Login IP Ranges related list.
Login restrictions (IP ranges and Login Hours) are enforced on Profiles and cannot be applied via Permission Sets.

Key Concept

Profile Login IP Ranges vs. Network Access IP Ranges
Estimated Time:2m 0s
Question 411Question

An administrator at an international logistics company manages a custom object named Shipment_Audit__c used for compliance tracking. The object's standard Name field was initially configured as an Auto-Number with the format AUD-{0000}. Due to operational changes, stakeholders now require users to manually enter a descriptive text title for new records while ensuring existing auto-numbered records retain their assigned identifiers unchanged. Which action should the administrator take to meet this requirement?

Show answer & explanation

Answer: Change the Data Type of the standard Name field from Auto-Number to Text in Object Manager.

Answer

Change the Data Type of the standard Name field from Auto-Number to Text in Object Manager.
In Salesforce custom object management, changing the standard Name field's data type from Auto-Number to Text allows users to input arbitrary text strings for new records while existing records retain their previously generated auto-number values as static text.

Step-by-Step Solution

1
Analyze the requirement for custom object standard field management.
Identified that existing auto-generated record names must be preserved while allowing manual text input for future records.
Salesforce custom objects always contain a standard Name field which can be set to either Text or Auto-Number.
2
Evaluate the behavior of converting an Auto-Number field to a Text field in Object Manager.
Converting Auto-Number to Text keeps all previously existing numbers intact as text and permits manual text entry for new records.
This direct data type transition fulfills both historical preservation and future flexibility requirements without data loss.

Key Concept

Standard Name Field Modification on Custom Objects
Question 412Question

An administrator is configuring field calculations for custom objects that share a Master-Detail relationship. The business requires tracking aggregate statistics on the parent record. Which TWO functionality requirements can be fulfilled using standard Roll-Up Summary fields on the master object? (Select 2)

Select all that apply

Show answer & explanation

Answer: Calculate the total value of numeric fields across all related detail records using a SUM calculation.; Count the total number of related detail records associated with the master record using a COUNT calculation.

Answer

Roll-up summary fields on a master object in a Master-Detail relationship can compute aggregate SUM values of numeric child fields and COUNT the total number of related detail records.
Roll-up summary fields allow administrators to calculate aggregate values from detail records directly on a master record in a Master-Detail relationship. Supported functions include COUNT (total number of detail records) and SUM (summing values of a specified numeric, currency, or percent field).

Step-by-Step Solution

1
Evaluate relationship type requirements for roll-up summary fields.
Confirm that roll-up summary fields are available on the master object in a Master-Detail relationship.
Salesforce standard functionality permits native roll-up summary fields exclusively on master-detail relationships.
2
Identify supported aggregate operations.
Determine that SUM, COUNT, MIN, and MAX operations are natively supported.
SUM aggregates numeric values across child records, and COUNT computes the number of related child records.
3
Identify invalid capabilities and misconceptions.
Reject lookup relationship aggregation and independent master deletion options.
Lookup relationships do not support native roll-up summary fields, and master record deletion cascades to detail records.

Key Concept

Roll-Up Summary Field Capabilities and Limitations in Master-Detail Relationships
Question 413Question

An administrator at a global logistics company must grant Read access to a custom currency field, Contract_Margin__c, on the Contract object to a specific group of three financial auditors. Currently, Field-Level Security (FLS) restricts access to this field across all profiles. The auditors share the standard Financial Analyst profile with fifteen other users who must not be able to view or export this sensitive margin data. Which configuration should the administrator implement to grant the necessary field access while adhering to security best practices?

Show answer & explanation

Answer: Create a Permission Set that grants Read access to Contract_Margin__c, and assign the Permission Set to the three financial auditors.

Answer

Create a Permission Set that grants Read access to Contract_Margin__c, and assign the Permission Set to the three financial auditors.
The correct approach is to keep the standard profile settings restricted and create a Permission Set granting Read access to Contract_Margin__c for the three auditors. Permission Sets are the recommended solution in Salesforce for granting additive permissions to specific users without introducing unnecessary profile overhead.

Step-by-Step Solution

1
Analyze the baseline access requirements
Identified that the Financial Analyst profile currently hides Contract_Margin__c from all eighteen members, but three specific members require Read access.
Profiles set baseline permissions for groups of users, but selective additive access must be handled cleanly without impacting the entire group.
2
Evaluate access expansion mechanism options
Selected Permission Sets as the optimal architecture for additive field-level security (FLS).
Permission Sets grant additional access to individual users without altering profile baselines or introducing security risks via UI-only restrictions.
3
Verify security boundary enforcement
Assigning the Permission Set to only the three auditors ensures FLS is strictly enforced at the data layer across UI, Reports, and API.
FLS configured via Permission Sets restricts both UI access and API/reporting access for non-assigned users.

Key Concept

Field-Level Security (FLS) and Permission Sets vs. Profiles
Question 414Question

A Salesforce administrator at an enterprise logistics firm creates a new custom Picklist field named Vendor_Rating__c on the Shipment__c custom object. The Shipment__c object uses three Record Types: Air, Sea, and Ground. Although the administrator added Vendor_Rating__c to all page layouts, users report that when creating a Ground shipment record, the Vendor_Rating__c field appears on the page but displays no available options in the drop-down menu.

Which administrative action will resolve this issue?

Show answer & explanation

Answer: Edit the Ground record type configuration in Object Manager and assign the required picklist values to the Vendor_Rating__c field.

Answer

Edit the Ground record type configuration in Object Manager and assign the required picklist values to the Vendor_Rating__c field.
When Record Types exist on an object, creating a custom picklist field requires an additional step: configuring which picklist values are active for each record type. Adding the field to page layouts makes the field visible, but editing the Record Type configuration in Object Manager and selecting the active picklist values is necessary to display options in the drop-down menu.

Step-by-Step Solution

1
Identify the cause of empty picklist values on a specific Record Type.
Recognize that creating a custom Picklist field does not automatically assign available values to pre-existing Record Types on the object.
Salesforce requires administrators to specify which picklist values are active for each distinct Record Type.
2
Navigate to Object Manager > Shipment__c > Record Types > Ground.
Locate the picklists available for editing under the Ground record type.
Record Type administration determines field-level picklist value availability per record type.
3
Edit the Vendor_Rating__c picklist field under the Ground record type and move the desired values to Selected Values.
The picklist options become visible and selectable when creating or editing Ground shipments.
Explicit assignment makes the picklist values active for users interacting with that specific record type.

Key Concept

Record Type Picklist Assignment for Custom Fields
Estimated Time:2m 0s
Question 415Question

An administrator is configuring object relationships between custom objects in Salesforce. Which two capabilities or behaviors are specific to Master-Detail relationships compared to Lookup relationships? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Deleting a master record automatically deletes all associated detail records.; Roll-up summary fields can be created on the master object to aggregate values from child records.

Answer

In Salesforce, Master-Detail relationships enforce cascading deletion of detail records when the master record is deleted and allow roll-up summary fields to be created on the master object to aggregate detail record values.
Master-Detail relationships feature cascading deletion of detail records upon master deletion and support roll-up summary fields on the master object to calculate aggregate data from child records.

Step-by-Step Solution

1
Analyze relationship deletion behavior
Identify that Master-Detail relationships perform cascading deletes on detail records when the master is deleted.
Detail record ownership and lifecycle are tightly coupled to the master record.
2
Evaluate roll-up summary field capabilities
Determine that roll-up summary fields are exclusively available on the master object in Master-Detail relationships.
Lookup relationships do not natively support roll-up summary fields.

Key Concept

Master-Detail Relationship Capabilities and Lifecycle Behaviors
Estimated Time:1m 0s
Question 416Question

A healthcare organization tracks sensitive patient interactions using a custom object named Patient_Feedback__c. The Organization-Wide Default (OWD) sharing setting for Patient_Feedback__c is set to Private, and the administrator has deselected the 'Grant Access Using Hierarchies' checkbox to prevent automatic upward access propagation. The compliance team now requires that users assigned to the 'Quality Assurance Director' role receive Read access to all Patient_Feedback__c records owned by users in the 'Intake Specialist' role, while ensuring that users in the intermediate 'Intake Manager' role (who sit directly above Intake Specialists in the role hierarchy) do not gain access to these records. Which statement correctly describes the outcome when the administrator configures an owner-based sharing rule from the Intake Specialist role to the Quality Assurance Director role?

Show answer & explanation

Answer: The sharing rule grants Read access exclusively to users in the Quality Assurance Director role, and Intake Managers remain unable to view the records.

Answer

The sharing rule grants Read access exclusively to users in the Quality Assurance Director role, while users in the Intake Manager role remain unable to view the records.
For custom objects, administrators can deselect 'Grant Access Using Hierarchies' to prevent managers from automatically inheriting access to records owned by subordinates. Creating an owner-based sharing rule targeted specifically to the Quality Assurance Director role grants access exclusively to users within that role, leaving intermediate manager roles without access.

Step-by-Step Solution

1
Analyze Organization-Wide Defaults and Hierarchy Settings
Patient_Feedback__c is Private with 'Grant Access Using Hierarchies' deselected. This means only record owners (Intake Specialists) and users granted explicit access can view records; higher roles like Intake Managers do not inherit access automatically.
For custom objects, disabling hierarchy access prevents managers from gaining implicit access to records owned by subordinates.
2
Evaluate the Owner-Based Sharing Rule Target
Configuring an owner-based sharing rule sharing records owned by 'Role: Intake Specialist' with 'Role: Quality Assurance Director' opens access specifically to members of the Quality Assurance Director role.
Sharing rules expand record access beyond OWD to specific roles, public groups, or territories.
3
Determine Access Propagation behavior
Because 'Grant Access Using Hierarchies' is disabled, access granted to Quality Assurance Directors does not propagate to intermediate roles like Intake Manager.
Disabling hierarchy access ensures sharing rules only grant access to the explicitly targeted role or group.

Key Concept

Interaction between Grant Access Using Hierarchies and Sharing Rules on Custom Objects
Estimated Time:2m 0s
Question 417Question

An administrator at a renewable energy firm is creating a custom object named Installation Project to track client installations. Which two statements correctly describe platform characteristics or administrative capabilities of custom objects compared to standard objects? (Select 2)

Select all that apply

Show answer & explanation

Answer: Custom objects can be deleted from the organization by an administrator if dependencies are cleared, whereas standard objects cannot be deleted.; Custom objects automatically append the '__c' suffix to their API name upon creation, whereas standard objects do not include a custom suffix.

Answer

Custom objects can be deleted by an administrator if dependency requirements are met while standard objects cannot be deleted, and custom object API names automatically append the '__c' suffix.
Custom objects differ from standard objects in lifecycle management and API naming conventions. Administrators have permission to delete custom objects if all references (such as Apex code or fields) are removed, whereas standard objects cannot be deleted. In addition, Salesforce automatically appends the '__c' suffix to custom object API names upon creation to designate custom schema elements.

Step-by-Step Solution

1
Evaluate lifecycle capabilities for custom vs standard objects
Custom objects can be deleted from Object Manager, but standard objects cannot be deleted.
Salesforce allows administrators to remove custom schema components, whereas built-in standard objects are core platform components.
2
Evaluate API naming conventions
Custom objects append '__c' to their API names, while standard objects do not.
The platform uses suffix conventions to isolate custom metadata from standard objects.

Key Concept

Standard and Custom Object Management
Question 418Question

A Salesforce Administrator needs to manually provision a new employee in Salesforce Core. What is the correct order of administrative steps to complete this standard user creation and provisioning workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence starts with navigating to Setup > Users and clicking New User, followed by entering mandatory user identity details, selecting the baseline User License and Profile on the creation page, and finally saving the record to assign additional Permission Sets.
The correct provisioning workflow begins by accessing the Users interface in Setup to open the New User form. Next, mandatory user identification details (such as Name, Email, and unique Username) are entered alongside selecting the required baseline User License and Profile. Finally, after saving the user record, administrators assign any additional Permission Sets to grant fine-grained permissions.

Step-by-Step Solution

1
Initiate user creation in Setup.
The New User form opens in Salesforce.
You must navigate to the Users management area to create a new user record.
2
Enter core identification details.
The user record has mandatory fields populated.
Salesforce requires identity information such as Username, Email, and Alias for every user.
3
Assign the baseline User License and Profile.
Core object security and license entitlement are configured.
Every user requires exactly one User License and one Profile during initial creation.
4
Save the user record and assign Permission Sets.
The user account is active and provisioned with supplemental permissions.
Permission sets can only be assigned to existing, saved user records to grant extra privileges.

Key Concept

Standard User Provisioning Sequence
Question 419Question

An administrator is designing a scalable security architecture using Salesforce permission management tools. Match each Salesforce permission component on the left with its corresponding functional capability on the right.

Click a left item, then click its matching right item

Items

Permission Set Group
Muting Permission Set
Permission Set Assignment Expiration
Single Permission Set

Matches

Show answer & explanation

Answer

Permission Set Group matches bundling multiple permission sets into a single unit; Muting Permission Set matches selectively masking specific permissions within a group; Permission Set Assignment Expiration matches automatically revoking access after a designated duration; Single Permission Set matches granting supplemental permissions without altering baseline profile settings.
Permission Set Groups bundle multiple permission sets into a single entity. Muting Permission Sets work within Permission Set Groups to explicitly remove permissions included in bundled sets. Permission Set Assignment Expiration enforces time-based access removal automatically. Single Permission Sets provide modular, additive access above baseline profile permissions.

Step-by-Step Solution

1
Analyze the container feature for consolidating permissions.
Identify that Permission Set Groups aggregate multiple permission sets into a single assignable package.
Group consolidation streamlines user administrative assignments across functional job roles.
2
Determine how to restrict a specific permission within a consolidated permission group.
Identify Muting Permission Sets as the component designed to suppress specific permissions in a Permission Set Group.
Muting allows fine-grained exception management without modifying underlying component permission sets.
3
Evaluate time-bound security access management.
Match Permission Set Assignment Expiration with setting duration bounds that automatically revoke access.
Assigning expiration dates ensures temporary elevated access expires automatically without manual intervention.
4
Examine standard additive permission assignment.
Match Single Permission Set with granting extra permissions to specific users on top of their profile.
Profiles establish baseline access while standalone permission sets add granular, modular capabilities.

Key Concept

Salesforce Permission Sets, Permission Set Groups, and Muting Permission Set Capabilities
Question 420Question

An administrator is attempting to create a Roll-Up Summary field on a parent custom object to calculate the sum of related child record amounts. However, during field creation, the administrator observes that the Roll-Up Summary field type option is greyed out and unavailable. What is the reason the Roll-Up Summary field type is disabled?

Show answer & explanation

Answer: The parent object and child object are connected using a Lookup relationship rather than a Master-Detail relationship.

Answer

The Roll-Up Summary field type is disabled because the parent and child objects are linked via a Lookup relationship instead of a Master-Detail relationship.
In Salesforce, Roll-Up Summary fields can only be created on the master object of a Master-Detail relationship. When objects are linked via a standard Lookup relationship, the Roll-Up Summary field type option remains disabled.

Step-by-Step Solution

1
Identify the relationship requirements for Roll-Up Summary fields in Salesforce.
Native Roll-Up Summary fields are only allowed on the master object in a Master-Detail relationship (or select standard object relationships like Account-Opportunity).
Lookup relationships do not enforce strict parent-child data dependency required for automatic database-level roll-ups.
2
Determine why the field type selection is unavailable during setup.
The relationship definition between the target objects is currently a Lookup relationship, causing Salesforce to disable the Roll-Up Summary field type.
Converting the Lookup relationship to a Master-Detail relationship (assuming all existing child records have parent values) enables the creation of Roll-Up Summary fields.

Key Concept

Roll-Up Summary Relationship Requirement
PreviousPage 21 / 90Next
All practice questions — Salesforce Certified Administrator | Examkin