All practice questions

1784 questions

Question 1681Question

An organization has configured strict security settings for users assigned to the Field Specialist profile. The administrator set the Profile Login IP Ranges to 192.168.10.1192.168.10.1192.168.10.254192.168.10.254 and Profile Login Hours to Monday through Friday from 08:00 AM to 06:00 PM EST. Additionally, the Organization-Wide Network Access Trusted IP Ranges include 10.0.0.110.0.0.110.0.0.25410.0.0.254. A user assigned to the Field Specialist profile attempts to log in under two different scenarios:

1. On Wednesday at 09:00 PM EST from IP address 192.168.10.45192.168.10.45.
2. On Thursday at 02:00 PM EST from IP address 10.0.0.5010.0.0.50.

Which two login outcomes will occur based on these configurations?

Select all that apply

Show answer & explanation

Answer: The login attempt on Wednesday at 09:00 PM EST is denied because it occurs outside the profile's allowed Login Hours.; The login attempt on Thursday at 02:00 PM EST is denied because Profile Login IP Ranges restrict login access outside the defined profile range.

Answer

The login attempt on Wednesday at 09:00 PM EST is denied due to Profile Login Hours restrictions, and the login attempt on Thursday at 02:00 PM EST is denied because Profile Login IP Ranges enforce a hard restriction regardless of Organization Network Access settings.
The correct outcomes recognize that profile security settings enforce strict access controls. Violating Profile Login Hours causes an immediate block of authentication. Furthermore, Profile Login IP Ranges establish an explicit whitelist; any login from an IP address not included in the profile's range is blocked outright, regardless of organization-level Network Access configurations.

Step-by-Step Solution

1
Evaluate the first scenario against Profile Login Hours.
Wednesday at 09:00 PM EST falls outside the Monday–Friday 08:00 AM to 06:00 PM EST window.
Profile Login Hours dictate strict operational windows. Any attempt outside these hours results in complete denial of access.
2
Evaluate the second scenario against Profile Login IP Ranges vs. Org Network Access.
IP 10.0.0.5010.0.0.50 is not within the profile range 192.168.10.1192.168.10.1192.168.10.254192.168.10.254.
Profile-level IP ranges act as a hard security boundary. If IP ranges are defined on a profile, any login attempt from an IP outside that range is blocked entirely, irrespective of Organization-Wide Trusted IP settings.

Key Concept

Profile-level Login Security boundaries (Login Hours and IP Ranges) strictly deny access when violated and supersede Organization-Wide Network Access settings.
Question 1682Question

An administrator at Cloud Kicks is designing an enterprise access control architecture using Permission Sets and Permission Set Groups. Match each specific administrative requirement on the left with the correct Salesforce configuration mechanism on the right.

Click a left item, then click its matching right item

Items

Granting temporary access to manage sensitive financial fields for a 14-day audit project without modifying baseline profile settings.
Restricting 'Delete' access on the Account object for users assigned a bundled set of permissions, without modifying the underlying component permission sets.
Combining multiple distinct permission sets ('Lead Manager', 'Opportunity Approver', and 'Contract Editor') into a single reusable package for simplified user assignment.
Providing additive 'Read' and 'Create' permissions on a custom 'Audit Log' object to a select group of users spanning multiple departments.

Matches

Show answer & explanation

Answer

The correct matches pair temporary financial field access with Permission Set Expiration Date Assignment, restricting delete access within a bundle with a Muting Permission Set, combining permission sets into a single package with a Permission Set Group, and extending custom object permissions with a Standalone Permission Set.
Each administrative requirement aligns with a specific Salesforce security feature: temporary access requires assignment expiration dates; masking permissions within an aggregated bundle requires a muting permission set; packaging multiple permission sets together requires a permission set group; and granting incremental permissions across different roles requires a standalone permission set.

Step-by-Step Solution

1
Evaluate requirement 1 regarding time-bound access for a 14-day audit project.
Identify that setting an expiration date on a permission set assignment automatically handles temporary access revocation.
Salesforce natively supports assignment expiration dates on user permission set assignments.
2
Evaluate requirement 2 regarding turning off a specific permission within bundled permission sets.
Identify Muting Permission Sets as the mechanism to suppress permissions inside a Permission Set Group.
Muting permission sets selectively negate permissions within the context of the group in which they are placed.
3
Evaluate requirement 3 regarding aggregating multiple permission sets into one assignable unit.
Identify Permission Set Groups as the solution for combining related permission sets.
Permission Set Groups streamline user assignment by bundling separate permission sets together.
4
Evaluate requirement 4 regarding granting additional object access to specific cross-departmental users.
Identify a Standalone Permission Set as the proper tool for additive user permissions.
Profiles define baseline access, whereas standalone permission sets addively grant object/field permissions to specific users.

