SALESFORCE-CERTIFIED-ADMINISTRATOR Practice Questions

The requirement is to automatically update a related record (Account) when a child record (Contact) is created with specific criteria. Process Builder is the appropriate automation tool for this scenario. It can be configured to trigger when a Contact is created, evaluate the 'Title' field, and if the condition ('Title' = 'CEO') is met, it can execute an action to update a field on the parent Account record. This cross-object field update capability is a core feature of Process Builder, making it the ideal solution for this request.

A. Quick Action: Quick Actions require manual user interaction to be initiated. The request specifies an automatic update, not a user-driven one.

B. Workflow Rule: While a Workflow Rule can update a parent record, Process Builder is a more powerful and versatile tool for cross-object automation and is generally the better choice for such requirements.

D. Validation Rule: Validation Rules are used to enforce data integrity by preventing a record from being saved if it fails to meet defined criteria. They cannot perform actions like updating other records.

1. Salesforce Help - Process Builder: "Process Builder helps you automate your business processes... A process is composed of criteria that determine when to execute an action group and immediate or scheduled actions to execute when those criteria are met. ... For example, you can create a process that updates a related record." This directly supports using Process Builder for cross-object updates. (Source: Salesforce Help, Document: "Process Builder").

2. Salesforce Help - What Can I Do with a Process?: Under the "Update Records" action type, the documentation states a process can "Update one or more records—related to the record that started the process or not—by manually entering values or by using the values from related records." This confirms its ability to update the parent Account from a Contact. (Source: Salesforce Help, Document: "Process Action Types").

3. Salesforce Help - Validation Rules: "Validation rules verify that the data a user enters in a record meets the standards you specify before the user can save the record." This reference clarifies that Validation Rules are for data verification, not for automating actions on other records. (Source: Salesforce Help, Document: "Validation Rules").

4. Trailhead - Process Automation Module, Process Builder Unit: "With Process Builder, you can... Update fields on any related record." This educational material from Salesforce explicitly highlights the capability needed to fulfill the request. (Source: Trailhead, Module: "Process Automation", Unit: "Automate Basic Business Processes with Process Builder").

To track the specific roles of contacts, such as "key stakeholders," on an opportunity, the standard Salesforce feature is Opportunity Contact Roles. The administrator must first customize the available picklist values for this object to include the required roles (D). To make this information accessible on the opportunity record, the Opportunity Contact Role related list must be added to the Opportunity page layout (E). This allows users to assign contacts to opportunities with specific roles and makes the data available for standard and custom reports.

A. Customize Campaign Member Role: This is not a standard Salesforce feature. Campaign Members have a 'Status', not a 'Role' that can be customized in this context. Campaigns are distinct from opportunities.

B. Add the Campaign Member related list to the Opportunity page layout: This would show campaign history for contacts on the opportunity, but it does not define their specific role within the opportunity itself.

C. Customize Campaign Role: This feature, known as Contact Roles on Campaigns, defines a contact's function within a marketing campaign, not a sales opportunity.

1. Salesforce Help, Set Up Opportunity Contact Roles: "To specify the part that a contact or person account plays in a deal, add contact roles to opportunities... Customize the contact roles available to your sales reps so they can best describe their contacts’ roles." This supports customizing the roles (Answer D).

2. Salesforce Help, Opportunity Contact Roles: "To see the contact roles related to an opportunity, add the Contact Roles related list to the opportunity page layouts." This supports adding the related list to the page layout for visibility (Answer E).

3. Salesforce Help, Report on Opportunity Contact Roles: "Create custom reports to find out which contact roles are most common in your deals or which contacts are most influential." This confirms that using Opportunity Contact Roles makes the information available for reporting as required by the question.

4. Salesforce Help, Add and Manage Campaign Members: This documentation details the function of Campaign Members, which is to link leads and contacts to a specific marketing campaign, confirming that it is separate from the sales opportunity context.

The requirement is to dynamically filter the available values in the 'Lead Source' picklist based on the value selected in the 'Product Category' field. This is the precise functionality of a field dependency in Salesforce. By establishing a dependency, the 'Product Category' field acts as the controlling picklist, and the 'Lead Source' field becomes the dependent picklist. The administrator can then map which specific lead source values are valid and should be displayed for each product category, ensuring data integrity and a streamlined user experience.

