All practice questions

1784 questions

Question 341Question

A global firm tracks strategic mergers and acquisitions using a custom object named Joint_Venture__c. Executive leadership mandates that baseline access must be restricted so that users can only view and edit Joint_Venture__c records they personally own. Additionally, because executive team roles overlap in the role hierarchy, record access must NOT automatically propagate to managers higher up in the role hierarchy. Which TWO configurations must the System Administrator implement on the Joint_Venture__c object to satisfy these business security requirements?

Select all that apply

Show answer & explanation

Answer: Set the Default Internal Access for Joint_Venture__c to Private.; Deselect the Grant Access Using Hierarchies checkbox on the Joint_Venture__c sharing settings.

Answer

The System Administrator must set the Organization-Wide Default (OWD) internal access for Joint_Venture__c to Private and deselect the Grant Access Using Hierarchies checkbox in Sharing Settings.
To satisfy the requirement that users can only access Joint_Venture__c records they own, the baseline Organization-Wide Default (OWD) must be set to Private. Furthermore, because Salesforce automatically grants record access to users above the owner in the role hierarchy by default, the administrator must deselect Grant Access Using Hierarchies on the custom object's sharing settings to prevent management access.

Step-by-Step Solution

1
Determine the required Organization-Wide Default (OWD) setting for baseline record access.
Setting Default Internal Access to Private ensures that non-owner users have no access to Joint_Venture__c records by default.
Salesforce security architecture relies on OWD to set the most restrictive baseline level of record access for an organization.
2
Evaluate role hierarchy propagation for the custom object.
Unchecking Grant Access Using Hierarchies disables automatic access rollout to managers above record owners in the role hierarchy.
By default, custom objects inherit hierarchy access. Disabling this checkbox specifically prevents superior roles from inheriting owner access on custom objects.
3
Verify that object-level security settings (Profiles/Permission Sets) are not being misapplied for record-level restrictions.
Confirm that record access control is handled via OWD rather than Profile settings.
Profiles grant permissions (Create, Read, Edit, Delete) but cannot restrict individual record visibility governed by OWD.

Key Concept

Organization-Wide Defaults (OWD) set the baseline record-level access in Salesforce. For custom objects, baseline access can be set to Private, and automatic role hierarchy access rollout can be disabled by unchecking Grant Access Using Hierarchies.
Question 342Question

A Salesforce administrator at a subscription management company needs to update custom field settings on the custom object Subscription_Contract__c to align with updated accounting requirements. The administrator plans to convert an existing Text field used for storing promotional codes into a Percent field, and convert an Auto-Number contract identifier field into a Text field.

Which two statements accurately describe the consequences and considerations of these custom field data type conversions?

Select all that apply

Show answer & explanation

Answer: Converting an Auto-Number field to a Text field preserves existing values in current records, but disables automatic sequential numbering for newly created records.; Converting a Text field to a Percent field results in data loss for any records containing non-numeric characters or text strings.

Answer

Converting an Auto-Number field to a Text field preserves existing data while stopping auto-numbering on future records, and converting a Text field to a Percent field leads to data loss on records containing non-numeric values.
Converting an Auto-Number field to a Text field retains all existing values on current records, but turns off automated sequential number generation for new records. Converting a Text field to a Percent field converts numeric values successfully, but causes data loss on any record containing non-numeric text characters.

Step-by-Step Solution

1
Analyze the impact of converting an Auto-Number field to a Text field.
Recognize that existing text values are retained on historic records, but future record creations will no longer generate automatic sequential numbers.
Salesforce allows Auto-Number to Text conversion while retaining data, but the auto-numbering logic is disabled.
2
Analyze the impact of converting a Text field to a Percent field.
Identify that non-numeric text strings cannot be converted into numbers, leading to data loss on affected records.
Data type conversions from broad types (Text) to restrictive numeric types (Percent/Number/Currency) lose non-convertible data.
3
Evaluate relationship and picklist field limitations presented in distractor options.
Confirm that cascading deletes and roll-up summaries depend on Master-Detail relationships, and picklists require explicit Record Type assignment.
Eliminates incorrect statements regarding Lookup relationship capabilities and Record Type picklist management.

Key Concept

Salesforce Custom Field Data Type Conversion Rules and Data Loss Considerations
Estimated Time:2m 0s
Question 343Question

