Configuration and Setup practice questions

Set OWD to Public Read Only

Why it fails: Public Read Only grants all users access to view every record in the object regardless of ownership. This setting fails to meet the requirement of restricting access to only the user's records and their subordinates, as it effectively opens data visibility to the entire organization, violating the principle of least privilege.

Enable Grant Access Using Hierarchies

Why it fails: Enabling this setting is necessary for the role hierarchy to function, but it is not sufficient on its own. If OWD is set to Public Read/Write, access is already open to everyone. You must first restrict the base access level via OWD before the hierarchy can effectively filter record visibility.

Create a Permission Set for view access

Why it fails: Permission Sets are designed to extend functional access, such as viewing specific tabs or executing apex classes. They cannot be used to restrict record-level visibility in the manner required here. Record visibility is governed by OWD, sharing rules, and roles, not by profile or permission set-based object permissions.

Organization-Wide Defaults

Why it fails: OWD controls access to records at the object level, not at the field level. While OWD dictates if a user can see the record itself, it does not provide granular control over individual fields. Therefore, OWD is not a direct requirement for viewing a field if the record is accessible.

Sharing Rules

Why it fails: Sharing rules are used to open up access to records beyond the OWD baseline. They do not have the capability to restrict or grant access to individual fields. Field-level access is managed strictly through profiles and permission sets, making sharing rules irrelevant for this specific field-level visibility requirement.

Record Type configuration

Why it fails: Record Types determine the page layouts and picklist values available to a user, but they do not control field visibility permissions. While they affect what a user sees on a layout, they are not a security feature for restricting access to data within a specific field on a record.

Sharing Rules

Why it fails: Sharing Rules are used for granting record access at the security level, not for displaying lists of records to users. While they determine which records a user can see, they do not provide the UI interface for sorting and filtering that a List View offers for daily user productivity tasks.

Record Types

Why it fails: Record Types are used to assign different page layouts, business processes, and picklist values to different records. They do not have the capability to filter or display collections of records for user access. They are structural components for managing data variations, not for viewing subsets of data for end-users.

Reports

Why it fails: Reports are designed for aggregating and analyzing data over time, often used for management dashboards. While they can display lists of records, they are not intended for daily record management and editing in the way List Views are. List Views are optimized for immediate, operational interaction with record sets.

Profile Names

Why it fails: Profile names are managed at the organizational level and are not specific to a single custom object. You can adjust permissions for an object within a profile, but you cannot define or rename the profile itself based on the needs of a single object. This is a system-wide setting.

Org-Wide Defaults

Why it fails: Organization-Wide Defaults are security settings that apply to the entire object and are configured in the Security section of Setup. They are not defined as part of the object's specific customization wizard. While you configure them for the object, they are a broader security concept, not an object-specific component.

In the Setup Audit Trail

Why it fails: The Setup Audit Trail tracks changes to the configuration, not to the data values within records. While it is an audit tool, it is for administrative changes. To track field value changes, one must use the specific Field History Tracking feature located on the object definition page in the Object Manager.

In the Field's metadata settings

Why it fails: While you select fields to track within the Field History Tracking setup, the feature itself is enabled at the object level first. You cannot enable it from within the individual field definition window. The object-level configuration is the mandatory first step before you can specify which fields to monitor.

In the Profile settings

Why it fails: Profile settings manage user permissions and access rights. They do not have any control over data auditing or tracking field history. Attempting to enable tracking here would be ineffective, as the auditing engine is integrated directly into the object's data handling logic, not the user's security and permission profile.

Organization-Wide Defaults

Why it fails: Organization-Wide Defaults determine the baseline level of access for records within Salesforce, managing data visibility across different user groups. They do not control or restrict the network environment or IP addresses from which users can authenticate into the platform, making them irrelevant to network-level security requirements.

Trusted IP Ranges in Network Access

