Practice Free Plat-Admn-201 Exam Online Questions
At Cloud Kicks, when a rep needs to seek additional support help, there’s a series of actions the company wants to ensure are taken. The steps include sending an email and changing the status and owner of the case.
What should a Platform Administrator use to give the reps an easy way to make these updates?
- A . Case Assignment Rules
- B . Macros with Quick Actions
- C . Quick Text with Email Templates
- D . Autolaunched Flows with Email Alerts
B
Explanation:
To provide reps with an "easy way" to perform a repetitive sequence of manual tasks, Macros are the ideal solution. A Macro allows a user to perform multiple steps―such as changing a Case Status, reassigning the Case Owner, and sending a pre-written email―with a single click. When combined with Quick Actions, Macros can navigate the user interface, populate fields, and submit changes automatically. This significantly reduces manual data entry and ensures that the company’s required support process is followed consistently. Case Assignment Rules (Option A) and Autolaunched Flows (Option D) are fully automated and trigger on save, which might not be appropriate if the rep needs to decide when to trigger the support request. Quick Text (Option C) only assists with typing but does not automate field changes or ownership transfers.
Cloud Kicks has been seeing exponential growth and will be hiring an additional 10 sales reps and 15 support reps to its teams. The support team will need access to the Service Console to manage cases. A Platform Administrator will be assigning the users to existing custom sales and support profiles.
How should the administrator ensure the support reps have the appropriate access to the console?
- A . Enable the Service Cloud User feature license for the support reps on the User Detail page.
- B . Create a permission set for the Service Console and assign it to the support reps.
- C . Build a Service Console using Lightning App Builder for the custom service profile.
- D . Assign the Salesforce Platform User License to the support reps.
A
Explanation:
Access to the Service Console and other advanced Service Cloud features (like Entitlements or Knowledge) requires a specific Feature License called the Service Cloud User. Even if a user’s profile has the "Manage Cases" permission, they will not be able to access the specialized Console app unless the "Service Cloud User" checkbox is selected on their individual User record. This is a common administrative step when onboarding new support staff. Permission sets (Option B) grant functional permissions but cannot grant feature licenses. Assigning a "Platform User License" (Option D) would actually restrict them, as that license type does not include access to standard CRM objects like Cases or the Service Console.
Cloud Kicks is concerned that not everyone on the sales team is entering key data into accounts and opportunities that they own. Also, the team is concerned that if the key information changes, it does not get updated in Salesforce. A Platform Administrator wants to get a better understanding of their data quality and record completeness.
What should the administrator do to accomplish this?
- A . Explore AppExchange for data quality and record completeness solutions.
- B . Create a report for Accounts and Opportunities highlighting missing data.
- C . Subscribe the sales reps to a monthly report for accounts and opportunities.
- D . Configure the key fields as required fields on the page layout.
B
Explanation:
The administrator’s goal is to gain a better understanding of current data quality and record completeness issues in Accounts and Opportunities. Creating reports (or dashboards) that highlight blank or missing key fields―using filters like "Field equals (blank)" or formula fields to flag incompleteness―directly assesses the existing data by showing which records lack required information.
Why B is correct: Salesforce Trailhead modules on data quality emphasize using reports and dashboards (e.g., Account, Contact & Opportunity Data Quality Dashboard) to identify missing fields and measure completeness before implementing fixes.
Why not the others:
A: Exploring AppExchange apps is useful for advanced or ongoing solutions but skips the initial assessment step.
C: Subscribing reps to reports helps with awareness but doesn’t provide the admin with an overview of data quality.
D: Making fields required prevents future issues but doesn’t reveal current missing data or outdated records.
This approach aligns with Salesforce best practices: assess data quality first through reporting, then enforce improvements.
A Platform Administrator at Cloud Kicks has a custom picklist field on Lead, which is missing on the Contact when leads are converted.
Which two steps should the administrator take to ensure these values are populated?
- A . Update the picklist value with a validation rule.
- B . Create a custom picklist field on Contact.
- C . Map the picklist field on the Lead to the Contact.
- D . Set the picklist field to be required on the Lead object.
B, C
Explanation:
When a Lead is converted into an Account, Contact, and Opportunity, standard fields are mapped automatically. However, custom fields require manual configuration to ensure d3ata flows through the conversion process. First, the Platform Administrator must create a corresponding custom picklist field on the Contact object (Option B) with the same values as the Lead field. Second, the administrator must go to the Lead Object Manager, select "Fields & Relationships," and click Map Lead Fields (Option C). Here, the admin explicitly maps the Lead custom picklist to the newly created Contact custom picklist. Without this mapping, the data will be lost during conversion. Validation rules (Option A) and making the field required (Option D) ensure data exists on the Lead but do not facilitate the transfer of that data to the Contact.
A VP of sales needs to report on records owned by individuals in various parts of the role hierarchy. The organization-wide default is set to Private.
What should a Platform Administrator configure to achieve this?
- A . Field-Level Security
- B . Sharing Rules
- C . Permission Sets
- D . Restriction Rules
B
Explanation:
When the Organization-Wide Default (OWD) for an object is set to Private, users can only see records they own or those shared with them. While the Role Hierarchy automatically grants "upward" visibility (managers see what subordinates own), it does not naturally allow for "lateral" visibility or visibility across different branches of the hierarchy. To solve this, a Platform Administrator should use Sharing Rules. Sharing Rules allow the admin to create exceptions to the Private OWD based on record ownership or specific criteria.
For example, the admin can create an "Owner-based Sharing Rule" that shares all records owned by the "East Coast Sales" role with the VP of Sales (or a Public Group the VP belongs to). This provides a scalable way to grant the necessary visibility for reporting without making the data public to the entire company. Sharing Rules are a core security feature that ensures the right people have access to the right data while maintaining the principle of least privilege.
Northern Trail Outfitters has a new flow that automatically sets field values when a new account is created. The flow is launched by a process, but the flow is not working properly.
What should a Platform Administrator do to identify the problem?
- A . View the Setup Audit Trail and review for errors.
- B . Set up email logs and review the send error logs.
- C . Use the native debug feature in Flow Builder.
- D . Review debug logs with the flow logging level.
C
Explanation:
The most efficient and descriptive way to troubleshoot a flow is to use the native Debug feature within the Flow Builder. This tool allows the Platform Administrator to "run" the flow in a safe environment, simulating the creation or update of a record. As the flow executes, the Debugger provides a step-by-step panel showing exactly how variables were assigned, which paths were taken in "Decision" elements, and whether any "Update" or "Create" elements failed. It explicitly highlights where an error occurred and provides a detailed error message. While general Debug Logs (Option D) can capture flow information, they are much harder to read and require setting specific trace flags. The Setup Audit Trail (Option A) only shows configuration changes, not runtime errors. Email logs (Option B) are only useful if the flow is failing to send an email. The Flow Debugger is the primary tool for administrators to refine logic and fix issues before activating automation.
Universal Containers (UC) has a private sharing model for Opportunities and uses Opportunity teams. Criteria-based sharing rules are not used. A sales rep at UC leaves the company, and their user record is deactivated. The rep is later rehired in the same role. A Platform Administrator activates the old user record. The user is added to the same default Opportunity teams but is no longer able to see the same records the user worked on before leaving the company.
What is the likely cause?
- A . The stage of the opportunity records was changed to Closed Lost.
- B . The record type of the opportunity records was changed.
- C . The records were manually shared with the user.
- D . Permission sets were removed when the user was deactivated.
C
Explanation:
In Salesforce, there are different types of sharing: Managed Sharing (Role Hierarchy, Sharing Rules) and Manual Sharing. A critical behavior of the platform is that when a user is deactivated, all their Manual Shares (records shared with them by other users using the "Share" button) are automatically and permanently deleted from the system. Even if the user record is reactivated later, those manual shares do not return. Because the organization uses a "Private" model and does not use criteria-based sharing rules, the user’s previous access likely relied on manual sharing or their previous position in the hierarchy. While activating the record and adding them back to teams provides new access, the historical "one-off" shares are gone.
Options A and B are unlikely to be the cause of a total loss of visibility.
Option D is incorrect because permission sets control what a user can do, not which specific records they can see in a private sharing model.
A user at Northern Trail Outfitters is having trouble logging in to Salesforce. The user’s login history shows that this person has attempted to log in multiple times and has been locked out of the organization.
Which two steps should a Platform Administrator take to help the user log in to Salesforce?
- A . Log in as the user to unlock the user and reset the password.
- B . Use the unlock button on the user’s record detail page.
- C . Reset password on the user’s record detail page.
- D . Reset the password policies to allow the user to login.
B, C
Explanation:
When a user is locked out of Salesforce due to too many incorrect login attempts, the Platform Administrator must take specific actions on the user’s record detail page to restore access. First, the administrator should click the Unlock button19. This clears the lockout status immediately20. Second, because the user likely forgot their credentials (causing the failed attempts), the administrator should use the Reset Password button21. This sends a temporary link to the user’s email, allowing them to create a new password and log in successfully. "Logging in as the user" (Option A) is a troubleshooting tool for existing sessions but cannot bypass a lockout or change a password on the user’s behalf. Changing "Password Policies" (Option D) would affect the entire organization and is not a valid way to help a single locked-out individual.
A Platform Administrator at Universal Containers is trying to deactivate a user who has left the company but is unable to do so.
What is preventing the administrator from deactivating this user?
- A . The user is the running user of a dashboard.
- B . The user is part of an active case assignment rule.
- C . The user is part of an Opportunity team.
- D . The user is part of an Account team.
A
Explanation:
In Salesforce, certain dependencies prevent a user record from being deactivated. One of the most common blockers is if the user is the Running User of a Dashboard. Because the dashboard relies on that user’s security context to display data to others, deactivating them would break the dashboard. To resolve this, the administrator must first change the running user of the dashboard to someone else. Being part of an Opportunity Team (Option C) or Account Team (Option D) does not prevent deactivation; the user simply remains on the team but is inactive. For Assignment Rules (Option B), while you cannot delete a user in a rule, deactivation is usually permitted, though it may result in an error when the rule attempts to assign a record to the inactive user. However, the "Running User" requirement is a hard system block.
Universal Containers (UC) customers have provided feedback that their support cases are not being responded to quickly enough. UC wants to send all unassigned cases that have been open for more than 2 hours to an urgent Case queue and alert the support manager.
Which feature should a Platform Administrator configure to meet this requirement?
- A . Case Scheduled Reports
- B . Case Dashboard Refreshes
- C . Case Escalation Rules
- D . Case Assignment Rules
C
Explanation:
Case Escalation Rules are specifically designed to automate actions when a case has remained in a certain state for a defined period of time. In this scenario, the requirement involves two specific time-based triggers: moving the case after 2 hours and alerting a manager. Escalation rules allow the administrator to define "Escalation Actions" that execute when the time threshold is reached, such as "Reassign to Queue" and "Notify Manager". Case Assignment Rules (Option D) only fire when a case is first created or manually triggered, not after a time delay63. Reports (Option A) and Dashboards (Option B) provide information but do not physically move records or perform automated reassignments.