All practice questions

1784 questions

All types1,784 Multiple choice918 Multiple select587 Matching142 Ordering137

A pharmaceutical company needs to grant temporary Read and Edit access to the custom Clinical Trial object for five quality assurance specialists. These five specialists are assigned to different baseline profiles across various departments. Once the three-month clinical trial audit concludes, their elevated access must automatically cease without altering the access rights of other users who share their base profiles. Which TWO configuration steps should the administrator implement to meet these requirements efficiently? (Select 2)

Select all that apply

Create a permission set that grants Read and Edit access to the Clinical Trial object and assign it to the five quality assurance specialists.

Clone the baseline profiles for each department, enable Read and Edit permissions on the Clinical Trial object, and reassign the five specialists to the new profiles.

Specify an expiration date on the permission set assignment for each of the five specialists corresponding to the end of the audit.

Update the Organization-Wide Defaults for the Clinical Trial object to Public Read/Write for the duration of the audit period.

Show answer & explanation

Answer: Create a permission set that grants Read and Edit access to the Clinical Trial object and assign it to the five quality assurance specialists.; Specify an expiration date on the permission set assignment for each of the five specialists corresponding to the end of the audit.

Answer

The administrator should create a permission set granting Read and Edit permissions on the Clinical Trial object for the specialists, and set an expiration date on those permission set assignments to ensure access automatically ends after the three-month audit.

Permission sets provide additive permissions to specific users without altering base profiles shared by other users. Combining a permission set with assignment expiration dates handles temporary access requirements cleanly by automatically removing elevated permissions when the specified date is reached.

Step-by-Step Solution

Identify the proper access mechanism for additive, cross-profile permissions.

Determine that a permission set is required rather than modifying or cloning existing user profiles.

Profiles establish baseline access for job roles, whereas permission sets grant flexible additive permissions to selective users regardless of their profile.

Address the temporary nature of the audit access requirement.

Use permission set assignment expiration dates.

Setting an expiration date during assignment automates access revocation upon audit completion, eliminating manual administrative cleanup.

Key Concept

Permission Sets and Permission Set Assignment Expiration

Question 1722Question →

Helios Solar has three sales engineers who require access to create custom Solution Design records and export inventory reports. Their assigned 'Sales User' profile currently restricts these capabilities. The system administrator must grant these extra permissions to only these three users while adhering to Salesforce security best practices. How should the administrator meet this requirement?

Create a permission set with permissions to create Solution Design records and export reports, then assign it to the three sales engineers.

Clone the 'Sales User' profile, enable Solution Design creation and report export permissions, and reassign the three engineers to the new profile.

Edit the baseline 'Sales User' profile to enable Solution Design creation and report export for all sales users.

Create a new role in the role hierarchy that grants implicit edit permissions on Solution Design records and assign it to the three sales engineers.

Show answer & explanation

Answer: Create a permission set with permissions to create Solution Design records and export reports, then assign it to the three sales engineers.

Answer

Create a permission set with permissions to create Solution Design records and export reports, then assign it to the three sales engineers.

Salesforce security architecture emphasizes keeping profiles minimal and using permission sets to grant additive capabilities to specific users. Building a permission set with the required object and export permissions and assigning it directly to the designated engineers cleanly satisfies the business requirement without modifying baseline profiles.

Step-by-Step Solution

Analyze the access requirement.

The requirement asks for additive object-level permissions (create custom object records) and system permissions (export reports) for a specific subset of users.

Profiles define standard baseline access for job functions, whereas permission sets extend access flexibly.

Determine the appropriate Salesforce security mechanism.

Configure a permission set containing the necessary object and system settings.

Using a permission set prevents profile proliferation and enforces least-privilege security.

Assign the permission set to target users.

Assign the created permission set specifically to the three sales engineers.

Direct assignment ensures only the intended users receive the elevated privileges.

Key Concept

Using Permission Sets to Grant Additive Access

Question 1723Question →

An administrator at a telecommunications enterprise is updating field configurations for the custom object Subscription__c and reviewing Lead conversion configuration. The company needs to change an existing custom Text field named Monthly_Charge__c on Subscription__c to a Currency data type to support reporting. Additionally, the administrator must ensure that custom Lead fields capturing prospect network preferences map properly to target records during Lead conversion. Which TWO considerations and requirements must the administrator take into account when executing these changes? (Select 2)

Select all that apply

Custom Lead fields automatically map to standard Account and Contact fields with matching field labels without requiring manual field mapping setup.

Changing the field type of Monthly_Charge__c from Text to Currency can cause data loss if existing records contain non-numeric characters or exceed decimal precision rules.

Roll-up summary fields can be configured on the Subscription__c object to calculate totals on a parent Account linked via a standard Lookup relationship.

Custom Lead fields must be manually mapped to custom target fields of matching or compatible data types on the Account, Contact, or Opportunity object.

Adding a new picklist field to an object automatically enables all picklist values across all existing record types without further configuration.

Show answer & explanation