Why it fails: Trusted IP Ranges in the Network Access settings are used to exempt users from multi-factor authentication or security challenges when logging in. They do not prevent users from accessing the system from other locations; they merely bypass the secondary verification step, which is insufficient for strict network-based access control.

Role Hierarchy restrictions

Why it fails: The Role Hierarchy is designed to manage record-level access based on the organizational structure, allowing users to view records owned by subordinates. It has no capability to restrict or influence the physical location or network IP address from which a user logs into their Salesforce user account.

The user is not the owner of the record.

Why it fails: Record ownership is not a prerequisite for editing fields on a record. Salesforce security allows users to edit records they do not own, provided they possess the appropriate object-level 'Edit' permissions and the relevant field-level security settings allow for write access to the specific fields being modified.

The record is currently locked by an Approval Process.

Why it fails: While an approval process can lock a record, the typical error message displayed would specifically state that the record is locked for editing. An 'Insufficient Privileges' error is almost exclusively linked to permission settings like profile, permission sets, or sharing rules rather than the state of the record.

The user has a lower role in the hierarchy.

Why it fails: The role hierarchy grants record access but does not define the ability to edit specific fields. Being lower in the hierarchy might restrict access to records owned by superiors, but it does not dictate the capability to edit field values if the profile permissions for the object are granted.

Page Layouts

Why it fails: Page Layouts manage the organization of fields on desktop records. While they do affect the 'Details' section on mobile devices, they are not the primary configuration tool for the mobile-specific highlights panel and condensed field display, which is the specific purpose of Compact Layouts in the Salesforce mobile environment.

Lightning App Builder

Why it fails: The Lightning App Builder is used to design the structure of Lightning pages, including components and regions. While it dictates the overall page structure, it does not manage the specific fields shown in the record's highlights header, which is handled by the Compact Layouts feature assigned to each object.

Mobile Publisher

Why it fails: Mobile Publisher is a tool used to create branded versions of the Salesforce mobile app for distribution. It is not a configuration setting for individual object layouts or fields. Its purpose is to handle branding and app store deployment, not to control how records are displayed within the application interface.

To filter picklist values based on the user's role.

Why it fails: Record types do not filter picklist values based on the user's role; they define the available values for all profiles assigned to that record type. Filtering based on role is better achieved through other means, such as dynamic forms or specific page layouts, not through the record type configuration.

To automatically change the owner of the record.

Why it fails: Record types have no mechanism to change the owner of a record automatically. Assignment rules are the correct feature to handle the routing and ownership of records based on criteria, and record types remain completely independent of the automated record assignment logic used within the Salesforce system configuration.

To change the standard object's API name.

Why it fails: Record types do not modify the API name of standard objects. Standard object names and their associated API names are permanent features of the platform. Attempting to rename them would break existing integrations and code, so this functionality is not available through any configuration within the object manager settings.

Workflow Rule

Why it fails: Workflow rules are designed for automation, such as sending emails or updating fields. They cannot prevent a user from saving a record if the required data is missing, meaning they cannot force the completion of a survey during the record update process, making them unsuitable for this validation requirement.

Assignment Rule

Why it fails: Assignment rules are used to automatically route leads or cases to specific users or queues based on predefined criteria. They do not have any functionality related to validating data input or preventing record saves, so they cannot assist in forcing a survey to be completed during the save process.

Approval Process

Why it fails: While an approval process could require a survey to be submitted for approval, it is an indirect way to handle the requirement. A validation rule provides a faster, more integrated experience for the user by stopping the save immediately if data is missing, rather than relying on a separate submission process.

Frozen users can be removed from public groups.

Why it fails: Frozen users cannot be removed from public groups, queues, or other record-sharing associations. They remain part of these structures, which is why freezing is typically a temporary measure. To fully remove them from sharing hierarchies and groups, the administrator must deactivate the user and reassign their records accordingly.

Freezing a user removes them from the role hierarchy.