An administrator at a telecommunications provider is modifying custom fields on the custom object Equipment_Order__c to support a operational system migration. The administrator needs to convert an existing Picklist field named Priority_Level__c into a Multi-Select Picklist, and convert an existing custom Text field named Device_Tracking_ID__c into an Auto-Number field. Which TWO considerations or system behaviors should the administrator expect during these custom field conversions? (Select 2)

Select all that apply

Show answer & explanation

Answer: Converting a Picklist field to a Multi-Select Picklist field preserves existing values on records, but can break existing validation rules or formula fields that reference the original field.; Converting a custom Text field to an Auto-Number field leaves existing text values on historical records unchanged, while applying the auto-number formatting sequence to newly created records.

Answer

Converting a Picklist field to a Multi-Select Picklist preserves existing values on records, but can break existing validation rules or formula fields that reference the original field, AND converting a custom Text field to an Auto-Number field leaves existing text values on historical records unchanged, while applying the auto-number formatting sequence to newly created records.
Converting a Picklist field to a Multi-Select Picklist preserves data on existing records, but formulas or validation rules referencing the original field will fail if they use single-select functions like ISPICKVAL instead of multi-select functions like INCLUDES. Furthermore, converting a Text field to an Auto-Number field retains existing text values on historical records while applying the sequential auto-number format exclusively to newly created records.

Step-by-Step Solution

1
Analyze the impact of converting a single-select Picklist field to a Multi-Select Picklist field.
Existing record values are preserved, but functions such as ISPICKVAL in formulas and validation rules will fail or produce syntax errors because multi-select picklists require the INCLUDES function.
Salesforce handles data preservation for picklist conversions, but formula syntax rules differ between single-select and multi-select picklist data types.
2
Analyze the impact of converting a custom Text field to an Auto-Number field.
Historical text values remain unaffected on pre-existing records, while new records generated post-conversion automatically populate using the newly defined auto-number sequence format.
Salesforce preserves historical text data when converting to Auto-Number to prevent data loss.
3
Evaluate and eliminate distractors related to relationship limitations, lead mapping, and picklist record type configurations.
Confirmed that converting lookup to master-detail requires non-null parent values, lead field mapping requires explicit target setup, and picklist record type availability must be verified.
Identified standard Salesforce administrative limitations across object management and field conversions.

Key Concept

Custom Field Data Type Conversion Rules and Considerations
Question 344Question

Match each Salesforce Delegated Administration feature with its corresponding operational scope and administrative capability.

Click a left item, then click its matching right item

Items

Delegated User Management
Delegated Profile Assignment
Delegated Custom Object Administration
Delegated Administrator Login Access

Matches

Show answer & explanation

Answer

Delegated User Management matches creating/editing users and resetting passwords within specified roles. Delegated Profile Assignment matches assigning only designated profiles added to the delegated group. Delegated Custom Object Administration matches managing fields, layouts, and record types on specified custom objects. Delegated Administrator Login Access matches logging in as users in managed roles who granted access.
Each feature of Delegated Administration maps directly to its predefined security boundary in Salesforce Setup. Delegated user management controls users in specific role hierarchies; profile assignment is bounded by assigned profile lists; custom object delegation allows schema changes for designated custom objects; and login privileges require user consent within delegated role structures.

Step-by-Step Solution

1
Analyze user management scope for delegated administration.
User maintenance capabilities are scoped to users in defined roles and subordinate roles in the role hierarchy.
Salesforce scopes user administration delegation using specified role trees to enforce least privilege.
2
Determine profile assignment limits for delegated administrators.
Profile permissions are strictly restricted to profiles explicitly assigned to the delegated group.
This prevents delegated admins from elevating user privileges beyond approved organizational roles.
3
Examine object administration privileges.
Custom object administration permits field, page layout, and record type management for specified custom objects.
Delegated object administration is strictly limited to specified custom objects and cannot modify standard objects.
4
Evaluate login access requirements.
Logging in as another user requires the target user to reside in a delegated role and explicitly grant login access.
Login permissions require both role delegation boundaries and user authorization.

Key Concept

Delegated Administration Boundaries and Capabilities
Estimated Time:1m 0s
Question 345Question

A Salesforce administrator at OmniTech Solutions needs to enforce strict access controls for compliance officers assigned to the Custom Compliance Auditor profile. The compliance officers must be allowed to access Salesforce only between 8:00 AM and 6:00 PM, Monday through Friday. Additionally, if these users attempt to log in from an IP address outside the corporate network, access must be completely denied rather than prompting for multi-factor identity verification. Which two configuration steps should the administrator execute on the Custom Compliance Auditor profile to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Define Login Hours on the profile to permit access between 8:00 AM and 6:00 PM, Monday through Friday.; Add the corporate network IP addresses to the Login IP Ranges section of the profile.

