Plat-Admn-201 Practice Questions

The administrator's primary goal is to "get a better understanding of their data quality and record completeness." Creating a report is the most direct and effective method to achieve this. By building a report on the Account and Opportunity objects, the administrator can use filters to specifically identify records where key fields are blank or null. This provides a clear, quantitative analysis of the current state of the data, showing exactly which records and users are non-compliant, which is the essential first step before implementing any solution.

A. Exploring AppExchange is a step to find a solution, not to perform the initial analysis. The administrator should first assess the problem's scope using standard, built-in tools.

C. Subscribing users to a report is a notification and accountability action. This should only be done after the report has been created and the data has been analyzed by the administrator.

D. Configuring fields as required is a preventative measure that enforces data entry on new or edited records. It does not help in analyzing the completeness of existing data.

1. Trailhead, Salesforce Administrator, Data Management Module, Assess Your Data Quality Unit: This official Salesforce training module explicitly states, "A great way to get a handle on your data quality is to use reports and dashboards... Start by running reports to find records with missing information." This directly supports using reports as the initial step for understanding data completeness.

Source: Salesforce Trailhead, Module: Data Management, Unit: Assess Your Data Quality.

2. Salesforce Help, Reports, Filter Report Data: The official documentation on building reports details the use of filters. To find incomplete records, an administrator would set a filter where the key field "equals" a blank value. This is the technical implementation of the action described in the correct answer.

Source: Salesforce Help, Document ID: 000380521, "Filter Report Data," Section: "Filter by Field Value."

3. Salesforce Press, Salesforce Administrator Certification Handbook (2018), Chapter 6: Reports and Dashboards: This guide emphasizes that reports are the primary tool for data analysis and visibility. It explains that administrators use reports to "slice and dice data," which includes identifying records that do not meet specific criteria, such as having empty fields.

Source: Salesforce Administrator Certification Handbook, Chapter 6, "Creating and Customizing Reports," p. 185.

Approval process entry criteria are the specific rules that determine whether a record qualifies for submission into that process. When a user submits a record for approval, the system evaluates it against these predefined conditions. If the record meets the criteria, it enters the approval process; otherwise, it is rejected. This is the standard and most direct mechanism to ensure only the intended records are included, fulfilling the administrator's requirement to filter opportunities based on particular conditions.

B. Use Dynamic Forms to display a button.

Dynamic Forms control UI component visibility. While it can hide the submission button, it does not enforce the business logic within the approval process itself.

C. Create a screen flow.

A screen flow is a more complex solution used for guided user interactions. The standard approval process feature includes entry criteria specifically for this filtering purpose without needing a flow.

D. Add a validation rule to the opportunity.

Validation rules prevent records from being saved if they don't meet data integrity standards. They do not initiate or filter records for an approval process.

1. Salesforce Help Documentation, "Create an Approval Process": In the approval process setup wizard, Step 3 is "Specify Entry Criteria." The documentation states, "The entry criteria determine which records are subject to this approval process. You can also set the filter criteria..." This directly confirms that entry criteria are the designated feature for this purpose. (Salesforce Help, Article ID: 000385177, "Create an Approval Process").

2. Salesforce Trailhead, "Approval Processes" Module, "Set Up an Approval Process" Unit: This official training module explains the components of an approval process. It details the step for setting entry criteria: "For the entry criteria, let’s specify that only opportunities with an amount greater than or equal to $5,000 are submitted for approval." This provides a practical example of using entry criteria to filter records.

3. Salesforce Platform App Builder Certification Guide (Official Vendor Material): The guide outlines the capabilities of approval processes, emphasizing that entry criteria are evaluated when a record is submitted to determine if it should enter the process. It distinguishes this from other automation tools like flows or validation rules. (See sections on Process Automation and Data Validation).

Flow Builder is the appropriate automation tool for this requirement. A record-triggered flow can be configured to execute when an Opportunity record is updated and the 'Stage' field is set to 'Won'. This flow can then automatically get all related Opportunity Product records and update their respective discount fields with the value from the parent Opportunity's discount field. This solution is fully automated and eliminates the need for manual user intervention, directly addressing the sales manager's request.

A. Approval Process: An approval process is designed to submit a record for approval from one or more users. It is not the primary tool for automating data updates on related records.

B. Formula Field: A formula field is read-only and calculates a value dynamically. It cannot be used to update a field value on a related child record.

D. Prebuilt Macro: A macro automates a sequence of user interface actions but must be manually initiated by a user. It does not run automatically in the background based on a record change.

---