Answer: Changing the field type of Monthly_Charge__c from Text to Currency can cause data loss if existing records contain non-numeric characters or exceed decimal precision rules.; Custom Lead fields must be manually mapped to custom target fields of matching or compatible data types on the Account, Contact, or Opportunity object.

Answer

The administrator must account for potential data loss when changing the custom text field to currency if existing text values contain non-numeric characters, and must manually map custom Lead fields to custom fields of compatible data types on the target objects.

Changing a field type from Text to Currency carries a risk of data loss if existing values contain non-numeric text. In addition, converting custom Lead fields requires administrators to manually map each custom Lead field to a compatible custom field on the Account, Contact, or Opportunity object.

Step-by-Step Solution

Evaluate data type conversion risks

Identify that converting Text to Currency truncates or loses data if records contain non-numeric characters.

Salesforce enforces strict data type conversion rules to protect data integrity.

Configure Lead custom field mapping

Navigate to Object Manager -> Lead -> Field Mappings and map custom Lead fields to corresponding target custom fields on Account, Contact, or Opportunity.

Custom Lead fields do not automatically transfer to standard target fields or unmapped custom fields during conversion.

Key Concept

Custom Field Data Type Conversion Risks and Lead Custom Field Mapping Requirements

Estimated Time:2m 0s

Question 1724Question →

An administrator needs to grant a single Sales Representative the ability to edit the 'Budget' field on Opportunity records. Multiple other Sales Representatives share the same profile and must not be granted edit access to this field. What is the recommended Salesforce best practice to meet this requirement?

Create a Permission Set that grants edit permission for the Budget field and assign it to the specific Sales Representative.

Create a new custom profile with edit access to the Budget field and assign all Sales Representatives to this new profile.

Modify the existing shared profile to grant edit access to the Budget field for all assigned users.

Enable Grant Access Using Hierarchies on the Opportunity object to grant field-level edit permission.

Show answer & explanation

Answer: Create a Permission Set that grants edit permission for the Budget field and assign it to the specific Sales Representative.

Answer

Create a Permission Set that grants edit permission for the Budget field and assign it to the specific Sales Representative.

In Salesforce security architecture, profiles establish baseline access while Permission Sets are used to grant additional permissions on an ad-hoc or individual basis. Assigning a Permission Set with edit access on the 'Budget' field to only the specific user satisfies the requirement without expanding permissions for other users on the same profile.

Step-by-Step Solution

Identify the base access configuration

Multiple Sales Representatives share a common profile where the 'Budget' field is read-only or hidden.

Profiles set baseline permissions for all assigned users.

Determine the scope of the required access expansion

Only one specific Sales Representative requires edit access.

Modifying a shared profile or creating redundant profiles for minor access differences leads to poor profile management.

Apply the principle of additive permissions using Permission Sets

Create a Permission Set enabling Field-Level Security edit access on the 'Budget' field and assign it to the single user.

Permission Sets extend user entitlements additively without altering profile assignments.

Key Concept

Additive permissions via Permission Sets

Question 1725Question →

Cloud Kicks tracks sensitive executive compensation details using a custom object named Vendor_Payment__c. Management mandates that individual finance specialists should only see the payment records they own. Furthermore, executive managers above these specialists in the role hierarchy must be prevented from automatically gaining access to these payment records unless explicitly shared. Which security configuration should the administrator implement to fulfill this requirement?

Set the Organization-Wide Default for Vendor_Payment__c to Private and uncheck the Grant Access Using Hierarchies setting.

Set the Organization-Wide Default for Vendor_Payment__c to Private and assign a Permission Set to executive managers that revokes Read access.

Set the Organization-Wide Default for Vendor_Payment__c to Private and leave Grant Access Using Hierarchies checked, since role hierarchies only apply to standard objects.

Set the Organization-Wide Default for Vendor_Payment__c to Public Read-Only and restrict executive profiles using Object Permissions.

Show answer & explanation

Answer: Set the Organization-Wide Default for Vendor_Payment__c to Private and uncheck the Grant Access Using Hierarchies setting.

Answer

Set the Organization-Wide Default for Vendor_Payment__c to Private and uncheck the Grant Access Using Hierarchies setting.

The correct configuration requires setting the Organization-Wide Default (OWD) for the custom object to Private so that users only have access to records they own. Additionally, deselecting 'Grant Access Using Hierarchies' prevents users higher in the role hierarchy from automatically gaining access to records owned by subordinates.

Step-by-Step Solution

Determine the most restrictive baseline sharing setting (OWD) required for record owners only.

Setting the Organization-Wide Default (OWD) of Vendor_Payment__c to Private ensures users can only access records they own.

OWD sets the baseline record-level security across the organization.

Evaluate role hierarchy propagation behavior for custom objects.

Deselect the 'Grant Access Using Hierarchies' checkbox on the sharing settings for Vendor_Payment__c.

For custom objects, unchecking Grant Access Using Hierarchies disables automatic access inheritance by users higher in the role hierarchy.