Answer

The administrator must define Login Hours on the profile to permit access between 8:00 AM and 6:00 PM Monday through Friday, and add the corporate network IP addresses to the Login IP Ranges section of the profile.
To satisfy both requirements, security settings must be enforced at the profile level. Defining Login Hours restricts authentication to Monday through Friday from 8:00 AM to 6:00 PM. Specifying Login IP Ranges on the profile ensures that any login attempt outside the defined corporate IP range is completely rejected, rather than prompting the user for identity verification.

Step-by-Step Solution

1
Evaluate time restriction requirements
Login Hours on the user profile control the exact days and time windows during which users can authenticate.
Profile-level Login Hours enforce a strict time window and deny authentication outside the defined schedule.
2
Evaluate IP address restriction requirements
Login IP Ranges defined on a profile hard-block any login attempt coming from outside the defined IP range.
Profile IP ranges act as a hard restriction (denying login), whereas organization-wide Network Access trusted IPs merely bypass identity verification prompts.

Key Concept

Profile-Level Security: Login Hours and Login IP Ranges
Question 346Question

A Salesforce Administrator at an enterprise organization is tasked with provisioning access for a newly hired Senior Financial Auditor who requires targeted access to confidential audit objects and executive reporting queues. Following security governance and Salesforce administrative best practices, in what order should the administrator execute the user provisioning workflow?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct operational sequence begins with verifying license availability, defining the required base profile, creating the user record with mandatory fields, assigning supplemental permission set groups, and finally adding the active user to the public group for record sharing.
The correct order respects mandatory dependencies in Salesforce user administration: checking license availability precedes account generation; profile creation must occur prior to selection on the user form; user record creation instantiates the account; permission set groups provide targeted privilege expansion; and public group addition enables row-level sharing.

Step-by-Step Solution

1
Check Organization License Capacity
Confirmed an available Salesforce User License in Company Information.
User creation requires an unassigned active license of the targeted type.
2
Establish Base Profile Settings
Created or verified the minimal-privilege profile.
Profile selection is a required field on the User object during record save.
3
Instantiate the User Record
Saved the new user record with standard license and profile attributes.
A valid user ID is necessary prior to associating permission sets or public group memberships.
4
Assign Permission Set Group
Granted specialized financial audit permissions to the user.
Permission Set Groups build upon baseline profile permissions and must target instantiated users.
5
Add to Public Group
Included the user in the sharing hierarchy for audit records.
Public group assignment applies sharing rules to the active user account.

Key Concept

Salesforce User Provisioning Lifecycle and Access Layering
Question 347Question

A Salesforce administrator is designing a scalable permission architecture to meet strict security and administrative guidelines across multiple departments. Match each business requirement with the most appropriate permission structure or mechanism.

Click a left item, then click its matching right item

Items

Granting an external auditor temporary 'Modify All' access on the Account object for a specified 30-day compliance window without altering baseline profile settings.
Bundling multiple functional access packages for executive users while explicitly turning off the 'Export Reports' permission granted by one of the aggregated packages.
Restricting elevated system permissions so they are active only when a user explicitly authenticates via multi-factor authentication during an active browser session.
Providing specialized Read and Edit access to custom financial fields across users who belong to four different standard baseline profiles.

Matches

Show answer & explanation

Answer

Each business requirement maps to its optimal Salesforce permission mechanism: Temporary compliance audit access pairs with Permission Set Assignment with an Expiration Date; aggregated access with muted report export capabilities pairs with Permission Set Group containing a Muting Permission Set; conditional session-dependent access pairs with Session-Based Permission Set; and cross-profile custom field access pairs with Standalone Additive Permission Set.
The correct pairings align business scenarios with Salesforce administrative capabilities: temporary access utilizes expiration dates on assignments; permission aggregation with selective permission removal utilizes Permission Set Groups with Muting Permission Sets; session-dependent access uses Session-Based Permission Sets; and cross-profile field additions utilize standard additive Permission Sets.

Step-by-Step Solution