Key Concept

Permission Sets, Permission Set Groups, Muting Permission Sets, and User Assignment Expiration
Estimated Time:2m 0s
Question 1683Question

An administrator at a healthcare company needs to revise several custom fields on the custom object Medical_Device__c to support a new regulatory compliance audit. The administrator plans to convert field types and reconfigure object settings. Which two technical impacts and data integrity risks must the administrator account for before changing custom field data types? (Select 2)

Select all that apply

Show answer & explanation

Answer: Converting a field from Text to Picklist may result in data loss if existing text values exceed 255 characters or contain unsupported data formats.; Changing a custom field type from Auto-Number to Text retains existing data values but permanently prevents the field from generating incremental sequential identifiers.

Answer

Converting a custom Text field to a Picklist risks data loss for values exceeding 255 characters, and converting an Auto-Number field to Text retains existing values while halting automated sequence generation.
Converting a Text field to a Picklist restricts entries to a 255-character limit, causing data truncation or loss for longer values. Additionally, converting an Auto-Number field to a Text field preserves existing record data as text while stopping automatic sequential number generation for future records.

Step-by-Step Solution

1
Analyze data conversion rules from Text to Picklist.
Identified that text values longer than 255 characters are truncated or lost upon conversion to a single-select Picklist field.
Picklist fields impose a maximum length limit of 255 characters per entry.
2
Evaluate the structural impact of converting an Auto-Number field to a Text field.
Existing values are preserved as plain text strings, but future sequence numbering stops.
Text fields lack auto-increment engines required for sequential identifier generation.
3
Evaluate incorrect relationship and conversion assumptions.
Disqualified statements regarding automatic Roll-Up conversion, automatic Record Type assignment, and automatic Lead conversion mapping updates.
Salesforce requires explicit master-detail relationships for roll-ups and manual configuration for record types and lead field mapping.

Key Concept

Custom Field Data Type Conversion Consequences and Data Protection
Question 1684Question

Northern Trail Outfitters uses a custom object named `Supplier_Audit__c` to store sensitive internal vendor reviews. Business requirements mandate that access must be restricted so that only the record owner has access to their assigned audits. Additionally, executive managers positioned higher in the role hierarchy must NOT automatically inherit access to these sensitive record reviews.

Which TWO configuration actions must a Salesforce administrator execute in Organization-Wide Defaults (OWD) to satisfy these security requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Set the Default Internal Access for Supplier_Audit__c to Private.; Deselect the 'Grant Access Using Hierarchies' checkbox for the Supplier_Audit__c object.

Answer

To enforce the most restrictive access baseline where only record owners have access and role hierarchy inheritance is disabled for a custom object, the administrator must set the Organization-Wide Default (OWD) to Private and deselect the 'Grant Access Using Hierarchies' setting on that custom object.
Organization-Wide Defaults (OWD) establish the baseline level of access for records in Salesforce. Setting the OWD of a custom object to Private ensures that non-owners cannot see records by default. Furthermore, while standard objects always grant access to superior roles in the role hierarchy, custom objects allow administrators to deselect 'Grant Access Using Hierarchies' to stop users higher in the role hierarchy from automatically gaining access to records owned by subordinates.

Step-by-Step Solution

1
Determine the baseline record sharing access required for record owners.
Identify that setting the Organization-Wide Default (OWD) to Private restricts record visibility exclusively to the record owner by default.
OWD is the only mechanism in Salesforce used to restrict baseline record access across the organization.
2
Evaluate role hierarchy record access behavior for custom objects.
Recognize that Grant Access Using Hierarchies is enabled by default for custom objects, allowing management higher in the role hierarchy to view subordinate records even when OWD is Private.
To prevent managers from inheriting access, the 'Grant Access Using Hierarchies' option must be explicitly unchecked.
3
Verify profile and permission set capabilities regarding record restriction.
Confirm that profiles and permission sets control object/field access permissions and can only expand access, never restrict sharing access established by OWD.
Attempting to use permission sets or object permissions to restrict visibility violates core Salesforce security architecture.