Key Concept

Organization-Wide Defaults and Grant Access Using Hierarchies for Custom Objects

Question 1726Question →

A renewable energy enterprise uses a baseline custom profile for its field service technicians. To support an upcoming compliance audit, the administrator needs to grant ten senior technicians temporary privileges to export custom inspection reports and permanently delete obsolete turbine log records. The administrator must implement this access change without modifying the standard permissions of the remaining field service technicians or creating redundant administrative overhead. Which solution meets these security requirements?

Create a Permission Set containing the Export Reports system permission and Delete object permission for turbine logs, include it in a Permission Set Group, and assign the group to the ten senior technicians.

Clone the baseline technician profile to create a new Senior Technician profile with Export Reports and Delete access, then reassign the ten technicians to the new profile.

Enable Delete object access and Export Reports directly on the baseline technician profile, then assign a Muting Permission Set to all technicians who should not have access.

Change the Organization-Wide Default sharing settings for the turbine log object to Public Read/Write/Transfer, enabling deletion access for senior technicians.

Show answer & explanation

Answer: Create a Permission Set containing the Export Reports system permission and Delete object permission for turbine logs, include it in a Permission Set Group, and assign the group to the ten senior technicians.

Answer

Create a Permission Set containing the Export Reports system permission and Delete object permission, bundle it into a Permission Set Group, and assign the group to the senior technicians.

Salesforce architecture mandates that profiles should establish baseline access, while Permission Sets and Permission Set Groups should be utilized to grant additive capabilities to subset user groups. Constructing a Permission Set with the required system and object permissions and bundling it within a Permission Set Group cleanely extends access to the ten senior technicians without altering the base profile or creating profile sprawl.

Step-by-Step Solution

Analyze the permission requirement for the subset of technicians.

Identify that the requested permissions (Export Reports, Delete) represent additive permissions needed by only 10 out of all technicians.

Profile modifications affect all assigned users, making profile edits unsuitable for targeted access expansion.

Evaluate permission assignment tools following security best practices.

Design a Permission Set with the necessary system and object permissions, then aggregate it into a Permission Set Group.

Permission Sets provide flexible additive permissions, while Permission Set Groups allow streamlined assignment and management.

Assign the Permission Set Group to target users.

Grant access to the 10 senior technicians without affecting the baseline access of other technicians.

This maintains least privilege access and avoids profile proliferation.

Key Concept

Permission Sets and Permission Set Groups for Additive Access Management

Question 1727Question →

An organization wants to restrict default record visibility for the Lead object so that sales representatives can only view and edit the leads that they personally own. Which Organization-Wide Default (OWD) setting should the administrator select for the Lead object to meet this requirement?

Private

Public Read-Only with a profile restriction

Public Read/Write with a restrictive permission set

Public Read/Write and deselect 'Grant Access Using Hierarchies'

Show answer & explanation

Answer: Private

Answer

The administrator should set the Organization-Wide Default (OWD) for the Lead object to Private.

The correct setting is Private because Organization-Wide Defaults (OWD) establish the baseline level of access for an object. When OWD is set to Private, users cannot see or edit records owned by other users unless access is explicitly opened up through the role hierarchy, sharing rules, or manual sharing.

Step-by-Step Solution

Identify the required baseline access level

Users should only view records they own, requiring the most restrictive record access setting.

Organization-Wide Defaults establish the baseline record access for all users in the organization.

Evaluate standard OWD setting levels

The Private access setting restricts record visibility strictly to the record owner and users above them in the role hierarchy.

Setting OWD to Private ensures no other users have read or edit permissions by default.

Key Concept

Organization-Wide Defaults (OWD) set the baseline level of access for records, where Private provides the most restrictive access.

Estimated Time:45s

Question 1728Question →

An administrator at a global logistics firm is updating custom field architecture and field mapping configurations across custom objects and the Lead object. The administrator needs to convert existing relationship fields, configure custom lead mapping for lead conversion, and set up summary reporting on parent records.

Which two statements accurately describe the requirements and constraints when managing custom field conversions and relationship field capabilities in Salesforce?

Select all that apply

Converting a Lookup relationship field to a Master-Detail relationship field requires that all existing records on the child object have a populated value in the lookup field.

Converting a Master-Detail relationship field to a Lookup relationship field is prevented if any Roll-up Summary fields on the parent object reference the detail object.

Roll-up summary fields can be created on a parent object regardless of whether the child object is connected using a Lookup or a Master-Detail relationship.

Custom fields created on the Lead object can be mapped directly to existing standard fields on the Contact or Opportunity object during lead conversion.

Creating a new custom picklist field automatically assigns and enables all picklist values for all existing record types on that object.

Show answer & explanation

Answer: Converting a Lookup relationship field to a Master-Detail relationship field requires that all existing records on the child object have a populated value in the lookup field.; Converting a Master-Detail relationship field to a Lookup relationship field is prevented if any Roll-up Summary fields on the parent object reference the detail object.