1
Analyze time-bound elevated access requirement
Identified requirement for temporary 30-day access
Salesforce permits setting expiration dates directly on User Permission Set Assignments to automatically revoke temporary elevated privileges.
2
Evaluate consolidated access with explicit permission restrictions
Identified permission set consolidation with a negative override (muting)
Permission Set Groups allow bundling multiple permission sets, while Muting Permission Sets provide the ability to remove specific permissions within the group context.
3
Analyze authentication-driven session requirements
Identified requirement for session-scoped permissions
Session-Based Permission Sets enforce that permissions are dynamically granted only during active user sessions meeting specific criteria.
4
Analyze cross-profile additive field access
Identified standard additive permission set usage
Profiles should serve as baseline access, while standalone permission sets grant flexible additive permissions across disparate user profiles.

Key Concept

Permission Architecture & Advanced Grouping Capabilities
Estimated Time:2m 0s
Question 348Question

Global Logistics Inc. maintains a custom object called 'Shipment__c' with its Organization-Wide Default (OWD) sharing setting configured as Private. The administrator needs to automatically grant Read-Only access for all records owned by users in the 'Warehouse Staff' role to users in the 'Regional Support' role. Which Salesforce security feature should the administrator configure to satisfy this requirement?

Show answer & explanation

Answer: An owner-based sharing rule targeting records owned by the 'Warehouse Staff' role

Answer

An owner-based sharing rule targeting records owned by the 'Warehouse Staff' role.
When Organization-Wide Defaults are set to Private, owner-based sharing rules are used to open up Read-Only or Read/Write access for records owned by a specific set of users (defined by role, territory, or public group) to another specified set of users.

Step-by-Step Solution

1
Identify the base record access level
Organization-Wide Default (OWD) is Private, meaning users only see records they own by default.
OWD establishes the baseline record-level access for all users in Salesforce.
2
Evaluate record sharing requirements
Need to share records owned by a specific group ('Warehouse Staff' role) with another specific group ('Regional Support' role).
Access needs to be extended beyond the owner based on ownership role membership.
3
Select the appropriate record-level sharing tool
Configure an owner-based sharing rule specifying the source role, target role, and access level (Read-Only).
Owner-based sharing rules extend record-level visibility to specified roles or public groups for private records.

Key Concept

Owner-based Sharing Rules
Question 349Question

The finance team at Helios Solar Systems requests to transition Salesforce from a Standard Fiscal Year to a 4-4-5 Custom Fiscal Year structure to match their corporate financial accounting cycles. Which two key implications must the Salesforce Administrator highlight to executive leadership before enabling this feature? (Choose 2 answers)

Select all that apply

Show answer & explanation

Answer: Enabling a custom fiscal year is an irreversible process and cannot be disabled once saved.; Existing opportunity quotas, forecasting, and reporting period definitions will be impacted and must be aligned with the custom periods.

Answer

The administrator must explain that enabling a custom fiscal year is an irreversible action that cannot be disabled once saved, and that defining custom fiscal periods directly impacts forecasting, reports, and opportunity quotas.
Enabling a Custom Fiscal Year is a permanent, irreversible setting in Salesforce. Additionally, because standard reporting and forecasting rely on predefined calendar periods, switching to custom fiscal years impacts existing forecasting structures, quotas, and period-based reporting filters.

Step-by-Step Solution

1
Evaluate the architectural permanency of custom fiscal year settings.
Identify that enabling custom fiscal years permanently replaces standard calendar fiscal year behavior in Salesforce.
Salesforce Setup documentation specifies that enabling custom fiscal years is an irreversible action.
2
Assess impact on standard business forecasting and analytics.
Recognize that opportunity quotas, forecasts, and standard reporting period filters adapt to custom fiscal period definitions.
Standard calendar-based forecasting calculations are replaced when custom fiscal periods are defined.

Key Concept

Irreversibility and operational impact of Custom Fiscal Years in Salesforce
Question 350Question

A Salesforce Administrator at a global logistics firm is tasked with onboarding a new Regional Dispatch Manager. The new user requires a standard user license, data visibility constrained by their geographic territory, specialized permission to manage custom Fleet records, and automated assignment to the Regional Incident Queue.

What is the correct sequential order of administrative steps required to provision this user while adhering to Salesforce security best practices?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order to provision the user is: 1) Create the User record with mandatory fields and baseline Profile, 2) Assign the user's Role in the Role Hierarchy, 3) Assign the specialized Permission Set Group, and 4) Add the User to the Regional Incident Queue and Public Groups.
The correct order follows Salesforce's logical dependency and security best practices: first creating the User record with required fields and a standard profile, then establishing baseline visibility via the Role Hierarchy, layering job-specific functional access using a Permission Set Group, and finally adding the user to queues and public groups for operational record routing.