Key Concept

Organization-Wide Defaults (OWD) and Grant Access Using Hierarchies settings for custom objects
Estimated Time:2m 0s
Question 1685Question

A security audit requires an organization to implement strict login controls for users assigned to the Field Auditor role. The administrator must ensure that:
1. Users attempting to log in from outside the corporate VPN subnet are completely blocked from authenticating.
2. Users currently logged in have their active session forcibly terminated as soon as their defined shift ends.

Which two configuration actions must the System Administrator perform to meet these requirements? (Select 2 answers)

Select all that apply

Show answer & explanation

Answer: Add the corporate VPN subnet to the Login IP Ranges section on the Field Auditor profile.; Enable 'When login hours expire, terminate the session immediately' in Session Settings.

Answer

The administrator must add the corporate VPN subnet to the Login IP Ranges section on the user profile and enable immediate session termination upon login hours expiration in Session Settings.
Adding IP ranges to a user profile restricts login access strictly to those IP addresses, denying any attempt outside the range. Additionally, selecting the immediate session termination option under Session Settings ensures that active user sessions end immediately when profile Login Hours expire rather than allowing passive view access.

Step-by-Step Solution

1
Differentiate profile-level IP restrictions from org-wide Network Access.
Recognize that profile-level Login IP Ranges enforce a strict denial for any IP outside the specified list, satisfying the requirement to completely block unauthorized IP authentication.
Org-wide Network Access ranges only allow users to bypass activation code prompts, whereas profile IP ranges restrict total access.
2
Configure the session expiration behavior for active users.
Identify the Session Settings option 'When login hours expire, terminate the session immediately'.
Without this global setting enabled, users already logged in when their profile Login Hours end can remain in their session until navigating or making server calls.
3
Verify profile vs permission set capabilities.
Confirm that IP range restrictions and Login Hours can only be enforced at the profile level, not via permission sets.
Salesforce architecture mandates that IP ranges and login hours are defined per profile.

Key Concept

Profile IP Restrictions vs. Org Network Access and Session Setting Expiration Policies
Question 1686Question

An administrator at Financial Consultants Inc. is building a custom application to manage client portfolios. The administrator needs to display the calculated total sum of asset values from a child custom object on the parent custom object Portfolio__c. The two objects are currently connected by a Lookup relationship. When creating a new custom field on Portfolio__c, the administrator notices that the Roll-Up Summary field type option is disabled. Why is the administrator unable to select the Roll-Up Summary field type?

Show answer & explanation

Answer: Roll-up summary fields can only be created on the master object in a Master-Detail relationship.

Answer

Roll-up summary fields can only be created on the master object in a Master-Detail relationship.
In Salesforce, native Roll-Up Summary fields summarize data from related detail records and are only available on the master object in a Master-Detail relationship. Because the two objects are currently connected via a Lookup relationship, the Roll-Up Summary field type is unavailable during field creation.

Step-by-Step Solution

1
Identify the relationship type currently connecting the parent and child objects.
The objects are currently linked via a Lookup relationship.
Salesforce standard functionality determines field type availability based on relationship architecture.
2
Evaluate Salesforce platform requirements for creating native Roll-Up Summary custom fields.
Native Roll-Up Summary fields are exclusively supported on the master object of a Master-Detail relationship.
Objects connected by a Lookup relationship cannot use declarative Roll-Up Summary fields without converting the relationship to Master-Detail or using custom automation.

Key Concept

Roll-Up Summary Field Eligibility and Relationship Types
Question 1687Question

A company's financial team requests that the Salesforce administrator change the organization's fiscal year start month from January to July while keeping a standard 12-month calendar structure. Which statement accurately describes the impact of updating the start month in Standard Fiscal Year settings?

Show answer & explanation

Answer: Salesforce automatically recalculates fiscal quarters and updates existing reports and forecasts to reflect the new start month.

Answer

Salesforce automatically recalculates fiscal quarters and updates existing reports and forecasts to reflect the new start month.
In Salesforce, Standard Fiscal Years follow a standard 12-month structure starting on the first day of any chosen month. Changing the fiscal year start month automatically updates report calculations and opportunity forecasting throughout the organization without converting the org to Custom Fiscal Years.

Step-by-Step Solution