Answer

Converting a Lookup relationship field to a Master-Detail relationship requires that all existing child records have a populated lookup field value. Furthermore, converting a Master-Detail relationship to a Lookup relationship is blocked if any Roll-up Summary fields on the parent object reference the child object.

Converting a Lookup relationship to a Master-Detail relationship is only permitted if every existing record on the child object contains a valid parent reference, as Master-Detail relationships require every detail record to have a master record. Additionally, converting a Master-Detail relationship to a Lookup relationship is prohibited if the master object contains Roll-up Summary fields that aggregate data from the detail object, because Roll-up Summary functionality is strictly dependent on Master-Detail architecture.

Step-by-Step Solution

Analyze relationship conversion requirements from Lookup to Master-Detail.

Identify that because Master-Detail relationships enforce mandatory parentage on detail records, all existing child records must have a populated lookup field before conversion is allowed.

Salesforce prevents orphaned records in Master-Detail relationships.

Analyze relationship conversion restrictions from Master-Detail to Lookup.

Identify that Roll-up Summary fields rely on Master-Detail relationship behavior.

If Roll-up Summary fields exist on the master object, the Master-Detail relationship cannot be changed to a Lookup until those Roll-up Summary fields are deleted.

Evaluate relationship limits for Roll-up Summary fields, Lead field mapping rules, and record type picklist assignments to eliminate distractors.

Confirm that Roll-up Summary fields require Master-Detail relationships, Lead custom fields can only map to custom fields on target objects, and picklist values must be manually assigned per record type.

These restrictions represent fundamental platform boundaries in Salesforce field configuration.

Key Concept

Custom Field Data Type Conversion and Relationship Field Constraints

Question 1729Question →

An administrator at Apex Universal is preparing to configure Custom Fiscal Years in Salesforce to align with the company's unique 13-week accounting period structure. Which key limitation must the administrator consider before enabling Custom Fiscal Years?

Enabling Custom Fiscal Years is an irreversible setting and affects standard forecasting and reporting features.

Custom Fiscal Years can be temporarily deactivated whenever the finance team needs to return to a standard calendar year.

Custom Fiscal Years automatically alter all historical opportunity close dates to match the new quarterly start dates.

Enabling Custom Fiscal Years requires all active user accounts to be frozen during the setup process.

Show answer & explanation

Answer: Enabling Custom Fiscal Years is an irreversible setting and affects standard forecasting and reporting features.

Answer

Enabling Custom Fiscal Years is an irreversible setting and affects standard forecasting and reporting features.

Once Custom Fiscal Years are enabled in a Salesforce organization, the action cannot be undone or reverted back to Standard Fiscal Years. Additionally, enabling custom fiscal years impacts standard forecasting and reporting functionality.

Step-by-Step Solution

Identify the key administrative impact of enabling Custom Fiscal Years in Salesforce.

Recognize that turning on Custom Fiscal Years is a permanent, non-reversible change.

Salesforce architecture permanently alters how fiscal years and periods are structured once custom fiscal years are enabled.

Determine the impact on standard Salesforce features.

Confirm that standard forecasting and reporting calculations are impacted.

Custom fiscal year definitions replace standard calendar assumptions across standard reports and forecasts.

Key Concept

Custom Fiscal Year Enablement Implications

Question 1730Question →

A Salesforce Administrator needs to ensure that call center representatives assigned to a specific profile are completely denied access to Salesforce if they attempt to log in from an IP address outside their corporate network range. Which security setting should the administrator configure to enforce this strict login restriction?

Trusted IP Ranges under Network Access in Organization Setup

Network Access settings on individual user records

Session Security Levels in Org-Wide Session Settings

Show answer & explanation

Answer: Login IP Ranges on the specific user profile

Answer

The administrator should configure Login IP Ranges on the specific user profile.

Configuring Login IP Ranges on the user profile strictly limits access to the designated IP addresses. Any user on that profile trying to log in from an unapproved IP address is completely blocked.

Step-by-Step Solution

Identify the security requirement

The requirement calls for complete denial of login access when originating outside specified IP ranges.

Hard login restriction outside defined IP boundaries is governed per profile in Salesforce.

Differentiate Profile IP Ranges from Org Network Access

Profile-level Login IP Ranges result in hard login prohibition outside the range. Organization-wide Network Access trusted IP ranges merely determine whether activation/identity verification is required.

Understanding the difference between access denial and identity verification is key to Salesforce login security configuration.

Key Concept

Profile Login IP Ranges vs. Org Network Access Trusted IP Ranges

Estimated Time:45s

Question 1731Question →

An administrator needs to track a prospect's preferred contact method using a custom picklist field on the Lead object. To ensure this data is automatically retained when a lead is converted into a contact, which action must the administrator take?

Map the custom Lead field to a compatible custom field on the Contact object in Lead Field Mapping.

Create a roll-up summary field on the Contact object that summarizes the Lead picklist field value.

Assign the custom picklist field directly to the Contact Record Type without mapping.