Step-by-Step Solution

1
Create the initial User record in Salesforce Setup.
The User record exists with necessary system fields (Username, Email, Alias, Encoding, Profile, User License).
All subsequent security and operational associations (Roles, Permission Sets, Queues) depend on a valid, saved User record ID.
2
Set the user's Role in the Role Hierarchy.
The user inherits baseline data visibility based on Organization-Wide Defaults (OWD) and role hierarchy mechanisms.
Establishing record-level access context via the Role Hierarchy is essential before granting additional functional capabilities.
3
Assign the Permission Set Group for Fleet management.
The user is granted targeted object/field permissions and functional rights beyond their baseline profile.
Salesforce security best practices dictate using minimal base profiles and extending access via Permission Sets or Permission Set Groups.
4
Add the user to the Regional Incident Queue and Public Groups.
The user can receive assigned records and participate in queue-based workflows.
Queue membership requires an existing, fully provisioned user with appropriate object permissions to process queue records.

Key Concept

User Provisioning Workflow and Least Privilege Architecture
Estimated Time:2m 0s
Question 351Question

A Salesforce Administrator is auditing the organization's security baseline and profile-specific security requirements. Match each security requirement on the left to the correct administrative location or configuration setting in Salesforce Setup on the right.

Click a left item, then click its matching right item

Items

Enforce custom password complexity requirements specifically for users assigned to the Customer Support Specialist profile.
Ensure user session tokens become invalid immediately upon reaching a 15-minute inactivity threshold across the entire organization.
Prevent session hijacking org-wide by binding active user sessions strictly to the original client IP address.
Configure the global baseline duration for user account unlock following five consecutive failed login attempts.

Matches

Show answer & explanation

Answer

The correct pairings align each security requirement with its accurate Salesforce administrative control: profile-specific password rules are managed via Profile-level Password Policies; global session token invalidation upon timeout and IP binding are managed under Organization-Wide Session Settings; global account lockout rules are set under Organization-Wide Password Policies.
Each requirement maps to its specific administrative interface in Salesforce Setup: Profile-level Password Policies allow granular overrides for specific user profiles; Organization-Wide Session Settings manage session timeouts, force logout behavior, and origin IP session locking globally; Organization-Wide Password Policies define default lockout periods and login failure thresholds for the organization baseline.

Step-by-Step Solution

1
Analyze profile-specific vs org-wide password controls.
Identify that customized password complexity for a specific profile (Customer Support Specialist) requires Profile-level Password Policies.
Organization-wide password policies set the default baseline, but profile-level password policies allow targeted overrides.
2
Evaluate session management controls.
Identify that session timeout duration, forcing logout upon timeout, and locking sessions to origin IP addresses are configured under Session Settings in Setup.
Session security settings apply organization-wide to govern active web sessions and session token lifecycle.
3
Differentiate default lockout duration setup.
Map global lockout duration to Organization-Wide Password Policies.
Lockout policies (such as lockout duration after failed login attempts) are maintained in Password Policies in Setup.

Key Concept

Distinction between Organization-Wide Session Settings, Org-Wide Password Policies, and Profile-Level Password Policy Overrides.
Question 352Question

An administrator at a global logistics organization is configuring a custom data model for tracking machinery assets and maintenance logs. The business requires that deleting an asset record automatically deletes all associated maintenance logs, that security access and record ownership of maintenance logs are derived strictly from the parent asset record, and that users can reassign a maintenance log record to a different asset record if it was originally linked incorrectly. Which two configuration steps must the administrator take to fulfill these business requirements? (Select 2)

Select all that apply

Show answer & explanation

Answer: Create a Master-Detail relationship field on the child Maintenance Log object referencing the Asset object.; Check the 'Allow reparenting' option on the Master-Detail relationship field definition.

Answer

The administrator must create a Master-Detail relationship field on the Maintenance Log object pointing to the Asset object and check the 'Allow reparenting' checkbox on the field configuration.
Creating a Master-Detail relationship on the child object enforces automatic deletion of child logs when the parent asset is deleted and dictates that access to child logs is governed by access to the parent asset. Enabling the 'Allow reparenting' option on the field definition overrides the default restriction that prevents detail records from being reassigned to a different master record.

Step-by-Step Solution