1. Salesforce Help, "Flow Builder": This document outlines the capabilities of Flow Builder as the primary tool for declarative process automation. It supports complex logic, including fetching and updating related records, which is central to the scenario. (Refer to the "What Can I Build with Flow Builder?" section).

2. Salesforce Help, "Record-Triggered Flow Considerations": This documentation specifies that a record-triggered flow "starts when a record is created or updated" and can be used to "update any record, but it’s easiest to update the triggering record or records that are related to it." This directly validates using a flow to update child Opportunity Products when a parent Opportunity is updated.

3. Salesforce Help, "What Is an Approval Process?": This source defines an approval process as a tool that "automates how records are approved in Salesforce." Its purpose is managing approval sequences, not automating field propagation to related records.

4. Salesforce Help, "Formulas": The documentation on formula fields implicitly confirms their read-only nature. They are designed to compute and display values, not to perform Data Manipulation Language (DML) operations like updating other records. (Refer to the "What is a Formula?" section).

5. Salesforce Help, "Set Up and Use Macros": This document states, "A macro is a set of instructions that tells the system how to complete a task... Users run a macro to complete these steps automatically." This confirms that macros are not fully automated backend processes and require user interaction to run.

When a field is removed from a page layout, it is not deleted but returned to the fields palette within the page layout editor. The most direct and common method to restore it is to re-open the page layout editor and drag the field from the palette back onto the layout.

Alternatively, in an environment with formal change control processes, the entire page layout component can be restored to its correct state by deploying it from a sandbox environment using a change set or other metadata deployment tools. This overwrites the modified layout in the target organization with the version from the sandbox.

A. Clone the layout from a different profile and use save as.

Cloning creates an entirely new page layout. It does not fix the existing one and would require reassigning the new layout to all relevant profiles.

C. Restore from the recycle bin within 15 days.

The Recycle Bin is for deleted records and certain metadata components, not for configuration changes made within a component like a page layout.

1. Salesforce Help, "Customize Page Layouts with the Enhanced Page Layout Editor": This document details the functionality of the page layout editor. It states, "The palette at the top of the screen contains the basic elements—fields, buttons, links, and related lists—that you can add and arrange on your page layout... To add an element, drag it from the palette onto the page layout." This directly supports option D.

2. Salesforce Help, "Components Available in Change Sets": This official documentation lists the metadata types that can be deployed between Salesforce orgs. "Page Layout" is listed as a supported component type, confirming that a page layout can be deployed from a sandbox to another org, which supports the method described in option B.

3. Salesforce Trailhead, "Customize a Page Layout": In the "Customize a Page Layout" unit of the "Lightning App Builder" module, the process of adding fields is described: "From the Fields section in the palette, drag the fields you want to add...". This reinforces that fields not on the layout reside in the palette, ready to be added back.

This requirement involves an automated process that triggers upon a specific record update (Opportunity Stage = 'Closed Won') and then performs actions on other related records (updating other open Opportunities on the same Account). Flow Builder is the designated Salesforce tool for creating such complex, record-triggered automations. An administrator can build a record-triggered flow that fires when an Opportunity is updated to 'Closed Won'. The flow would then get the Account ID, find all other related Opportunities that are not yet closed, and update their stage to 'Closed Lost'. This aligns perfectly with the capabilities of Flow Builder.

B. Outbound Message: This is used for sending data to an external system via a SOAP API call and cannot be used to update records within Salesforce.

C. Flow Orchestration: This is designed for coordinating complex, multi-step, multi-user processes and is overkill for this straightforward, background automation requirement.

D. Quick Action: This requires manual user initiation (e.g., clicking a button). The requirement is for a fully automated process that runs in the background upon saving a record.

1. Salesforce Help Documentation, "Record-Triggered Flows": "A record-triggered flow runs when a record is created or updated... Record-triggered flows can update any record in the database..." This source confirms that a flow can be triggered by a record update and can subsequently update other records, which is the core of the requirement. (Salesforce Help, "Flow Builder," Record-Triggered Flows section).

2. Salesforce Architects, "Architect's Guide to Record-Triggered Automation on Salesforce": This guide provides a decision framework for choosing automation tools. For a process that needs to execute after a record is saved and needs to access and update other records, the guide directs administrators to use a record-triggered flow. It explicitly states, "For all other 'after-save' use cases, we recommend Flow." (Salesforce Architects, "Record-Triggered Automation Decision Guide," After-Save Flow path).