Set the field-level security of the Lead picklist field to Read-Only across all profiles.

Show answer & explanation

Answer: Map the custom Lead field to a compatible custom field on the Contact object in Lead Field Mapping.

Answer

Map the custom Lead field to a compatible custom field on the Contact object in Lead Field Mapping.

Mapping the custom Lead field to a compatible custom field on the Contact object within the Lead Object Manager settings ensures Salesforce automatically passes the picklist selection to the newly generated Contact record upon conversion.

Step-by-Step Solution

Identify the target requirement

Lead custom field data must transfer to the Contact record during lead conversion.

Standard lead conversion does not automatically carry custom field data to target records unless configured.

Configure Lead Field Mapping in Object Manager

Map the Lead custom picklist field to an existing custom picklist field on the Contact object.

Salesforce requires administrators to map custom lead fields to corresponding custom fields on Account, Contact, or Opportunity objects for data transfer.

Key Concept

Lead Custom Field Mapping during Lead Conversion

Question 1732Question →

An organization's global security baseline enforces a strict 15-minute session timeout and a 30-day password expiration policy configured in Organization-Wide Session Settings and Password Policies. To accommodate call center operations, executive leadership approves a specialized security exception for customer support representatives: a 60-minute session timeout and a 90-day password expiration interval. A Salesforce administrator creates a new Permission Set containing session-based settings and assigns it to the support team, but audits reveal that the support representatives are still being logged out after 15 minutes and prompted for password resets every 30 days. Which administrative action must be taken to successfully enforce these customized session and password requirements for the support representatives?

Configure the custom session timeout and password expiration values directly within the custom Profile assigned to the customer support representatives.

Add the call center IP address range to Organization-Wide Network Access settings to automatically elevate session timeout limits and bypass password expiration cycles.

Update the Organization-Wide Session Settings and Password Policies to 60 minutes and 90 days, then assign a restrictive Permission Set to all non-support users to decrease their thresholds back to 15 minutes and 30 days.

Create a Session-Based Permission Set Group linked to a custom Auth. Session object flow that dynamically updates user session parameters upon login.

Show answer & explanation

Answer: Configure the custom session timeout and password expiration values directly within the custom Profile assigned to the customer support representatives.

Answer

Configure the custom session timeout and password expiration values directly within the custom Profile assigned to the customer support representatives.

In Salesforce, Password Policies (such as password expiration intervals) and Session Settings (such as session inactivity timeouts) set at the organization level act as global defaults. When individual departments require tailored security parameters, these overrides must be configured directly on the specific Profile assigned to those users. Profile-level password policies and session settings completely take precedence over organization-wide defaults.

Step-by-Step Solution

Analyze the security governance hierarchy in Salesforce for session settings and password policies.

Identify that global defaults set at the organization level can be overridden specifically per user profile, but not via permission sets.

Salesforce architecture enforces Password Policies and Session Timeout overrides at the Profile level under Profile Security Settings.

Evaluate why the administrator's initial approach using a Permission Set failed.

Confirm that Permission Sets manage functional access rights (e.g., object permissions, system permissions) and cannot override session timeouts or password policy expirations.

Permission Sets lack configuration interfaces for baseline password expiration schedules and session inactivity timeouts.

Determine the proper administrative procedure to satisfy the compliance requirement.

Navigate to Setup > Profiles, select the custom profile assigned to customer support representatives, and edit the 'Password Policies' and 'Session Settings' sections directly on the profile.

Profile-level settings explicitly supersede Organization-Wide defaults for all users assigned to that profile.

Key Concept

Profile-Level Overrides for Session Settings and Password Policies

Estimated Time:2m 0s

Question 1733Question →

An administrator at Cloud Kicks is creating custom fields on the Lead object to capture potential client metrics, including an estimated budget and product interest, prior to lead conversion. The administrator creates the custom fields `Estimated_Budget__c` and `Product_Interest__c` on the Lead object. What must the administrator do to ensure data entered into these custom lead fields is successfully transferred to converted records?

Create corresponding custom fields on the target Account, Contact, or Opportunity objects and map them in Lead Conversion Settings.

Map the custom lead fields directly to standard fields on the Account and Contact objects using standard field mapping formulas.

Assign the custom picklist values to all active record types on the Lead object without creating target fields on destination records.

Create roll-up summary fields on the Account object to aggregate the custom lead field values through the standard lookup relationship.

Show answer & explanation

Answer: Create corresponding custom fields on the target Account, Contact, or Opportunity objects and map them in Lead Conversion Settings.

Answer

Create corresponding custom fields on the target Account, Contact, or Opportunity objects and map them in Lead Conversion Settings.

To preserve custom lead field values during lead conversion, an administrator must create corresponding custom fields on the target Account, Contact, or Opportunity objects and configure custom field mapping under Lead Object Manager settings.

Step-by-Step Solution

Identify the target objects for converted lead data.

Determine whether custom lead data belongs on the Account, Contact, or Opportunity object.