A. Page layouts control the visibility, read-only status, and placement of fields on a record page, but they cannot dynamically filter the values within a picklist.

C. Business processes are specifically used to manage the lifecycle stages for standard objects like Leads (Status), Opportunities (Stage), Cases (Status), and Solutions (Status), not custom fields.

D. While record types can be used to present different sets of picklist values, a field dependency is the more direct and appropriate solution for dynamic filtering on a single page.

1. Salesforce Help, Define Dependent Picklists: "A dependent picklist is a custom or multi-select picklist for which the valid values depend on the value of another field, called the controlling field... For example, you can define a dependency between a Region picklist and an Area picklist. The user must first select a region, which then filters the list of available areas to only those in the selected region." This directly maps to the question's scenario.

2. Trailhead, Data Modeling Module, Customize Picklists Unit: "Field dependencies are filters that allow you to change the contents of a picklist based on the value of another field... The controlling field drives which values are available in the dependent field." This confirms that a dependency is the correct tool for this requirement.

3. Salesforce Help, Field Dependency Considerations: "The controlling field must be a standard or custom picklist (with at least one and less than 300 values) or a checkbox field on the same record." This document outlines the technical specifications, confirming that a 'Product Category' picklist can control a 'Lead Source' picklist.

To allow the support team to manage Cases using their existing queue, two steps are required. First, the queue itself must be configured to support the Case object. By default, a queue is created for specific objects, so the administrator must edit the existing queue and add 'Case' to its list of supported objects. Second, a mechanism is needed to automatically route incoming Cases to this queue. Case Assignment Rules are the standard, declarative Salesforce feature designed specifically for this purpose, allowing administrators to define criteria that, when met, assign a Case to a specific user or queue.

A. While a flow can assign records, Case Assignment Rules are the standard, purpose-built automation tool specifically for routing new cases and are simpler to configure for this task.

D. Creating a new queue is inefficient. The existing queue can be modified to include the Case object, allowing the same team to manage both Tasks and Cases from one place.

1. Salesforce Help: Set Up Queues

In the setup process for a queue, the documentation states: "Select the objects you want to be in the queue. Users can assign records for these objects to the queue." This confirms that the Case object must be explicitly added to the existing queue's configuration. (Reference: Setup > Users > Queues > Edit Queue > Supported Objects section).

2. Salesforce Help: Set Up Assignment Rules

The official documentation specifies: "Case assignment rules automate your organization’s support processes. Use case assignment rules to automatically assign cases to users or queues based on criteria you define." This identifies assignment rules as the primary tool for routing cases to queues. (Reference: Setup > Service > Case Assignment Rules).

3. Trailhead Module: Automate Case Management

The unit "Route Cases with Queues and Assignment Rules" explicitly details this two-step process: "First, create a queue... Next, create an assignment rule to automatically add cases to the queue." This directly supports using both queue configuration and assignment rules in conjunction.

A discrepancy between dashboard and report data typically occurs for two main reasons. First, dashboards are snapshots of data from the last time they were refreshed. If the underlying data has changed since the last refresh, the dashboard will display outdated information, while the report, when run, will show the most current data. Second, dashboards can be set to run with the data visibility of a specific user (the "Running User"). If the viewing user has different data access permissions than the designated running user, the dashboard will show data based on the running user's visibility, but the underlying report will run based on the viewing user's own permissions, causing a mismatch.

A. The report needs to be refreshed.

Reports run in real-time when a user clicks on them, always showing the most current data according to the user's permissions. They do not have a separate "stale" state.

C. The current user does not have access to the report folder.

If a user lacked access to the report folder, they would receive an error and be unable to view the report at all, not see different data.

1. Salesforce Help Documentation - Why Don't My Dashboard and Report Data Match?

Reference: This article explicitly lists the two primary reasons for data mismatch. It states, "Your dashboard hasn't refreshed" and "Your dashboard is running as someone else with a different set of permissions." This directly supports answers B and D.

2. Salesforce Help Documentation - Refresh Dashboard Data

Reference: Under the section "Refresh Dashboard Data in Lightning Experience," the documentation explains, "A dashboard shows data from the last time it was refreshed." This confirms that a dashboard can display stale data if not recently refreshed, supporting answer B.

3. Salesforce Help Documentation - Choose a Running User for a Dashboard in Lightning Experience

