Troubleshooting practice questions

A company uses Lightning Sync to manage contacts. A sales rep updates a contact's phone number in Outlook, but the change is not appearing in Salesforce. What is the first thing the administrator should check?

Trap 1: Reset the user's password and Outlook integration.

Resetting a password and re-integrating is a drastic step that should only be taken if specific errors indicate authentication failure. It is inefficient as a first troubleshooting step and disrupts the user's workflow without verifying if the issue is a simple sync configuration setting or filter criteria.

Trap 2: Create a new validation rule to force updates.

Validation rules restrict data entry; they do not facilitate data synchronization or push updates from external systems. Adding a validation rule would not resolve the issue and could potentially block future updates, further complicating the data synchronization problem rather than identifying the root cause of the current failure.

Trap 3: Reinstall the Salesforce Outlook add-in for all users.

Reinstalling software is a time-consuming task that is rarely the solution for individual sync record failures. Troubleshooting should always begin with administrative tools that analyze the specific sync state of the record in question before moving to broad, disruptive actions like re-deploying software to the entire organization.

A
Check the user's sync status in the Lightning Sync dashboard.
The Lightning Sync dashboard is the primary location to view sync health, error logs, and connectivity status for individual users. Checking this first allows the administrator to quickly identify if the record failed to sync due to a permission issue, a configuration error, or a technical communication failure.
B
Reset the user's password and Outlook integration.
Why it fails: Resetting a password and re-integrating is a drastic step that should only be taken if specific errors indicate authentication failure. It is inefficient as a first troubleshooting step and disrupts the user's workflow without verifying if the issue is a simple sync configuration setting or filter criteria.
C
Create a new validation rule to force updates.
Why it fails: Validation rules restrict data entry; they do not facilitate data synchronization or push updates from external systems. Adding a validation rule would not resolve the issue and could potentially block future updates, further complicating the data synchronization problem rather than identifying the root cause of the current failure.
D
Reinstall the Salesforce Outlook add-in for all users.
Why it fails: Reinstalling software is a time-consuming task that is rarely the solution for individual sync record failures. Troubleshooting should always begin with administrative tools that analyze the specific sync state of the record in question before moving to broad, disruptive actions like re-deploying software to the entire organization.

Question 2hardmultiple choice

A user is unable to see a custom field on a record page, even though it is visible on the Page Layout. What is the most likely reason?

Trap 1: The field is not added to the Lightning Record Page.

If a field is not on the Lightning Record Page, the user might still see it in the 'Details' tab or standard components. However, this is less likely to be the root cause if the user can see other fields on the same page layout but not the specific field in question.

Trap 2: The user has insufficient object permissions.

If the user lacked object permissions, they would likely be unable to see the object or the records entirely, not just a single field. Since the user can see the record and the page layout, the issue is specifically related to the field's security settings rather than the object.

Trap 3: The field is a system-generated field.

System-generated fields like 'Created By' or 'Last Modified By' are standard and usually visible to all users unless specifically hidden by FLS. They are not 'hidden' by default in a way that would require special configuration just to view them, making this an unlikely cause for a custom field issue.

A
The field is not added to the Lightning Record Page.
Why it fails: If a field is not on the Lightning Record Page, the user might still see it in the 'Details' tab or standard components. However, this is less likely to be the root cause if the user can see other fields on the same page layout but not the specific field in question.
B
Field-Level Security is hidden for the user's profile.
Field-Level Security acts as a security layer that sits above the page layout. Even if a field is explicitly included in a Page Layout, the user will be unable to see or interact with the field if their profile or permission sets do not grant visibility to that specific field.
C
The user has insufficient object permissions.
Why it fails: If the user lacked object permissions, they would likely be unable to see the object or the records entirely, not just a single field. Since the user can see the record and the page layout, the issue is specifically related to the field's security settings rather than the object.
D
The field is a system-generated field.
Why it fails: System-generated fields like 'Created By' or 'Last Modified By' are standard and usually visible to all users unless specifically hidden by FLS. They are not 'hidden' by default in a way that would require special configuration just to view them, making this an unlikely cause for a custom field issue.

Question 3mediummultiple choice

An administrator needs to track the history of changes made to a custom field on a custom object. Which feature should they enable to ensure this is logged?

Trap 1: Add the 'Field Audit Trail' permission set to the user profile.

Field Audit Trail is an enterprise-grade feature used for long-term retention of historical data, which requires a specific add-on license. It is not the standard mechanism for tracking simple field changes. Enabling the standard field history tracking is sufficient for most business needs and does not require additional licenses.

Trap 2: Configure an Apex trigger to log changes to a custom object.

While an Apex trigger can log changes, it is not a declarative solution. Salesforce provides built-in, no-code functionality for this purpose via Field History Tracking. Using custom code for simple auditing increases technical debt, requires maintenance, and is unnecessary when the platform already provides this native, robust, and supported feature.