1
Identify the fiscal year requirement
The requirement is to change the fiscal year start month from January to July while maintaining a standard 12-month structure.
Determining whether the structure remains a standard 12-month cycle dictates if standard settings apply.
2
Evaluate Standard Fiscal Year capabilities
Standard Fiscal Years in Salesforce permit selecting any month as the start month without requiring Custom Fiscal Years.
Standard Fiscal Years flexibly support any 12-month calendar start month.
3
Determine system impact
Salesforce automatically recalculates report quarters, performance metrics, and forecasting dates based on the new July start month.
Standard fiscal settings dynamically update existing reporting structures upon saving.

Key Concept

Standard Fiscal Year Settings
Question 1688Question

A regional manager at a logistics firm requires the 'Export Reports' permission to perform a one-time quarterly audit. This access is not granted by their current profile, and other employees assigned to the same profile should not receive this permission. Which administrative action should be taken to grant this user the required permission?

Show answer & explanation

Answer: Create a permission set with the Export Reports permission enabled and assign it to the regional manager.

Answer

Create a permission set with the Export Reports permission enabled and assign it to the user.
Permission sets are designed to grant additive permissions to individual users without affecting baseline access settings of other users assigned to the same profile. This adheres to Salesforce security best practices.

Step-by-Step Solution

1
Analyze access requirements
A single user needs an additional permission that should not be shared by other users sharing the same profile.
Profiles govern baseline access across groups of users, whereas Permission Sets grant additive access to specific individuals.
2
Determine the administrative mechanism
Use a Permission Set rather than modifying or creating profiles.
Permission sets allow administrators to grant incremental permissions cleanly without modifying profile assignments.

Key Concept

Additive Access with Permission Sets
Question 1689Question

Highland Healthcare Systems is planning to restructure its financial tracking to align with a custom 4-4-5 accounting cycle. The Chief Financial Officer requests that the Salesforce Administrator enable Custom Fiscal Years in the organization. Before implementing this change in Setup, which critical operational constraint must the administrator communicate to executive leadership regarding Custom Fiscal Years?

Show answer & explanation

Answer: Activating Custom Fiscal Years is an irreversible action that prevents reverting back to standard fiscal years, and it impacts standard forecasting and report filter behavior.

Answer

Activating Custom Fiscal Years is an irreversible action that prevents reverting back to standard fiscal years, and it impacts standard forecasting and report filter behavior.
Enabling Custom Fiscal Years is a permanent decision in Salesforce. Once activated, the org cannot switch back to standard fiscal years. Additionally, custom fiscal years impact how standard forecasting, quota definitions, and date filter logic operate across reports and dashboards.

Step-by-Step Solution

1
Analyze the administrative request
The organization needs to transition from a standard calendar fiscal year to a 4-4-5 custom fiscal year structure.
Custom fiscal years are required when an organization does not follow a standard 12-month calendar year beginning on the first day of a month.
2
Evaluate system setting constraints in Salesforce Setup
Identify that Custom Fiscal Years is a permanent, organization-wide configuration.
Salesforce explicitly warns administrators during setup that enabling custom fiscal years cannot be reverted.
3
Determine operational impact on reporting and forecasting
Understand that standard forecasting models and default date filters in reports will adapt to defined custom periods and cannot use standard calendar logic.
Custom fiscal years alter how standard date ranges (such as 'Current FY') map across opportunities and forecasts.

Key Concept

Irreversibility and operational consequences of enabling Custom Fiscal Years in Salesforce Company Information settings.
Question 1690Question

An administrator at a security firm is configuring record-level access for a custom object named Vendor_Audit__c and evaluating default access behaviors across standard and custom objects. The compliance team requires that records be kept confidential by default, while allowing management access control flexibility. Which of the following statements correctly describe Organization-Wide Default (OWD) capabilities and security principles for this scenario? (Select TWO choices.)

Select all that apply

Show answer & explanation

Answer: Setting the Organization-Wide Default for Vendor_Audit__c to Private establishes the baseline access, ensuring users cannot view records owned by others unless granted access through hierarchy or sharing.; Disabling 'Grant Access Using Hierarchies' is configurable for custom objects like Vendor_Audit__c, whereas standard objects always enforce access propagation up the role hierarchy.

Answer

The correct statements are that setting OWD to Private establishes the default record-level baseline access, and that 'Grant Access Using Hierarchies' can be disabled for custom objects but is mandatory for standard objects.
Setting OWD to Private ensures records are inaccessible by default to non-owners, establishing the foundational record security baseline. Additionally, custom objects provide the administrative flexibility to uncheck 'Grant Access Using Hierarchies', whereas standard objects mandate hierarchy access propagation.