3. Trailhead, "Flow Builder" Module, "Record-Triggered Flows" Unit: "Use record-triggered flows to automate your business processes when a record is created or updated... For example, when an opportunity's stage is updated to Closed Won, create a renewal opportunity." This example demonstrates a similar use case of triggering a process from an Opportunity stage change, validating the use of Flow Builder for the scenario. (Trailhead, "Flow Builder" Module).

The business requirement is to run an automated process on a recurring schedule ("once a week") to perform an action on a set of records (count open cases for Accounts). A Schedule-Triggered Flow is the only flow type designed specifically for this purpose. It initiates automatically at a specified time and frequency, operating on a batch of records without needing a user action or a record change event to trigger it. This directly aligns with the requirement for a weekly, automated background job.

B. Record triggered flow: This flow executes only in response to a record being created, updated, or deleted, not on a predefined time-based schedule.

C. Autolaunched flow: This flow type lacks an inherent trigger and must be invoked by another process, such as Apex, a button, or another flow, not by a schedule.

D. Automation event triggered flow: This is not a standard flow type. Platform Event-triggered flows run when a platform event message is received, which is event-driven, not time-based.

1. Salesforce Help Documentation, "Flow Types":

Reference: Under the section for "Schedule-Triggered Flow," the documentation states, "Launches at a specified time and frequency for each record in a batch. This autolaunched flow runs in the background." This directly supports the use case of a weekly scheduled job.

Reference: The description for "Record-Triggered Flow" confirms it "Launches when a record is created, updated, or deleted," making it unsuitable for a scheduled task.

2. Salesforce Trailhead, "Record-Triggered Flows" Module, "Choose the Right Flow for the Job" Unit:

Reference: This unit provides a decision guide. For the question "When do you need the flow to run?", the path for "On a recurring schedule" explicitly leads to "Schedule-Triggered Flow."

3. Salesforce Help Documentation, "Schedule-Triggered Flow Considerations":

Reference: This document outlines the use case: "A schedule-triggered flow starts at a specified time and frequency for a batch of records. Configure the schedule in the Start element of your autolaunched flow. Schedule-triggered flows are ideal for jobs that require repetitive work, such as nightly reports or weekly data cleansing." This aligns perfectly with the "once a week" requirement.

To allow users to share dashboard components in Chatter, an administrator must first enable feed tracking for the Dashboard object. This administrative setting activates the functionality that allows users to follow specific dashboards and post snapshots of individual components to the dashboard's feed or other Chatter feeds. Without enabling feed tracking for dashboards, the option to share components via Chatter is not available to users. This is the direct, system-level change required to fulfill management's request.

A. Enable reporting snapshots: Reporting snapshots are used for capturing and trending historical report data over time by saving it to a custom object, not for sharing components in Chatter.

B. Select Download Chart on the component: This is a user action to save a component as an image file. It is a manual workaround, not the integrated sharing functionality the administrator needs to enable.

C. Set View Dashboard As to the dashboard viewer: This setting controls the data visibility of the dashboard based on the running user's permissions. It does not enable or disable Chatter sharing capabilities.

1. Salesforce Help, "Post Snapshots of Dashboard Components": This document explicitly states the prerequisite for this functionality. Under the "Post a component snapshot to a feed" section, it notes, "To post dashboard components, feed tracking must be enabled for dashboards." This directly supports the correct answer.

2. Salesforce Help, "Enable Feed Tracking for Objects": This guide details the administrative process. It instructs, "From Setup, in the Quick Find box, enter Feed Tracking, and then select Feed Tracking. Select the object [e.g., Dashboards]... Select Enable Feed Tracking." This confirms that enabling feed tracking is the specific administrative task required.

3. Salesforce Help, "Track Historical Data with Reporting Snapshots": This document defines Reporting Snapshots as a tool to "report on historical data" by mapping "fields from a source report to fields on a custom object at scheduled times." This clearly distinguishes its purpose from real-time Chatter sharing.

4. Salesforce Help, "Choose Who People See a Dashboard As in Lightning Experience": This resource explains that the "View Dashboard As" setting determines whose data access rights are used to display the dashboard data. Its function is purely for data visibility and security, not for enabling collaboration features like Chatter posts.

Delegated administrators are designed to handle specific administrative tasks without having full administrative privileges. A key limitation is their inability to modify org-wide security configurations. While they can assign or remove existing permission sets for users within their delegated groups, they cannot create new permission sets or modify the permissions contained within existing ones. This restriction ensures that the fundamental security and access model of the organization remains under the control of full System Administrators, preventing unintended escalation of privileges or changes to core data access policies.

A. Delegated administrators can perform both user unlocking and password resets for the users within their specified scope of administration.

B. Delegated administrators are explicitly prohibited from modifying permissions, including field-level security, on standard Salesforce objects.