1
Evaluate object relationship requirements for cascading deletion and access inheritance.
Determined that a Master-Detail relationship is required because Lookup relationships do not natively cascade deletes or control security/ownership on custom objects.
Master-Detail relationships automatically delete child records upon master deletion and inherit record access and ownership from the master object.
2
Evaluate record reassignment (reparenting) requirements.
Determined that 'Allow reparenting' must be explicitly enabled on the Master-Detail relationship field.
Child records in a Master-Detail relationship are locked to their initial master record by default unless reparenting is enabled.

Key Concept

Master-Detail Relationship Behaviors and Reparenting Configuration
Question 353Question

A company uses a custom object named `Project_Audit__c` with Organization-Wide Defaults (OWD) set to Private. To prevent executive roles from automatically inheriting record access, the System Administrator deselects the Grant Access Using Hierarchies checkbox on the `Project_Audit__c` object definition.

The administrator must configure record access to fulfill two specific business requirements:
1. Users assigned to the Audit Lead role must be able to view and edit all `Project_Audit__c` records owned by users in the Audit Analyst role.
2. Users in the Compliance Team public group must receive Read-Only access to any `Project_Audit__c` record where the `Risk_Level__c` picklist field is set to 'High'.

Which TWO configuration steps should the administrator perform to meet these requirements? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Create an owner-based sharing rule on Project_Audit__c that shares records owned by members of the Audit Analyst role with the Audit Lead role, granting Read/Write access.; Create a criteria-based sharing rule on Project_Audit__c where Risk_Level__c equals 'High', sharing records with the Compliance Team public group with Read-Only access.

Answer

The administrator must create an owner-based sharing rule to share records owned by the Audit Analyst role with the Audit Lead role with Read/Write access, and create a criteria-based sharing rule to share records matching Risk_Level__c = 'High' with the Compliance Team public group with Read-Only access.
When 'Grant Access Using Hierarchies' is unchecked for a custom object, higher-level roles no longer inherit record access automatically. To restore access for managers over subordinate records without re-enabling global hierarchy access, an owner-based sharing rule must be configured between the respective roles. Additionally, granting access based on a field attribute (such as Risk_Level__c = 'High') requires a criteria-based sharing rule targeted to the specified public group.

Step-by-Step Solution

1
Analyze the impact of disabling Grant Access Using Hierarchies on custom objects.
Disabling 'Grant Access Using Hierarchies' on a custom object prevents users higher in the role hierarchy from automatically inheriting record access to records owned by or shared with their subordinates.
When standard hierarchy access is disabled, explicit sharing mechanisms must be defined for manager roles to gain access to subordinate records.
2
Address Requirement 1 (Audit Leads accessing Audit Analyst records).
Create an Owner-Based Sharing Rule on `Project_Audit__c`. Set the owned-by group to 'Role: Audit Analyst' and share with 'Role: Audit Lead' with Read/Write access.
Owner-based sharing rules can explicitly target source roles and share access with target roles when hierarchy inheritance is turned off.
3
Address Requirement 2 (Compliance Team accessing High Risk records).
Create a Criteria-Based Sharing Rule on `Project_Audit__c`. Set criteria to `Risk_Level__c EQUALS High` and share with 'Public Group: Compliance Team' with Read-Only access.
Criteria-based sharing rules evaluate record field values and share matching records with designated user groups regardless of who owns the records.

Key Concept

Role Hierarchy Custom Object Access Toggles and Sharing Rule Selection
Question 354Question

Universal Containers has configured a custom architecture involving three custom objects: Program__c, Project__c, and Resource_Allocation__c.

The business analyst defines the following strict security and operational constraints:
1. Deleting a Program__c record must automatically cascade and delete all associated child Project__c records.
2. Administrators must display the sum of allocated hours from child Project__c records directly on the parent Program__c record using native declarative features.
3. Resource_Allocation__c must serve as a junction object establishing a Many-to-Many relationship between Project__c and Contact.
4. Users who possess only Read access to a parent Program__c record must be prevented from creating, editing, or deleting its related Project__c records.

Which two configuration steps must the administrator implement to satisfy these requirements? (Choose 2 answers)

Select all that apply

Show answer & explanation

Answer: Create a Master-Detail relationship field on Project__c referencing Program__c and define a Roll-Up Summary field on Program__c to aggregate allocated hours.; Configure the Master-Detail relationship field on Project__c with a Sharing Setting of Read/Write to require edit permissions on the master record for detail modifications.

Answer