Data from custom lead fields is lost upon conversion unless mapped to corresponding custom fields on destination objects.

Create matching custom fields on the destination objects.

Ensure compatible custom fields exist on Account, Contact, or Opportunity.

Field mapping requires target custom fields with compatible data types.

Navigate to Object Manager > Lead > Fields & Relationships > Map Lead Fields.

Establish explicit mapping between custom Lead fields and target custom fields.

Salesforce automatically copies mapped field values during the lead conversion process.

Key Concept

Lead Custom Field Mapping

Question 1734Question →

A Salesforce Administrator at Vanguard Health configures login access restrictions for users assigned to the Telehealth Specialist profile. The organization-wide Network Access settings contain a trusted IP range of 203.0.113.0 to 203.0.113.255. On the Telehealth Specialist profile, the administrator defines a Login IP Range of 203.0.113.50 to 203.0.113.100 and configures Login Hours from 08:00 to 17:00 Monday through Friday. A telehealth clinician attempts to log in from IP address 203.0.113.10 at 10:00 AM on a Tuesday. Which system behavior will occur during this login attempt?

The login attempt is denied immediately because the user's IP address falls outside the Profile Login IP Ranges.

The user is prompted for identity verification via SMS or email code because the IP address is outside the profile range but within organization Network Access.

The login attempt is granted without verification because the user's IP address is listed within the organization-wide Network Access trusted IP range.

The login attempt succeeds, but the user is granted read-only session access because the request occurred during valid profile Login Hours.

Show answer & explanation

Answer: The login attempt is denied immediately because the user's IP address falls outside the Profile Login IP Ranges.

Answer

The login attempt is denied immediately because the user's IP address falls outside the Profile Login IP Ranges.

When Profile Login IP Ranges are defined, Salesforce enforces a strict denial for any login request outside the specified IP range. Even though the IP address 203.0.113.10 is included in the organization-wide Network Access list, profile-level IP boundaries strictly forbid access, causing the login attempt to be blocked immediately.

Step-by-Step Solution

Evaluate Profile Login Hours boundary

The login occurs at 10:00 AM on Tuesday, which falls within the permitted 08:00 to 17:00 Monday–Friday window.

Compare user IP against Profile Login IP Ranges

The user's IP address 203.0.113.10 lies outside the profile range of 203.0.113.50 to 203.0.113.100.

Profile Login IP Ranges define a strict restriction window. Any IP address outside this range results in hard denial.

Evaluate interaction between Profile IP Ranges and Org Network Access

Profile-level IP restrictions override org-level Network Access settings.

Org Network Access only determines identity verification (MFA challenge) requirements, whereas Profile IP Ranges strictly prohibit login attempts originating outside the range.

Key Concept

Profile Login IP Ranges act as strict access boundaries (hard deny), overriding organization-wide Network Access settings which only govern activation challenges.

Estimated Time:2m 0s

Question 1735Question →

Match each Salesforce security mechanism to its primary administrative function or access control use case.

Click a left item, then click its matching right item

Show answer & explanation

Answer

Permission Set Group pairs with bundling multiple permission sets; Muting Permission Set pairs with selectively silencing specific permissions in a group; Permission Set Expiration pairs with automatically revoking user access on a specified date; and Standalone Permission Set pairs with granting additional permissions without altering baseline profiles.

Each feature maps directly to its intended governance model in Salesforce Security: Permission Set Groups streamline multi-set assignments; Muting Permission Sets restrict specific elevated permissions inside groups; Permission Set Expiration manages temporary project access; and Standalone Permission Sets provide additive permissions while maintaining profile integrity.

Step-by-Step Solution

Identify the primary purpose of bundling permission sets.

Recognize that Permission Set Groups combine multiple permission sets into one assignment unit.

Grouping permissions streamlines administrative overhead for complex job functions.

Identify how permissions within a group can be selectively restricted.

Recognize that Muting Permission Sets silence specific permissions inside a Permission Set Group.

Muting avoids creating multiple nearly identical permission set groups for minor access variations.

Determine the feature used for time-bound permissions.

Recognize that setting an Expiration Date on a permission set assignment automatically removes access after the specified time.

Time-based assignments enforce security compliance for temporary roles or project assignments.

Analyze standard permission sets used outside of groups.

Recognize that standalone Permission Sets add discrete permissions to users without modifying user profiles.

Salesforce best practices dictate keeping profiles minimal and using permission sets for additive access.

Key Concept

Salesforce Permission Sets, Permission Set Groups, Muting Permission Sets, and User Assignment Expiration

Question 1736Question →

A Salesforce administrator needs to apply stricter password requirements specifically for users assigned to the Support Specialist profile. Which TWO password policy settings can be customized directly at the individual Profile level? (Select TWO)

Select all that apply

Maximum Invalid Login Attempts

User Password Expiration Period

Organization-wide Network Access IP Ranges

Permission Set Password Policy Overrides

Show answer & explanation

Answer: Maximum Invalid Login Attempts; User Password Expiration Period