D. A primary function of a delegated administrator is user management, which includes the ability to assign users to specified profiles.

1. Salesforce Help Documentation, "Delegate Administrative Duties": This official document outlines the specific capabilities and limitations of delegated administrators. In the section detailing what delegated administrators cannot do, it explicitly states they "can’t... Create or modify profiles and permission sets." It also confirms they can "Reset passwords for users," "Unlock users," and "Assign users to specified profiles."

Source: Salesforce Help, "Delegate Administrative Duties," table titled "Delegated administrators can’t:".

2. Salesforce Security Guide, "User Management Administration": This guide details security-related administrative tasks. It reinforces the principle that delegated administration is for managing users within a defined scope, not for altering foundational security structures like permission sets or profiles.

Source: Salesforce Security Guide, PDF version, Chapter on "Controlling Access to Your Org," section on Delegated Administration.

3. Trailhead by Salesforce, "Delegate Administrative Tasks" Module: This official training module provides hands-on learning about delegated administration. The unit "Set Up Delegated Administrators" clarifies the boundaries of their permissions, noting that they cannot modify permission sets, which would alter the org's security model.

Source: Trailhead, "User Management" Trail, "Delegate Administrative Tasks" Module.

The most efficient and standard method to meet this requirement is by using the built-in Component Visibility feature on the screen element itself. Within the Flow Builder, any screen component, such as a picklist, can be configured to display only when specific conditions are met. The administrator can set the visibility of the 'Specific Search Engine' picklist to be dependent on the 'Lead Source' field's value being "Search Engine". This is a declarative setting on a single screen, requires no additional flow elements, and directly addresses both the show/hide and conditional requirement aspects of the task.

A. "Conditional filter" is not the correct terminology for screen component visibility. Filters are typically used in data elements like 'Get Records' to query for specific data, not to control UI display.

B. Assignment elements are used to assign values to variables, not to control the visibility of screen components. This approach would be inefficient, likely requiring a Decision element and separate screens.

D. Validation rules are used to enforce data integrity before a record is saved. They cannot dynamically show or hide a component on a flow screen; they only display an error message if criteria are not met.

1. Salesforce Help Documentation, "Flow Screen Input Component: Set Component Visibility": This document explicitly describes the feature. It states, "Define conditions to dynamically show or hide the component on the screen... When you set component visibility, the flow evaluates the conditions at run time. If the conditions are met, the component appears on the screen." This directly supports the use of conditional visibility as described in option C.

Source: Salesforce Help, Flow Builder Core Concepts, "Flow Screen Input Component".

2. Salesforce Help Documentation, "Flow Element: Screen": This document outlines the capabilities of the Screen element in a flow. It details how to add various components and configure their properties, including conditional visibility, which is the most direct way to handle the scenario.

Source: Salesforce Help, Flow Elements, "Flow Element: Screen".

3. Salesforce Help Documentation, "Validation Rules": This resource clarifies the purpose of validation rules. It states, "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 confirms that their function is data validation upon saving, not controlling UI visibility within a flow screen.

Source: Salesforce Help, Data Quality, "Validation Rules".

To limit the kinds of reports users can create, a Platform Administrator should use the "Hide Report Types" functionality. This administrative tool allows the administrator to control which report types are visible to users when they initiate the report creation process. By hiding specific report types from user profiles or permission sets, the administrator effectively prevents those users from building new reports based on those underlying data structures. This directly addresses the requirement of limiting the types of reports that can be created, without affecting existing reports.

B. Report Folder Sharing: This controls access permissions (view, edit, manage) for folders containing existing, saved reports. It does not prevent users from creating new reports of any type.

C. Standard Report Types: This refers to the predefined report types included with the platform. It is a category of report types, not an administrative tool for restricting their use.

D. Joined Report: This is a specific report format that combines multiple report blocks. It is a feature for data analysis, not a tool for controlling report creation access.

1. Salesforce Help, "Hide Report Types": "You can hide report types from the Create Report page. Hiding a report type doesn't delete it or any reports based on it. Instead, it removes the report type from view in the report type selection page so users can't create new reports with it." This document explicitly describes the function of hiding report types to control creation.

2. Salesforce Help, "Standard Report Types": This document lists and describes the out-of-the-box report types, establishing it as a category of features rather than a control mechanism.

3. Salesforce Help, "Share a Report or Dashboard Folder": This guide details how to set access levels for folders, confirming that folder sharing is about controlling access to saved reports, not limiting the creation of new ones. Section: "Folder Sharing in Lightning Experience".