Trap 3: Create a new Report Type on the custom object.

Report types define which records and fields are available for reporting, but they do not actively track or log changes made to data. You cannot report on historical field changes unless you have first enabled Field History Tracking to capture that data into the system's underlying audit tables.

A
Enable 'Track Field History' on the object and select the specific field.
Field history tracking must be enabled at the object level first, followed by selecting the individual fields to be monitored. Once configured, Salesforce automatically logs changes to the 'History' related list. This provides a clear, documented audit trail that is accessible to authorized users for reporting and review purposes.
B
Add the 'Field Audit Trail' permission set to the user profile.
Why it fails: Field Audit Trail is an enterprise-grade feature used for long-term retention of historical data, which requires a specific add-on license. It is not the standard mechanism for tracking simple field changes. Enabling the standard field history tracking is sufficient for most business needs and does not require additional licenses.
C
Configure an Apex trigger to log changes to a custom object.
Why it fails: While an Apex trigger can log changes, it is not a declarative solution. Salesforce provides built-in, no-code functionality for this purpose via Field History Tracking. Using custom code for simple auditing increases technical debt, requires maintenance, and is unnecessary when the platform already provides this native, robust, and supported feature.
D
Create a new Report Type on the custom object.
Why it fails: Report types define which records and fields are available for reporting, but they do not actively track or log changes made to data. You cannot report on historical field changes unless you have first enabled Field History Tracking to capture that data into the system's underlying audit tables.

Question 4easymultiple choice

A user reports they cannot see the 'Activities' related list on the Opportunity page layout. What is the first thing an administrator should check?

Trap 1: Review the user's Profile object permissions.

Object permissions control the ability to create, read, edit, or delete records, but they do not control the visibility of a related list component on a specific page layout. An administrator would only need to check these if the user could not see the Opportunity records entirely.

Trap 2: Examine the Organization-Wide Defaults for Activities.

Organization-wide defaults control the baseline security and record-level access for sharing data. These settings govern whether a user can see a specific record, but they do not dictate whether a related list component exists or is visible on the UI layout for an object record page.

Trap 3: Verify the user has 'Edit' access to the Opportunity.

Edit access allows a user to modify field values on the Opportunity record itself, but it does not dictate the presence of UI elements like related lists. Even with read-only access, a user should still be able to see the related list if it is configured on the layout.

A
Review the user's Profile object permissions.
Why it fails: Object permissions control the ability to create, read, edit, or delete records, but they do not control the visibility of a related list component on a specific page layout. An administrator would only need to check these if the user could not see the Opportunity records entirely.
B
Check the Page Layout assigned to the user's profile.
The page layout determines which related lists appear on the record detail page. If the Activities related list has been removed or was never added to the assigned layout for that profile, the user will not see the section regardless of their functional permissions or access rights.
C
Examine the Organization-Wide Defaults for Activities.
Why it fails: Organization-wide defaults control the baseline security and record-level access for sharing data. These settings govern whether a user can see a specific record, but they do not dictate whether a related list component exists or is visible on the UI layout for an object record page.
D
Verify the user has 'Edit' access to the Opportunity.
Why it fails: Edit access allows a user to modify field values on the Opportunity record itself, but it does not dictate the presence of UI elements like related lists. Even with read-only access, a user should still be able to see the related list if it is configured on the layout.

Question 5mediummultiple choice

A user reports that they cannot see a custom field that was recently added to an object. What is the first thing an administrator should check?

Trap 1: Check the user's login history.

Login history tracks when and how a user accessed the system. It does not provide any information regarding the user's permissions or their ability to view specific fields on a record. Checking this would be irrelevant to troubleshooting a potential field-level security or page layout configuration problem.

Trap 2: Delete and recreate the field.

Deleting and recreating a field is a destructive and unnecessary action. It causes data loss and does not solve the root cause, which is almost always a permissions or layout visibility issue. Administrators should always investigate configuration settings before resorting to removing and recreating existing data components.

Trap 3: Change the user's role in the hierarchy.

Role hierarchy controls access to records (data sharing), not the visibility of fields on a layout. Changing the user's role will not affect which fields are visible on a record page, so this action would be completely ineffective in resolving the reported issue regarding missing custom fields.

A
Check the user's login history.
Why it fails: Login history tracks when and how a user accessed the system. It does not provide any information regarding the user's permissions or their ability to view specific fields on a record. Checking this would be irrelevant to troubleshooting a potential field-level security or page layout configuration problem.
B
Verify Field-Level Security for the user's profile.
Field-level security settings determine whether a user can see or edit a specific field. Even if a field is added to a page layout, if the user's profile does not have the 'Visible' check box enabled for that field, it will remain hidden from their view entirely.
C
Delete and recreate the field.
Why it fails: Deleting and recreating a field is a destructive and unnecessary action. It causes data loss and does not solve the root cause, which is almost always a permissions or layout visibility issue. Administrators should always investigate configuration settings before resorting to removing and recreating existing data components.
D
Change the user's role in the hierarchy.
Why it fails: Role hierarchy controls access to records (data sharing), not the visibility of fields on a layout. Changing the user's role will not affect which fields are visible on a record page, so this action would be completely ineffective in resolving the reported issue regarding missing custom fields.