Why it fails: Freezing a user does not remove them from the role hierarchy. The user record remains in its position within the hierarchy, which can lead to continued visibility of child records if the user was a manager. This is why it is only a temporary stop-gap rather than a full account decommissioning.

The Sharing Settings for the Account object.

Why it fails: Sharing settings determine record-level access for the parent object. However, the presence of a 'New' button is controlled by object-level permissions and page layout configuration, not by record sharing rules. Adjusting sharing settings will not resolve issues related to UI button availability on a related list.

The Organization-Wide Defaults for the Opportunity object.

Why it fails: Organization-Wide Defaults control baseline record visibility across the organization. They do not dictate whether a user can initiate the creation of a new record via a related list button. Changing these settings would impact record access, not the ability to interact with the user interface components.

The Search Layout configuration for the Account object.

Why it fails: Search layouts define which fields appear in search results and lookup dialogs. They have no impact on the action buttons displayed within standard related lists on a record detail page. Configuring these layouts will not restore the missing 'New' button or resolve the user's access-related functional requirement.

Modifying the Page Layout editor to add fields to the page.

Why it fails: The Page Layout editor is primarily used to manage fields, buttons, and related lists for Classic pages and some legacy components. While it influences what shows up in the 'Record Details' component on Lightning pages, it does not define the overall structural layout of the Lightning page itself.

Configuring the Compact Layout for header fields.

Why it fails: Compact layouts control which fields appear in the highlights panel at the top of a record page. They do not allow for structural configuration of the page body, such as adding components, columns, or changing the arrangement of the main content area in the Lightning App Builder.

Adjusting the Search Layout settings.

Why it fails: Search layouts are specific to search results and lookup dialogs. They do not control the layout or component arrangement of a record detail page. Attempting to use search layouts for this purpose would be ineffective as they have no functional overlap with Lightning record page configuration requirements.

Enable Chatter tracking

Why it fails: Enabling Chatter tracking is an optional feature that allows users to follow records and receive updates in their feeds. It is not a functional requirement for basic access, object visibility, or the ability to create records on a custom object.

Create a standard Page Layout

Why it fails: Salesforce automatically creates a default page layout when a custom object is generated. While customizing the layout is often necessary for usability, it is not a prerequisite for making the object visible or accessible to users within the application.

Add the object to the Global Search

Why it fails: Custom objects are automatically indexed for search once created. While administrators can configure search layouts, the object does not require manual registration to appear in search results. This is not a prerequisite for basic object availability or user access.

Use a workflow rule with a field update to set the Renewal_Date__c field.

Why it fails: Workflow rules are deprecated for new development and cannot perform date calculations directly. A field update can set a static value or use a formula, but workflow rules are less efficient than record-triggered flows and may not be supported in the future. Salesforce recommends using Flow for new automation.

Create a validation rule that requires the field to be filled when the stage is Closed Won.

Why it fails: A validation rule can enforce that the field is not blank, but it cannot automatically populate the field with a calculated date. It would require users to manually enter the date, which is not efficient and prone to error. This does not meet the requirement of automatic population.

Create a formula field that calculates Close Date + 30.

Why it fails: A formula field would always display a date 30 days after the Close Date, but it cannot be set to only populate when the opportunity is closed won. It would also update if the Close Date changes, which may not be desired. Additionally, formula fields are not stored and cannot be used in reporting snapshots or other features that require a static value.

Use a workflow rule with a field update to set Location__c from Account.BillingCity.

Why it fails: Workflow rules can perform field updates, but they cannot reference fields from a related parent record directly in the field update formula. They also run after the record is saved, not before, so they cannot set the field on creation in the same transaction. This approach would not reliably populate the field at creation.

Create a formula field on Project__c that references Account.BillingCity.

Why it fails: A formula field cannot be used to populate a field that users can edit or that needs to be stored. Formula fields are calculated at runtime and are not writable. They also cannot be used to enforce that users cannot change a field, because they are read-only by nature. This does not meet the requirement to populate and then lock the field.