Step-by-Step Solution

1
Evaluate baseline record visibility requirements.
Setting Organization-Wide Defaults (OWD) to Private restricts record visibility so that users cannot see records owned by others unless explicitly granted access.
OWD is the only mechanism in Salesforce that sets the baseline record-level access across the organization.
2
Analyze Role Hierarchy inheritance differences between custom and standard objects.
Custom objects allow administrators to deselect 'Grant Access Using Hierarchies', whereas standard objects enforce hierarchy access automatically and cannot be disabled.
Salesforce architecture allows flexibility for custom objects while locking mandatory hierarchy inheritance for standard objects.
3
Identify misconceptions regarding profiles and hierarchy depth.
Profiles manage broad object permissions rather than record-level visibility, and hierarchy grants extend to all superior roles above the owner in the hierarchy branch.
Understanding the separation of Object-Level Security (Profiles/Permission Sets) and Record-Level Security (OWD/Sharing) is essential to proper security configuration.

Key Concept

Organization-Wide Defaults (OWD) set the baseline record access in Salesforce. Profiles/Permission Sets grant object-level access (CRUD) but cannot restrict record access below OWD. Furthermore, 'Grant Access Using Hierarchies' can only be disabled on custom objects.
Question 1691Question

Cloud Components Inc. is reconfiguring its financial structure in Salesforce to align with a complex 13-week quarterly accounting calendar. Before enabling this feature under Company Information and Fiscal Year settings, the Lead Administrator must brief leadership on the long-term system implications. Which major technical constraint must the administrator communicate regarding the activation of Custom Fiscal Years?

Show answer & explanation

Answer: Enabling custom fiscal years is an irreversible action that permanently disables standard fiscal year calendar functionality and impacts existing forecast definitions.

Answer

Enabling custom fiscal years is an irreversible action that permanently disables standard fiscal year calendar functionality and impacts existing forecast definitions.
Enabling Custom Fiscal Years in Salesforce is a critical, irreversible organization-wide decision. Once custom fiscal years are activated, standard fiscal year calendars can no longer be used, and standard forecasting capabilities are affected as custom periods take effect.

Step-by-Step Solution

1
Evaluate the administrative impact of enabling Custom Fiscal Years in Salesforce Setup.
Identify that custom fiscal years are designed for organizations requiring non-gregorian or custom financial periods (such as 4-4-5 or 13-week quarters).
Salesforce explicitly warns administrators prior to activation that enabling custom fiscal years cannot be reverted.
2
Analyze downstream implications on Salesforce features such as Collaborative Forecasting and standard report filters.
Determine that standard calendar fiscal settings are deactivated and existing forecasting structures must be recreated to conform to custom fiscal periods.
Custom fiscal years change the baseline date ranges for quarters and financial years across the entire organization.

Key Concept

Irreversibility and Forecasting Impacts of Custom Fiscal Years
Estimated Time:2m 0s
Question 1692Question

A Salesforce administrator at Helios Financial needs to configure a 4-4-5 financial calendar to align Salesforce reporting with the organization's accounting cycle. Which critical operational implication must the administrator evaluate before enabling Custom Fiscal Years?

Show answer & explanation

Answer: The change is irreversible, and custom fiscal periods will impact standard forecasting while requiring manual definition for all future years.

Answer

Enabling custom fiscal years is an irreversible feature activation that impacts standard forecasting and requires custom fiscal periods to be defined manually for all subsequent years.
Enabling Custom Fiscal Years in Salesforce is a permanent, non-reversible administrative decision. Once enabled, the organization loses the ability to revert back to Standard Fiscal Years, and standard forecasting capabilities change significantly, requiring custom fiscal years to be manually defined year after year.

Step-by-Step Solution

1
Analyze business requirement
The company requires a non-standard 4-4-5 accounting calendar.
Standard fiscal years only support 12-month cycles starting on the first day of any month.
2
Evaluate system impact of enabling Custom Fiscal Years
Custom Fiscal Years cannot be disabled once turned on.
Salesforce explicitly warns that custom fiscal year enablement is irreversible.
3
Identify affected functionality
Standard forecasting metrics, quotas, and report periods are permanently altered, requiring manual administration for future years.
Custom fiscal year definitions do not auto-populate for future years and alter standard forecasting behavior.