The administrator must create a Master-Detail relationship on Project__c referencing Program__c with a Roll-Up Summary field on Program__c, and configure the Master-Detail field sharing setting to Read/Write.
Creating a Master-Detail relationship from Project__c to Program__c satisfies automatic cascade deletion upon parent deletion and unlocks native Roll-Up Summary fields on Program__c. Additionally, setting the Master-Detail relationship Sharing Setting to Read/Write forces users to have edit rights on Program__c to create, edit, or delete child Project__c records.

Step-by-Step Solution

1
Evaluate cascade deletion and aggregation requirements for Program__c and Project__c.
Determined that a Master-Detail relationship is required from Project__c (detail) to Program__c (master).
Master-Detail relationships enable automatic cascade deletion of child records and allow declarative Roll-Up Summary fields on the master object.
2
Evaluate record editing security requirements on child Project__c records based on parent Program__c access.
Configured the Master-Detail relationship Sharing Setting attribute to Read/Write.
Setting the relationship sharing setting to Read/Write restricts users with only Read access on the master record from creating, editing, or deleting detail records.

Key Concept

Master-Detail Relationship Capabilities and Security Settings
Question 355Question

A financial services firm needs to grant 15 compliance auditors temporary Read and Edit permissions on a custom object named 'Loan Applications'. The auditors currently share a standard baseline profile with other internal team members who must not have access to this object. What is the recommended administrative approach to grant the required access according to Salesforce security best practices?

Show answer & explanation

Answer: Create a permission set that grants Read and Edit access to the Loan Application object, and assign it directly to the 15 compliance auditors.

Answer

The administrator should create a permission set granting Read and Edit permissions on the Loan Application object and assign it to the 15 compliance auditors.
Salesforce security best practices dictate using profiles to define baseline access and permission sets to extend access to specific users. Creating a permission set for the custom object and assigning it to the auditors grants the necessary permissions without exposing the object to other users on the shared baseline profile.

Step-by-Step Solution

1
Analyze user access requirements
Identified that only a subset of users sharing a profile require extra object-level access.
Modifying a profile affects all users assigned to it, violating the principle of least privilege.
2
Select the appropriate security mechanism
Choose Permission Sets for granting additive permissions.
Permission sets allow flexible, additive permission assignments to individual users independently of their assigned profile.
3
Implement and assign
Create the permission set with object permissions for 'Loan Applications' and assign it to the designated compliance auditors.
This maintains a single streamlined profile architecture while fulfilling specific access requests.

Key Concept

Additive Permissions via Permission Sets
Estimated Time:1m 15s
Question 356Question

An administrator needs to prevent non-HR users from viewing or editing a sensitive custom field, SSN__c, on the Contact object across all UI pages, reports, search results, and API integrations. Which security mechanism should the administrator use to satisfy this requirement?

Show answer & explanation

Answer: Field-Level Security (FLS) on the Contact object settings

Answer

Field-Level Security (FLS) on the Contact object settings
Field-Level Security (FLS) directly controls whether a field is visible or editable for a profile or permission set across all access points, including page layouts, list views, reports, search results, and API integrations.

Step-by-Step Solution

1
Identify the administrative security requirement
The field must be protected from view and edit access across all channels, including reports and APIs.
Controls that operate strictly on user interface pages (like page layouts or component visibility) are insufficient for comprehensive field security.
2
Select the appropriate data security feature
Configure Field-Level Security (FLS) to set visibility and edit permissions by profile or permission set.
FLS is enforced at the platform layer across all tools, reports, list views, and APIs.

Key Concept

Field-Level Security (FLS) vs. Page Layout & Component Visibility
Estimated Time:45s
Question 357Question

A Salesforce Administrator needs to immediately block a user on extended leave from logging into the org. The user is currently assigned as the default owner for several active lead assignment rules and workflow updates. Which action should the administrator take to prevent login access without causing automation errors?

Show answer & explanation

Answer: Freeze the user account from the user setup page.

Answer

Freeze the user account from the user setup page.
Freezing a user account temporarily revokes the user's ability to log in without immediately unassigning their licenses or breaking automated processes (such as Lead Assignment Rules or Workflow default owners) where the user account is actively referenced.

Step-by-Step Solution

1
Identify the requirement to block user login without affecting active background process references.
Recognize that deactivating a user referenced in automated processes causes errors, whereas freezing suspends login capability immediately.
Freezing is designed specifically for scenarios where a user cannot be deactivated right away due to dependencies.
2
Select the option to freeze the user account.
The user is prevented from logging in while administrator holds time to reassign ownership dependencies.
Freezing stops access while preserving license and assignment references.

Key Concept

User Account Freezing vs. Deactivation
Estimated Time:45s
Question 358Question