Reference: This document details the concept of a running user. It clarifies, "The running user determines whose data is visible on the dashboard... When viewers click through to a source report, they see the data as themselves, not as the running user." This directly supports answer D as a reason for data discrepancy.

A dashboard's data visibility is determined by the "Running User." By default, a dashboard runs as the user viewing it (dynamic dashboard), respecting their personal security and sharing settings. To display enterprise-wide data to users with restricted visibility, an administrator can set a specific Running User for the dashboard. By choosing a user who has access to all opportunities (e.g., a user at the top of the role hierarchy or with the "View All Data" permission), the dashboard will render all data visible to that specified user, regardless of the viewing user's own permissions. This meets the requirement without altering the organization's sharing model.

A. Update the dashboard to folder settings to manager for the sales reps role. Folder settings control who can access, view, or edit the dashboard itself, not the data displayed within its components.

B. Add a filter to the dashboard to filter the opportunities by owner role. A dashboard filter can only narrow down the data that the running user can already see; it cannot expand their data access.

C. Build individual dashboards for profiles that need to see the enterprise results. This is inefficient and does not solve the underlying data visibility issue, as the data shown is still based on the running user's permissions.

1. Salesforce Help Documentation, "Choose a Running User in Lightning Experience": This document explicitly states, "The running user determines whose data is visible on the dashboard. If the running user is a specific user, all dashboard viewers see data based on the security settings of that user—regardless of their own personal security settings. This approach is perfect for when you want to share a dashboard with a wide group, but not open up underlying record access."

2. Salesforce Help Documentation, "Control Data Visibility in Dashboards": This guide details how dashboard data access works. It clarifies that to show a consistent, broad view of data, you should "Set a running user on the dashboard who has access to the data you want to display." This directly supports the selection of a user with enterprise-wide visibility as the running user.

3. Salesforce Help Documentation, "Dashboard Folder Sharing": This resource explains that folder permissions grant access to the dashboard asset (the container), while the data inside is governed by the running user's permissions and the organization's sharing model. This confirms that folder settings (Option A) are unrelated to data visibility within the dashboard.

This scenario requires a solution that both guides users and enforces data entry at specific points in the sales process.

1. Configure Opportunity Path (C): This provides a visual representation of the sales stages, guiding reps through the process.

2. Enable guided selling (A): As part of the Path configuration, an administrator can specify "Key Fields" and "Guidance for Success" for each stage. This prompts users to fill in critical information as they progress.

3. Use Validation Rules (B): To strictly enforce the requirement, a validation rule can prevent a user from moving to the next stage if a key field is blank. For example, a rule can fire when the StageName field is changed, checking if a corresponding field is filled out.

This combination provides both user-friendly guidance and necessary data integrity enforcement.

D. Use Flow to mark fields required:

A Flow would create a custom user interface, which is more complex than necessary. Path and Validation Rules are the standard, declarative tools for this specific requirement.

E. Mark fields required on the page layout:

This makes a field universally required on record creation and edits, regardless of the opportunity's stage. This is too restrictive and does not meet the stage-specific requirement.

---

1. Salesforce Help Documentation, "Guide Users with Path": This document details how to set up a Path. It states, "At each step of a path, you can highlight key fields and include guidance for success... A path guides your users along the steps in a process, such as working an opportunity from a new lead to a successfully closed deal." This supports the use of both Path (C) and its guided selling capabilities (A).

2. Salesforce Help Documentation, "Validation Rule Examples": This resource provides examples of validation rules. The principle shown in the "Opportunity Validation Rules" section can be applied here, such as creating a rule with the formula AND(ISCHANGED(StageName), ISBLANK(NextStep)) to require the NextStep field be populated before the stage can be changed. This supports the use of Validation Rules (B) for enforcement.

3. Salesforce Help Documentation, "Considerations for Page Layouts and Field-Level Security": This document explains that making a field required on a page layout means "users must enter a value for the field when they create or edit a record." This confirms that this option (E) is not stage-specific and is therefore incorrect for this scenario.

The inability of users to access a new report built on a custom report type can be attributed to two primary configuration issues. First, if the custom report type's status is 'In Development,' it is only visible to administrators and users with the 'Manage Custom Report Types' permission. It will not be available to standard users for running reports. Second, report visibility is controlled by folder access. If the administrator saved the report in their personal private folder ('My Personal Custom Reports'), it would not be accessible to any other users by default, regardless of their profile permissions.