Key Concept

Custom Fiscal Year Enablement Implications and Irreversibility
Estimated Time:1m 15s
Question 1693Question

A System Administrator assigned a remote inventory specialist to the custom profile 'Logistics Operations'. The administrator configured Profile-level Login IP Ranges on this profile to strictly permit access from the corporate VPN range of 198.51.100.1 to 198.51.100.50. Later, the administrator added a home broadband IP range of 203.0.113.10 to 203.0.113.20 under the organization-level Network Access settings. What happens when the inventory specialist attempts to log in from home using the IP address 203.0.113.15?

Show answer & explanation

Answer: The user is denied access entirely and cannot log in.

Answer

The user is denied access entirely and cannot log in because profile-level login IP ranges impose a hard restriction on access.
When Login IP Ranges are defined on a user's Profile, Salesforce enforces a strict access policy. Any login attempt from an IP address outside the profile's specified range is denied access completely. Organization-level Network Access settings cannot grant access or bypass restrictions set at the Profile level.

Step-by-Step Solution

1
Evaluate Profile-level Login IP Ranges
Profile Login IP Ranges are set to 198.51.100.1 - 198.51.100.50. The user IP (203.0.113.15) falls outside this range.
Profile-level IP restrictions define the explicit boundary outside of which login is completely prohibited.
2
Evaluate Organization-level Network Access (Trusted IP Ranges)
The user IP is listed in Network Access, but Network Access only controls identity verification prompts (MFA/activation codes) when profile IP ranges are absent.
Profile-level security settings always take precedence over org-wide Network Access trusted IP settings.
3
Determine Final Login Outcome
Because the user's IP is outside the Profile Login IP Range, Salesforce rejects the authentication attempt.
Profile IP ranges act as an absolute access block rather than a trigger for identity verification.

Key Concept

Profile Login IP Ranges vs. Organization Network Access
Question 1694Question

An organization uses a custom Billing application where access is managed using a Permission Set Group named 'Billing Operations Group'. This group includes three permission sets: Invoicing Access, Payment Processing, and Credit Adjustments. A compliance audit requires that a subgroup of internal auditors assigned to this group must retain all viewing and editing capabilities provided by the group, but must be explicitly restricted from deleting Credit Adjustment records. All other billing users must continue to have delete access. How should the system administrator meet this requirement while maintaining a scalable access architecture?

Show answer & explanation

Answer: Create a new Permission Set Group for the internal auditors containing the three permission sets, and add a Muting Permission Set to the group that disables Delete access on the Credit Adjustment object.

Answer

Create a new Permission Set Group specifically for internal auditors that bundles the original permission sets along with a Muting Permission Set that revokes Delete permission on the Credit Adjustment object.
Permission Set Groups consolidate permissions into single assignments. When a subset of users assigned to a group requires a restriction (such as revoking Delete access), the recommended solution is to include a Muting Permission Set within a dedicated Permission Set Group. This mutes specified permissions without affecting the underlying reusable Permission Sets.

Step-by-Step Solution

1
Analyze access requirements
Internal auditors require the exact permissions of the existing Permission Set Group minus the Delete capability on a specific custom object.
Additive permission modeling using Permission Set Groups allows re-using underlying permission sets while muting unwanted permissions.
2
Evaluate Muting Permission Set capabilities
A Muting Permission Set can be added to a Permission Set Group to mute specific Object, Field, or User permissions.
This avoids modifying the source permission sets that are shared across other groups or users.
3
Select the optimal architecture
Constructing an Auditor Permission Set Group with the three base permission sets plus a Muting Permission Set fulfills the audit restriction while maintaining a streamlined admin model.
This approach preserves reusable components without resorting to profile redundancy or record sharing mechanisms.

Key Concept

Permission Set Groups and Muting Permission Sets
Question 1695Question

An administrator at Zenith Financial is establishing access controls for a newly created custom object, Strategic_Account_Plan__c, which contains sensitive client growth strategies. Executive leadership mandates the following security criteria:

1. Default access must restrict all users from viewing or editing records created by others across different branches of the organization.
2. Managers and executives positioned above the record owner in the role hierarchy must automatically inherit full access to view and update their subordinates' account plan records.
3. Non-owner peers within the same department or role level must be denied visibility to these records by default.