Question 6mediummultiple choice

A user reports they cannot see a custom button on a record page, despite having read access. What is the most likely cause?

Trap 1: The user lacks Modify All access

Buttons do not require 'Modify All' permission to be visible. Visibility is governed by the assignment of the page layout to the user's profile. Even with standard read/write access, if the layout is not assigned correctly, the button will not appear in the user interface for that specific user.

Trap 2: The button is hidden by Field-Level Security

Field-Level Security only controls the visibility and editability of individual fields. It has no impact on the visibility of custom buttons or other user interface elements. Buttons are controlled strictly through the page layout configuration, so changing FLS would not resolve this specific issue for the user.

Trap 3: The button is blocked by the OWD setting

Organization-Wide Defaults control record-level access, not the visibility of buttons on a page layout. If the user can see the record, they have sufficient record access to potentially see the button if it were on their page layout. OWD is entirely unrelated to the presence of UI buttons.

A
The user lacks Modify All access
Why it fails: Buttons do not require 'Modify All' permission to be visible. Visibility is governed by the assignment of the page layout to the user's profile. Even with standard read/write access, if the layout is not assigned correctly, the button will not appear in the user interface for that specific user.
B
The button is not included on the assigned Page Layout
Page layouts determine the specific UI elements available to a user. If the button was added to 'Layout A' but the user is assigned 'Layout B' through their profile, the button will be invisible to them. Verifying the correct page layout assignment is essential for managing custom user interface components.
C
The button is hidden by Field-Level Security
Why it fails: Field-Level Security only controls the visibility and editability of individual fields. It has no impact on the visibility of custom buttons or other user interface elements. Buttons are controlled strictly through the page layout configuration, so changing FLS would not resolve this specific issue for the user.
D
The button is blocked by the OWD setting
Why it fails: Organization-Wide Defaults control record-level access, not the visibility of buttons on a page layout. If the user can see the record, they have sufficient record access to potentially see the button if it were on their page layout. OWD is entirely unrelated to the presence of UI buttons.

Question 7easymultiple choice

Which Salesforce tool should an administrator use to view a history of all configuration changes made in the environment?

Trap 1: Debug Log

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.

Trap 2: Login History

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.

Trap 3: Field History Tracking

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.

A
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.
B
Setup Audit Trail
The Setup Audit Trail records the last 6 months of configuration changes made to the organization. It is the primary tool for administrators to review administrative actions, such as creating fields, modifying profiles, or changing security settings, making it the definitive source for auditing setup-related configuration changes in Salesforce.
C
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.
D
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.

Question 8hardmultiple choice

A user receives the error shown in the exhibit when trying to export a specific report. What should the administrator check first?

Exhibit

Error: Insufficient privileges: You do not have the level of access necessary to perform the operation you requested. Please contact the owner of the record or your administrator if access is necessary.

Trap 1: The user's password expiration policy.

Password expiration policies would prevent the user from logging into the system entirely, not just from exporting a specific report. If the user is logged in and can navigate to the report, the authentication is fine, and the issue is restricted to the authorization level.

Trap 2: The user's daily data export limit.

Salesforce does not impose a generic 'daily export limit' that would trigger this specific 'Insufficient Privileges' error message. This message is clearly tied to record or folder access permissions, not to resource usage limits which usually trigger different error types or system notifications.

Trap 3: The Apex trigger execution limits.

Apex trigger limits do not prevent report exports. Reports are query-based and do not fire DML triggers on read. This error is strictly about the user's security profile and permissions to see the report, not about the backend code execution or resource exhaustion on the platform.

A
The user's password expiration policy.
Why it fails: Password expiration policies would prevent the user from logging into the system entirely, not just from exporting a specific report. If the user is logged in and can navigate to the report, the authentication is fine, and the issue is restricted to the authorization level.
B
The sharing permissions on the report folder.
Access to reports is governed by the folder in which they are stored. If a user does not have at least 'Viewer' access to the folder, they will be blocked from accessing the report content, regardless of their object-level permissions, making this the most logical first check.
C
The user's daily data export limit.
Why it fails: Salesforce does not impose a generic 'daily export limit' that would trigger this specific 'Insufficient Privileges' error message. This message is clearly tied to record or folder access permissions, not to resource usage limits which usually trigger different error types or system notifications.
D
The Apex trigger execution limits.
Why it fails: Apex trigger limits do not prevent report exports. Reports are query-based and do not fire DML triggers on read. This error is strictly about the user's security profile and permissions to see the report, not about the backend code execution or resource exhaustion on the platform.