Answer

Maximum Invalid Login Attempts and User Password Expiration Period can be customized at the Profile level.

Salesforce permits administrators to override organization-wide password policy defaults on individual Profiles. Maximum Invalid Login Attempts (lockout threshold) and User Password Expiration Period are both valid Profile-level password policy settings.

Step-by-Step Solution

Identify where password policy overrides take place in Salesforce administration.

Password policies exist at the Organization-Wide level and can be overridden on individual user Profiles.

Salesforce allows administrators to apply custom security settings per Profile when specific user roles require tighter security.

Evaluate which options represent settings that can be overridden on a Profile.

Maximum Invalid Login Attempts and User Password Expiration Period are configurable within Profile Password Policies.

These parameters control account lockout thresholds and password lifetimes for users assigned to that Profile.

Filter out non-profile or non-password settings.

Network Access IP ranges are configured globally under Network Access, and Permission Sets do not support password policy assignments.

Network Access is an organization-wide setting, and Permission Sets add permissions rather than defining Profile-level password governance.

Key Concept

Profile-Level Password Policy Overrides

Question 1737Question →

Cloud Kicks tracks performance bonuses using a custom object named Partner_Incentive__c. Management mandates that users must only be able to view and edit records that they own. Additionally, compliance requirements state that managers and executives above record owners in the role hierarchy MUST NOT automatically inherit access to these sensitive record details. Which combination of security configurations should the administrator apply to meet these requirements?

Set Default Internal Access to Private for Partner_Incentive__c and deselect the Grant Access Using Hierarchies checkbox.

Set Default Internal Access to Public Read-Only for Partner_Incentive__c and assign Permission Sets to restrict visibility for managers.

Set Default Internal Access to Private for Partner_Incentive__c and modify manager Profiles to revoke inherited sharing access.

Set Default Internal Access to Private for Partner_Incentive__c and leave Grant Access Using Hierarchies enabled, as custom objects do not propagate private records up the hierarchy.

Show answer & explanation

Answer: Set Default Internal Access to Private for Partner_Incentive__c and deselect the Grant Access Using Hierarchies checkbox.

Answer

Set Default Internal Access to Private for Partner_Incentive__c and deselect the Grant Access Using Hierarchies option.

Setting the Default Internal Access of a custom object to Private restricts record visibility exclusively to record owners and administrators. Because 'Grant Access Using Hierarchies' is enabled by default on custom objects, deselecting this option is required to stop automatic access propagation to users higher in the role hierarchy.

Step-by-Step Solution

Determine the baseline record-level access requirement.

Since users must only view and edit records they own, the Organization-Wide Default (OWD) baseline must be set to Private.

OWD is the most restrictive baseline level of data access in Salesforce.

Analyze role hierarchy access behavior for custom objects.

By default, Salesforce enables 'Grant Access Using Hierarchies' for all objects, which propagates record access to users above the owner in the role hierarchy.

To prevent managers and executives from automatically seeing Private records owned by direct reports, this feature must be explicitly disabled.

Verify custom object administrative capabilities.

For custom objects, administrators can uncheck 'Grant Access Using Hierarchies' in OWD settings (unlike standard objects where it is permanently enabled).

This achieves the strict privacy requirement for higher-level roles.

Key Concept

Organization-Wide Defaults (OWD) and Grant Access Using Hierarchies for Custom Objects

Question 1738Question →

An administrator at a financial services firm must configure record access for two objects: the standard Opportunity object and a custom object named Risk_Assessment__c. Management mandates that Opportunities must remain accessible to record owners and automatically roll up access to superiors in the role hierarchy. Conversely, Risk_Assessment__c records contain highly sensitive data that must be accessible solely by the record owner, explicitly preventing managers higher in the role hierarchy from inheriting record access automatically. Which setup for Organization-Wide Defaults (OWD) and hierarchy sharing settings correctly fulfills these security requirements?

Set Opportunity OWD to Private (where Grant Access Using Hierarchies is enabled by default and cannot be changed), and set Risk_Assessment__c OWD to Private while deselecting Grant Access Using Hierarchies.

Set both Opportunity and Risk_Assessment__c OWD to Private, and deselect the Grant Access Using Hierarchies checkbox on both object sharing settings.

Set Risk_Assessment__c OWD to Public Read-Only, and use Profile object settings to remove Read access for users occupying higher levels in the role hierarchy.

Set Risk_Assessment__c OWD to Private with Grant Access Using Hierarchies enabled, then assign a Permission Set Group to managers that revokes inherited sharing access.

Show answer & explanation

Answer: Set Opportunity OWD to Private (where Grant Access Using Hierarchies is enabled by default and cannot be changed), and set Risk_Assessment__c OWD to Private while deselecting Grant Access Using Hierarchies.

Answer

Set Opportunity OWD to Private (where Grant Access Using Hierarchies is enabled by default and cannot be modified), and set Risk_Assessment__c OWD to Private while deselecting the Grant Access Using Hierarchies checkbox.