Which Organization-Wide Default (OWD) configuration and sharing setting for Strategic_Account_Plan__c fulfills these requirements while maintaining standard record access inheritance?

Show answer & explanation

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

Answer

Set Default Internal Access to Private and keep Grant Access Using Hierarchies selected.
Setting the Organization-Wide Default (OWD) to Private restricts record visibility solely to the record owner by default. Keeping 'Grant Access Using Hierarchies' selected ensures that users positioned above the owner in the role hierarchy automatically inherit access to those records. This satisfies both strict peer privacy and executive access requirements.

Step-by-Step Solution

1
Determine the baseline Organization-Wide Default (OWD) requirement.
Since non-owners must be restricted from viewing peer records by default, the most restrictive baseline OWD setting of Private is required.
OWD sets the baseline level of access for the most restricted user in the organization.
2
Evaluate role hierarchy access requirements for the custom object.
Keep 'Grant Access Using Hierarchies' enabled (selected).
For custom objects, Grant Access Using Hierarchies is checked by default. Keeping it selected ensures record access automatically propagates up the role hierarchy to higher management roles.
3
Validate against alternative permission models.
Reject profile or permission set restriction strategies.
Salesforce security follows an additive model; profiles and permission sets grant object-level access and permissions but can never restrict record-level access granted by OWD.

Key Concept

Organization-Wide Defaults (OWD) and Role Hierarchy Inheritance for Custom Objects
Question 1696Question

An administrator at a renewable energy company creates custom fields on the Lead object to capture site assessment data, such as 'Roof Angle' and 'Solar Panel Capacity'. The business requirement specifies that this information must automatically transfer to the corresponding Account and Contact records created during lead conversion. Which administrative action is required to ensure this data persists when converting leads?

Show answer & explanation

Answer: Map the custom Lead fields to the designated custom Account and Contact fields using the Map Lead Fields tool in Object Manager.

Answer

The administrator must map the custom fields on the Lead object to the custom fields on the target Account and Contact objects using the 'Map Lead Fields' setup tool under Lead Fields & Relationships.
When converting a Lead, standard fields are automatically mapped to standard fields on Account, Contact, and Opportunity. However, data in custom Lead fields will be lost unless the administrator manually configures mapping via the 'Map Lead Fields' interface under the Lead object's Fields & Relationships menu.

Step-by-Step Solution

1
Create corresponding target custom fields on the target objects.
Custom fields with compatible data types exist on Account and Contact.
Custom Lead fields can only be mapped to existing custom fields of compatible data types on Account, Contact, or Opportunity.
2
Navigate to Object Manager > Lead > Fields & Relationships and select 'Map Lead Fields'.
The lead field mapping interface opens.
This interface defines explicit mapping targets for custom lead data upon conversion.
3
Select the corresponding Account and Contact fields for each custom Lead field and save the mapping.
Custom field data automatically transfers upon lead conversion.
Explicit field mapping guarantees data persistence without data loss when leads convert.

Key Concept

Custom Lead Field Mapping during Conversion
Question 1697Question

Solaris Energy Solutions tracks sensitive client site evaluations using a custom object named Site_Inspection__c. Management mandates that field technicians must only be able to view and edit Site_Inspection__c records that they explicitly own. Additionally, regional operations managers must automatically receive access to all Site_Inspection__c records created by their direct and indirect subordinates within the managerial role structure. Which configuration should the administrator implement to enforce these access controls using Salesforce security best practices?

Show answer & explanation

Answer: Set the Default Internal Access for Site_Inspection__c to Private and ensure Grant Access Using Hierarchies remains selected.

Answer

Set the Default Internal Access for Site_Inspection__c to Private and ensure Grant Access Using Hierarchies remains selected.
Setting the Organization-Wide Default (OWD) to Private enforces the baseline restriction that users can only access records they own. Keeping Grant Access Using Hierarchies enabled ensures that managers higher in the role hierarchy automatically inherit access to records owned by their subordinates without requiring redundant sharing rules.

Step-by-Step Solution

1
Determine the baseline record access requirement
Set the Organization-Wide Default (OWD) for Site_Inspection__c to Private.
Since technicians must only view records they own, the baseline OWD must be set to Private to restrict access from all non-owner peers.
2
Configure record access propagation for higher management roles
Keep the 'Grant Access Using Hierarchies' checkbox enabled for the custom object.
For custom objects, enabling Grant Access Using Hierarchies automatically allows users higher in the role hierarchy to inherit the record access permissions of their subordinates.

Key Concept

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

A Salesforce Administrator is configuring security controls for a user profile. Which two statements accurately describe how Salesforce enforces Profile-level Login IP Ranges and Login Hours? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Users attempting to log in outside of their specified Profile Login Hours are completely restricted from logging in.; Users attempting to log in from an IP address outside of their Profile Login IP Ranges are completely blocked from logging in.

Answer

Profile-level Login Hours and Profile-level Login IP Ranges both act as strict access restrictions, completely denying login attempts made outside the designated hours or IP boundaries.
Profile-level security settings enforce strict perimeter security. Users logging in outside of their profile's configured login hours or from IP addresses outside of their profile's specified login IP ranges are completely denied access to the organization.

Step-by-Step Solution

1
Evaluate Profile Login Hours enforcement behavior
Identify that logins attempted outside the defined schedule are blocked.
Profile login hours specify the allowable timeframe for user authentication.
2
Evaluate Profile Login IP Ranges enforcement behavior
Identify that logins originating outside the specified IP ranges are hard-blocked.
Unlike org-wide Network Access rules, profile-level IP settings deny access outright rather than issuing verification codes.

Key Concept

Profile-level Login IP Ranges and Login Hours enforce absolute access denials, distinguishing them from organization-wide Network Access settings.
Estimated Time:1m 0s
Question 1699Question

A company wants to secure a custom object named Staff_Evaluation__c. The administrator must ensure that users can only access records they own, while managers above them in the role hierarchy are automatically granted access. Which TWO configuration steps should the administrator take to fulfill this requirement?

Select all that apply

Show answer & explanation

Answer: Set the Organization-Wide Default (OWD) internal access for Staff_Evaluation__c to Private.; Ensure the Grant Access Using Hierarchies checkbox remains selected for Staff_Evaluation__c.

Answer

To meet the requirements, the administrator must set the Organization-Wide Default (OWD) internal access for the custom object to Private and ensure that the Grant Access Using Hierarchies option is selected.
To restrict records so users only access what they own, the Organization-Wide Default must be set to Private. To allow managers automatic access to their subordinates' records, the Grant Access Using Hierarchies option must remain enabled.

Step-by-Step Solution

1
Determine the baseline Organization-Wide Default setting.
Setting internal access for Staff_Evaluation__c to Private restricts general access so users can only view and edit records they own.
OWD sets the most restrictive baseline level of access across the organization.
2
Verify role hierarchy access settings.
Ensuring Grant Access Using Hierarchies is checked allows superior roles in the hierarchy to access records owned by lower roles.
By default, custom objects inherit role hierarchy sharing, which opens access vertically for managers.

Key Concept

Organization-Wide Defaults establish the baseline record access, while the Role Hierarchy expands access vertically to managers when enabled.
Question 1700Question

An administrator at a logistics company needs to set up a custom picklist field on the Lead object to capture delivery preferences. The administrator must ensure that specific picklist values are shown only for specific Lead record types, and that this preference data is preserved when a Lead is converted into an Account, Contact, and Opportunity. Which two actions should the administrator take to fulfill these requirements?

Select all that apply

Show answer & explanation

Answer: Map the custom Lead field to corresponding custom fields on the Account, Contact, or Opportunity objects in Lead Conversion Field Mapping.; Configure the available picklist values individually under the Picklists for Available Values section of each Lead Record Type.

Answer

The administrator must map the custom Lead field to custom fields on the Account, Contact, or Opportunity objects, and configure the picklist values available for each Lead Record Type.
Mapping the custom lead field ensures that custom data transfers to Account, Contact, or Opportunity records upon conversion. Controlling available picklist values within each Record Type configuration restricts visible choices appropriately for different business processes.

Step-by-Step Solution

1
Configure Record Type picklist availability
Only relevant picklist values are shown to users depending on the assigned record type.
Record Types control which subset of picklist values are visible when creating or editing records.
2
Map custom Lead field for lead conversion
Custom field data from the Lead transfers seamlessly to target records during conversion.
Custom Lead field values are lost during conversion unless explicitly mapped to corresponding custom fields on Account, Contact, or Opportunity.

Key Concept

Custom Field Administration and Record Type Picklist Assignment
Estimated Time:1m 0s
PreviousPage 85 / 90Next
All practice questions — Salesforce Certified Administrator | Examkin