B. The user’s profile is missing view access.

This is too general. While missing the 'Run Reports' permission would prevent access, the issue is specific to a new report, suggesting a problem with the report's configuration or its underlying type, not the users' fundamental permissions.

C. The org has reached its limit of custom report types.

This limit prevents the creation of new custom report types. It does not affect users' ability to access reports that have already been successfully created using an existing report type.

1. Salesforce Help, Set Up a Custom Report Type, "Deployment Status" section: "Report types in development are only visible to administrators and to users with the “Manage Custom Report Types” permission. They don’t appear in the report wizard for other users. When your custom report type is ready for general use, deploy it." This directly supports option A.

2. Salesforce Help, Report and Dashboard Folders, "Folders and Sharing" section: "Each user has a private folder for reports... named My Personal Custom Reports... By default, a user’s private folders are private, so only the user can access what’s inside." This directly supports option D.

3. Salesforce Help, User Permissions for Reports and Dashboards: This document outlines general permissions like "Run Reports" and "View Reports in Public Folders." The scenario implies a more specific issue than a lack of these base permissions, which would affect more than just this one report. This context makes option B less likely than A and D.

To enhance password security, a Salesforce administrator can configure several settings within the org's Password Policies. Setting password complexity requirements ensures that users create strong passwords with a mix of character types. Defining the number of days until expiration forces regular password changes, mitigating the risk of compromised credentials over time. Configuring the maximum invalid login attempts protects accounts from brute-force attacks by locking out users after a specified number of failed attempts. These three policies work together to enforce the creation and maintenance of secure passwords.

B. Prohibited password values: Salesforce does not have a standard feature to create a custom list of prohibited passwords (e.g., "password123," "companyname").

C. Require use of Password Manager App: Salesforce cannot enforce the use of an external application like a password manager; this is an internal company IT policy, not a configurable Salesforce setting.

1. Salesforce Help, "Set Password Policies": This document details all configurable password policies for a Salesforce org.

Password History, Length, and Complexity: This section describes the "Password complexity requirement" setting (Answer D).

Password Expiration: This section details the "User passwords expire in" setting (Answer E).

Login Lockout Settings: This section explains the "Maximum invalid login attempts" and "Lockout effective period" settings (Answer A).

2. Trailhead, Salesforce Administrator Trail, "Control Access to the Org" Module, "Set Password Policies and User Locking" Unit: This official training module outlines the key password policies an administrator can set to secure an org.

Under the "Set Password Policies" section, it explicitly lists and describes setting password expiration, complexity, and length.

Under the "Lock Users Out" section, it details the configuration for "Maximum invalid login attempts."

When a custom field with field history tracking enabled is deleted, the historical data associated with it is permanently deleted. Upon undeleting the custom field from the Recycle Bin, the field and its existing data are restored, but the field history data is not recovered. This permanent loss of historical tracking information is a critical consideration for an administrator, as it impacts auditing and data analysis capabilities for that field.

A. The field needs to be re-added to reports.

This is a true statement, but it is a reversible configuration task, whereas the loss of field history is a permanent data loss, making it a more critical consideration.

C. The field needs to be restored from the recycle bin.

This describes the action of undeleting the field, not a consequence or consideration about the state of the field after it has been restored.

D. The field needs to be re-added to page Layouts.

Similar to reports, this is a necessary but reversible administrative step. The permanent loss of historical data is a more significant and impactful consideration.

1. Salesforce Help - Manage Deleted Custom Fields:

"When you undelete a custom field, its field history data is not restored." This statement directly confirms that field history is permanently lost.

"The field is no longer on page layouts or in reports. You must manually add it back." This confirms options A and D are true but are manual steps post-restoration.

Source: Salesforce Help, Article Number 000333873, "Manage Deleted Custom Fields".

2. Salesforce Help - Considerations for Deleting Fields:

"If you delete a custom field, all the data in that field is also deleted and can’t be restored from the Recycle Bin. Before you delete a custom field, we recommend that you back up the data." While this refers to the field data itself (which is restorable within 15 days), it highlights the gravity of deletion. The associated field history is a component that is not restored.

Source: Salesforce Help, Article Number 000327118, "Considerations for Deleting Fields".