A Salesforce administrator at a commercial real estate firm needs to ensure that values entered in a custom Date field, Target_Move_In_Date__c, on the Lead object are transferred to a custom field on the Opportunity object whenever a lead is converted. What configuration step is required to meet this requirement?

Show answer & explanation

Answer: Create a custom Date field on the Opportunity object and map the custom Lead field to it in the Lead Custom Field Mapping settings.

Answer

Create a custom Date field on the target object (Opportunity) with a compatible data type, then map the Lead custom field to the Opportunity custom field using the Map Lead Fields action on the Lead Object Manager page.
To preserve custom lead data during lead conversion, an administrator must create a corresponding custom field on the target object (Account, Contact, or Opportunity) with a compatible data type and map them together in the Lead Custom Field Mapping setup.

Step-by-Step Solution

1
Create the target field on the Opportunity object
A custom Date field exists on Opportunity to receive the converted data
Salesforce requires a custom field of compatible type on the target object before mapping can occur.
2
Navigate to Lead Object Manager and select 'Fields & Relationships', then 'Map Lead Fields'
Access to the Lead Conversion Mapping setup interface
This interface defines how custom lead data maps to Account, Contact, or Opportunity custom fields during conversion.
3
Map Target_Move_In_Date__c on Lead to the newly created custom Date field on Opportunity
Field mapping configured
Establishes automated data transfer upon successful lead conversion.

Key Concept

Custom Lead Field Mapping during Lead Conversion
Question 359Question

A Salesforce administrator needs to allow a Support Operations Team Lead to reset passwords and unlock account access for team members within their department, without giving the lead full System Administrator access or access to other departments. Which Salesforce capability should the administrator configure to meet this requirement?

Show answer & explanation

Answer: Delegated Administration

Answer

Delegated Administration
Delegated Administration is designed specifically for decentralizing user administration. It allows non-administrator users to perform specified tasks—such as resetting passwords, unlocking accounts, and managing user details—for users belonging to specified roles and subordinate roles.

Step-by-Step Solution

1
Analyze the administrative privilege requirement
The requirement requests granting password reset and user maintenance abilities restricted to a specific departmental subset of users.
Security controls require scoping administrative rights strictly to the user population managed by the lead.
2
Evaluate Salesforce administrative delegation mechanisms
Delegated Administration groups allow system administrators to specify delegated administrators, target roles/subordinates, and allowed profiles.
This provides localized user administration capabilities without granting organization-wide administrative access.

Key Concept

Delegated Administration allows system administrators to decentralize user management by granting non-administrator users permission to perform administrative tasks (such as resetting passwords and editing users) for specified roles.
Question 360Question

An administrator at Stellar Health Systems receives a request from the executive team to transition the organization from a standard calendar year to a custom 13-week quarterly fiscal structure. Before enabling Custom Fiscal Years in Setup, which critical operational constraint must the administrator communicate to executive leadership?

Show answer & explanation

Answer: Enabling Custom Fiscal Years is an irreversible action that permanently impacts standard forecasting and report grouping by standard fiscal periods.

Answer

Enabling Custom Fiscal Years is an irreversible action that permanently impacts standard forecasting and report grouping by standard fiscal periods.
In Salesforce, enabling Custom Fiscal Years is a permanent, irreversible organization-wide change. Once defined, standard fiscal year functionality cannot be restored, and standard forecasting features as well as automatic standard fiscal period groupings in reports are replaced by the custom fiscal structure.

Step-by-Step Solution

1
Identify the requested configuration change in Salesforce Setup.
The requirement calls for enabling Custom Fiscal Years to accommodate a non-standard 13-week quarterly schedule.
Standard Fiscal Years only support 12-month Gregorian calendar structures starting on the first day of any month.
2
Analyze the systemic impact of enabling Custom Fiscal Years.
Once Custom Fiscal Years are enabled, the setting cannot be undone, and standard fiscal year forecasting and automatic date reporting are permanently altered.
Salesforce explicitly warns administrators that enabling Custom Fiscal Years is irreversible.
3
Select the option that correctly describes this critical administrative constraint.
The option stating that enabling Custom Fiscal Years is irreversible and impacts standard forecasting and reporting is correct.
Administrators must evaluate the long-term impact on forecasting and reports before enabling this feature.

Key Concept

Custom Fiscal Year Irreversibility and Functional Limitations
PreviousPage 18 / 90Next
All practice questions — Salesforce Certified Administrator | Examkin