Create a validation rule that prevents users from editing Location__c if it is not blank.

Why it fails: A validation rule can prevent users from editing a field if certain conditions are met, but it would also block the automated flow from setting the field if the rule is not carefully written. More importantly, it does not populate the field initially; it only restricts changes. The requirement includes automatic population.

Assign a permission set that removes the 'Modify All' permission on opportunities for non-Sales Manager users.

Why it fails: Removing Modify All would restrict record access, not stage values. Non-Sales Manager users still need to edit opportunities up to Negotiation/Review, so revoking broader edit permissions would break their normal workflow and does not address the specific stage restriction required.

Configure field-level security on the Stage field to make it read-only for non-Sales Manager profiles.

Why it fails: Field-level security controls whether a user can edit a field at all, not the specific values they can select. Making the Stage field read-only would prevent all sales users from changing stages, including allowed transitions, so it does not meet the requirement of restricting only the Closed Won stage.

Use a record type and page layout combination to hide the Closed Won stage from non-Sales Manager users.

Why it fails: Page layouts and record types control which fields and picklist values appear on the user interface, but they do not prevent a user from changing the stage through the API, data loader, or inline editing. They are presentation-layer controls, not enforcement, so they cannot reliably restrict the stage value.

Create a validation rule that prevents Support users from viewing the field.

Why it fails: Validation rules are used to prevent saving invalid data; they cannot control field visibility. They cannot hide a field from users. Therefore, this approach does not meet the requirement to hide the field from the Support profile.

Set the field-level security for the Support profile to 'Read-Only' or 'Hidden'.

Why it fails: Field-level security can be set to 'Visible' or 'Hidden' for profiles. 'Read-Only' is not a field-level security setting; it is a page layout setting. Field-level security controls whether a user can see the field at all, regardless of page layout. To hide the field, the administrator should set field-level security to 'Hidden' for the Support profile.

Remove the field from the Contact page layout assigned to the Support profile.

Why it fails: Removing a field from a page layout only hides it from the user interface; it does not prevent users from accessing the field through reports, list views, or the API. The requirement is to ensure the Support profile cannot view the field, which implies a security control, not just a UI change.

Assign a permission set that grants 'Read' and 'Edit' on Opportunities.

Why it fails: The profile already grants Read and Edit on Opportunities. Adding a permission set with the same access is redundant and does not address the need for record-level access to all Opportunities. It also does not prevent deletion, which is already handled by the profile.

Assign a permission set that grants 'Modify All' on Opportunities.

Why it fails: Modify All grants read, create, edit, and delete access, which would allow deletion—directly violating the requirement. Permission sets can grant additional access, but they cannot restrict access granted by the profile. This option would grant too much privilege.

Set the organization-wide default for Opportunities to 'Public Read Only'.

Why it fails: Public Read Only would allow the user to view all Opportunities but not edit them. The user needs edit access to all Opportunities, so this OWD setting alone is insufficient. It would require a sharing rule to grant edit access, but the OWD itself does not meet the requirement.

Debug Log

Why it fails: Debug Logs are used to track specific execution paths, database queries, and code performance for troubleshooting Apex, processes, or flows. They are not intended for tracking configuration changes made in the Setup menu. They provide granular technical insight rather than an administrative audit trail of organizational configuration modifications.

Login History

Why it fails: The Login History feature tracks information about user login attempts, including status, source IP, and authentication method. It does not record any configuration changes made by administrators within the setup interface. It is purely focused on user access and authentication security metrics rather than administrative metadata changes.

Field History Tracking

Why it fails: Field History Tracking is used to monitor changes to specific data values within records on an object. It does not track changes to the configuration of the Salesforce instance itself, such as adding a new custom field or changing a security profile. It is a data-level, not configuration-level, tracking mechanism.