Organization-Wide Defaults establish the baseline record access. For standard objects like Opportunity, access automatically propagates up the role hierarchy because 'Grant Access Using Hierarchies' is mandatory and cannot be disabled. For custom objects like Risk_Assessment__c, 'Grant Access Using Hierarchies' can be unchecked when OWD is Private, which successfully restricts access exclusively to the record owner.

Step-by-Step Solution

Analyze standard object sharing hierarchy behavior

Standard objects (such as Opportunity) have 'Grant Access Using Hierarchies' permanently checked and locked by Salesforce. Setting OWD to Private allows owners and superiors in the hierarchy to access records.

Salesforce architecture enforces role hierarchy access for all standard objects.

Analyze custom object sharing hierarchy behavior

Custom objects (such as Risk_Assessment__c) allow administrators to deselect 'Grant Access Using Hierarchies'.

Deselecting this option prevents record access from propagating up the role hierarchy.

Determine the baseline OWD for strict owner-only access

Combine a Private OWD with unchecked 'Grant Access Using Hierarchies' on the custom object.

This guarantees that non-owners, including managers above the owner, receive no access via OWD or hierarchy.

Key Concept

Organization-Wide Defaults and Grant Access Using Hierarchies behavior across standard versus custom objects

Question 1739Question →

An administrator needs to configure record access for a custom object named Project_Milestone__c. The business requirement specifies that users should only be able to view and edit milestone records they own, while managers above them in the role hierarchy should automatically retain access to those records. Which TWO settings must the administrator configure?

Select all that apply

Set the Organization-Wide Default (OWD) for Project_Milestone__c to Private.

Ensure the Grant Access Using Hierarchies checkbox is selected for Project_Milestone__c.

Create a permission set to restrict read and edit access for users who do not own the record.

Deselect the Grant Access Using Hierarchies checkbox on user profiles.

Show answer & explanation

Answer: Set the Organization-Wide Default (OWD) for Project_Milestone__c to Private.; Ensure the Grant Access Using Hierarchies checkbox is selected for Project_Milestone__c.

Answer

The administrator must set the Organization-Wide Default for Project_Milestone__c to Private and ensure that Grant Access Using Hierarchies is selected.

Setting the Organization-Wide Default to Private establishes the most restrictive baseline access where users only view records they own. Keeping Grant Access Using Hierarchies enabled ensures managers automatically inherit access to records owned by their subordinates.

Step-by-Step Solution

Determine the baseline access level required for non-owners.

The requirement specifies that users should only see their owned records, which demands a Private OWD setting.

OWD establishes the most restrictive baseline access level for records across the organization.

Ensure role hierarchy access propagation.

Verify that 'Grant Access Using Hierarchies' is enabled for the custom object.

By default, Grant Access Using Hierarchies is enabled for custom objects and allows managers to access records owned by direct reports.

Key Concept

Organization-Wide Defaults baseline security and role hierarchy access propagation

Estimated Time:1m 0s

Question 1740Question →

An administrator is configuring custom fields on a custom Asset management object to track hardware specifications and warranty details. Which two statements correctly describe standard capabilities and behavior of custom fields in Salesforce? (Select 2)

Select all that apply

Setting a custom field as universally required enforces data entry across all page layouts, API inserts, and data imports.

Custom Auto-Number fields generate unique sequence identifiers automatically whenever a new record is saved.

Roll-up summary fields can summarize data from child records connected through a standard Lookup relationship.

Custom fields created on the Lead object automatically map to Contact fields with identical API names upon lead conversion.

Adding a new picklist custom field automatically enables all defined picklist values across all active record types for that object.

Show answer & explanation

Answer: Setting a custom field as universally required enforces data entry across all page layouts, API inserts, and data imports.; Custom Auto-Number fields generate unique sequence identifiers automatically whenever a new record is saved.

Answer

Setting a custom field as universally required enforces data entry across all layouts and API calls, and custom Auto-Number fields automatically generate system-incremented sequence numbers on record creation.

Universally required custom fields enforce data validation across all user interface layouts, data loads, and API calls. Additionally, Auto-Number fields automatically generate system-incremented sequence numbers when records are created.

Step-by-Step Solution

Evaluate field enforcement properties

Marking a field as universally required at the field definition level forces validation on all user interactions, API calls, and data loads.

Universally required setting overrides layout-level permissions to ensure strict data completeness.

Evaluate field data type capabilities

Auto-Number is a read-only system-managed data type that increments automatically with each saved record.

Auto-Number fields format unique record IDs without requiring custom code or manual user entry.

Analyze limitations of relationship fields and mappings

Roll-up summaries require Master-Detail relationships, Lead custom field conversion requires explicit administrative mapping, and record types require manual picklist assignment.

These restrictions prevent data loss, unvalidated picklist values, and broken automation relationships.

Key Concept

Custom field properties, data types, and system-enforced constraints in Salesforce object management.

PreviousPage 87 / 90Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept