Salesforce-Platform-Administrator Practice Test Questions

Explanation:

To launch a simple discount calculator screen when a Sales Rep clicks a button on an Opportunity, the administrator should use Flow Builder, specifically a Screen Flow. Screen Flows allow you to create interactive user interfaces that can be embedded in Lightning pages or launched via custom buttons or actions.

In this scenario, the administrator can:

Create a Screen Flow with input fields for discount parameters (e.g., original price, discount percentage).
Add logic to calculate the discounted amount using Assignment elements.
Display the result on the same screen or a follow-up screen.
Add the flow to the Opportunity page using a Quick Action, Flow component, or custom button.

This approach provides a declarative, no-code solution that’s highly customizable and user-friendly. It’s ideal for building lightweight calculators, data entry forms, or guided workflows.

❌ Incorrect Answers:
B. Workflow Rule
Workflow Rules are used for background automation, such as sending emails or updating fields when criteria are met. They do not support user interfaces or interactive screens. Therefore, they cannot be used to launch a calculator screen.
C. Platform Event
Platform Events are used for event-driven architecture, typically to communicate between systems or trigger actions asynchronously. They are not designed for building UI components or launching screens. This option is too complex and unrelated to the requirement.
D. Process Builder
Process Builder is used to automate backend processes like record updates or task creation. It does not support screen flows or user interaction. It cannot be triggered by a button click to launch a UI component.

References:
Flow Builder Overview – Salesforce Help
Screen Flows – Salesforce Help
Add a Flow to a Lightning Page – Salesforce Help

Explanation:

Why these are correct

A. Profile Assignment:
To make a record type available to users, you must assign it to their profiles (or permission sets). This also lets you set a default record type per profile so users see it in the picklist (or skip the selection screen if only one is available).
D. Page Layout Assignment:
After enabling the record type for profiles, you assign the page layout that should display for that record type + profile combination. This is how you show the right fields/sections when users create/view Customer Warranty cases.

Why the others are not

B. Role Assignment:
Roles control data visibility (who can see which records), not which record types a user can choose or which layouts they see.
C. App Manager Assignment:
App assignments control which Lightning apps users can access. They don’t expose record types or determine page layouts.

Exam tip:
Record type visibility = Profile (or Permission Set). What the page looks like for that record type = Page Layout Assignment (by Profile + Record Type).

Explanation:

Why C is correct
On a Screen Flow, each component (e.g., each question/input) has Set Component Visibility rules. You can show/hide a component based on values the user enters on the same screen (or variables you pass in), so only the relevant question appears while the other stays hidden. This keeps a single screen, minimizes clicks, and avoids duplicating screens/flows. Salesforce+1

Why the others are not:
A. Use a new version of the flow for each scenario — Not needed
Multiple flow versions or separate flows complicate maintenance and don’t address dynamic UI needs on the same screen. Conditional visibility solves this within one flow screen.
B. Use a Decision element and a new screen — Overkill for same-screen logic
Decision elements branch between screens. They work, but you’d end up with extra screens and navigation when the requirement is specifically “two questions on the same screen.” Conditional visibility is the intended feature for same-screen show/hide.
D. Use branching in the flow screen — Not a feature
“Branching” happens with Decision elements in the flow path, not inside a screen. To dynamically show/hide components on the same screen, you use Set Component Visibility, not branching.

Exam tip:
When you read “show/hide fields on the same screen,” think Screen Flow + Set Component Visibility (a.k.a. conditional visibility).

Explanation:

Support agents need quick access to documentation (articles) and similar cases directly from the Case record page to resolve issues faster. Salesforce Knowledge (part of Service Cloud) provides this via the Knowledge Component on Lightning record pages:

Enable Knowledge in Setup > Feature Settings > Service > Knowledge.
Create Articles (rich text, FAQs, how-tos) with versions, translations, and attachments.
Use Data Categories to organize articles (e.g., by Product, Issue Type) for targeted visibility.
Add the Knowledge Lightning Component to the Case page (via Lightning App Builder):

Searches Knowledge base.
Suggests similar articles/cases based on Case fields (Subject, Description) using Lightning Knowledge or Einstein Article Recommendations.
Agents can search, view, attach articles to Cases, or link related records—all without leaving the page.

For similar cases:
Enable "Suggested Articles" or use Einstein Case Classification to surface past Cases.

This is efficient, contextual, and embedded in the workflow.

Why Not the Others?
A. Create a custom object to capture popular case resolutions: Overkill and manual. Custom objects require building relationships, searches, and UI—agents would still hunt manually. Knowledge has built-in search/recommendations.
B. Use an interview flow to capture Case details: Flows guide data entry (e.g., Screen Flows for wizards), but don't provide resource lookup. This helps creation, not resolution.
C. Direct users to Global Search to look for similar cases: Global Search works org-wide, but it's not page-specific or proactive. Agents leave the Case, lose context, and get broad results—no curated articles or auto-suggestions.

Step-by-Step Setup:
Enable Knowledge (requires Service Cloud licenses).
Set up Data Category Groups (Setup > Data Categories).
Author articles and assign categories.
Customize search: Promote articles, enable rich text.
Edit Case Lightning Page > Add "Knowledge" component (sidebar or tab).
Train agents: Search from Case, attach articles (auto-closes or updates Case).

References:
Salesforce Help: Set Up Salesforce Knowledge.
Salesforce Help: Add Knowledge to Record Pages.
Trailhead: Salesforce Knowledge Basics module (articles, categories, and agent efficiency).

Explanation:

At the most fundamental level, a user's ability to see and interact with a standard object like Account is governed by their Profile. The Profile contains Object Permissions (like "Read," "Create," "Edit," "Delete") that grant the baseline access.

Let's evaluate the options:

B. Users’ profile requires permission to the Account object. This is the correct answer. If the new users' Profile does not have at least Read permission for the Account object, they will be completely unable to see the Accounts tab, list views, or any individual Account records, regardless of any other settings. This is the first thing an administrator should check.

Why the other options are incorrect:

A. Users’ profile requires a sharing rule for Accounts. Sharing rules are a sharing mechanism, not a permissions mechanism. They extend access to records that users already have permission to see via their Profile. If the Profile does not grant access to the object itself, a sharing rule is irrelevant and will not help.
C. Users’ roles are low on the role hierarchy. The role hierarchy primarily controls record-level visibility for records a user is already permitted to see. It allows users higher in the hierarchy to see all records owned by users below them. Like sharing rules, it does not grant the object-level permissions that are missing here.
D. Organization-wide defaults are set to private. OWDs set the baseline sharing level for records. If OWD for Accounts is "Private," it means users can only see accounts they own, accounts shared with them via teams, or accounts shared via sharing rules. However, even with private OWD, a user with the correct Profile permissions can still see the Account tab and the accounts they personally own. The problem described is a complete inability to access the object, which points to a Profile issue, not a sharing issue.

Reference:
Salesforce Help: "Object Permissions" - This explains that object-level CRED (Create, Read, Edit, Delete) permissions are managed in the user's Profile or Permission Set.

Explanation:

B. Test Drive in a Trailhead Playground
A Test Drive is a feature offered by many AppExchange partners that gives an administrator or user instant, read-only access to a pre-configured Salesforce organization with the app already installed. This allows a quick, risk-free way to review the app's core functionality, user interface, and general fit with their business needs without installing anything in their own org. While the option mentions a "Trailhead Playground," a Test Drive typically uses a specially configured environment created by the partner, which fulfills the same goal of a quick, separate trial.

C. Install in a sandbox
Installing an app in a recently refreshed Sandbox is the best practice for thorough testing. A Sandbox is an isolated copy of the production organization, including its configurations, metadata, and often its data. This allows the administrator to:
Test the app's full functionality (including creating, editing, and deleting records).
Ensure it interacts correctly with Cloud Kicks' existing customizations, validation rules, and other installed apps.
Perform comprehensive user acceptance testing (UAT) with key employees before deployment to the live Production environment.

❌ Incorrect Answers
A. Test Drive in a production org.
While "Test Drive" is a valid option, it is never performed in a production org. Test Drives are designed to be entirely separate, read-only environments to ensure zero risk to the live data and configuration. No installation occurs in the production org during a Test Drive.
D. Check edition compatibility
While checking edition compatibility is an essential pre-requisite before even considering an app, it is a verification step and not an option for trying out or testing the app's functionality to ensure it meets business needs. Checking compatibility only confirms it can be installed, not that it should be used.

Explanation:

✅ Correct Answer: B. Send email notifications
Case Escalation Rules in Salesforce are designed to automatically escalate unresolved cases based on predefined criteria — such as elapsed time, priority, or status. One of the most common actions configured in an escalation rule is to send email notifications to support managers, case owners, or escalation teams when a case meets escalation conditions.
This ensures that:
Critical cases receive timely attention
Stakeholders are alerted without manual intervention
Service-level agreements (SLAs) are upheld

Administrators can define email templates, recipients, and escalation timing in the rule setup.

✅ Correct Answer: D. Re-assign the Case
Another key action in escalation rules is reassigning the case to a different user or queue. This is useful when:

The original case owner hasn’t responded within the expected timeframe
The case needs to be escalated to a higher-tier support team
A specialized agent or manager should take over

Reassignment helps ensure that cases are handled efficiently and by the appropriate personnel, improving resolution time and customer satisfaction.

❌ Incorrect Answers:
A. Re-open the Case
Escalation rules do not reopen closed cases. They are designed to act on open cases that are not progressing as expected. Reopening a case would require a separate automation (e.g., Flow or Apex), and is not a native action within escalation rules.
C. Change the Case Priority
While changing priority might be a logical escalation step, escalation rules do not directly support field updates like changing priority. To achieve this, administrators would need to use Workflow Rules, Process Builder, or Flow in conjunction with escalation logic. Therefore, this is not a valid action within escalation rule configuration itself.

References:
Set Up Case Escalation Rules – Salesforce Help
Trailhead: Automate Case Management

Explanation:

The two options the administrator should use to help the support team are Add Case to the existing queue as available object and Use assignment rules to set the queue as the owner of the case (combined with a flow or manual assignment).

The correct options based on common Salesforce exam answers and functionality are:

B. Use assignment rules to set the queue as the owner of the case.
Once the queue is set up to support Cases, an automation mechanism is needed to route the new cases to this queue. The standard, declarative way to automatically assign incoming cases to queues based on specific criteria is using Case Assignment Rules (or a Record-Triggered Flow, which is often preferred in modern Salesforce). This rule automatically sets the queue as the owner of the case upon creation, making it visible to all queue members.
C. Add Case to the existing queue as available object.
Salesforce queues can manage multiple standard and custom objects simultaneously, including both Tasks and Cases. The administrator simply needs to edit the existing queue in Setup, navigate to the "Supported Objects" section, and add the Case object to the list of selected objects.

Why other options are less appropriate:

A. Configure a flow to assign the cases to the queue.
While a Flow can be used to assign cases to a queue, assignment rules are the traditional and often simpler declarative method for standard case routing. Both are valid automation tools, but the combination of editing the queue itself and using assignment rules is a common exam answer pairing for this specific requirement.
D. Create a new queue and add Cases as an available object.
Creating a new queue is unnecessary if the team already uses an existing queue for tasks and wants to manage both types of records in one place (which a single queue supports).

Explanation:

To create a one-to-many relationship between two objects while maintaining limited access to child records, the administrator should use a Lookup field. A Lookup relationship links one object to another without enforcing strict ownership or access dependencies. This means:

The parent record can exist independently of the child.
The child record can have its own sharing settings and visibility.
You can control access to child records using organization-wide defaults, sharing rules, or manual sharing.

This flexibility makes Lookup relationships ideal when you need to relate objects but preserve granular control over record-level access, especially for child records.
For example, if you relate Accounts to Custom Support Tickets, and you want support agents to see only the tickets they own or are assigned to — not all tickets under an Account — a Lookup field is the right choice.

❌ Incorrect Answers:

A. Roll-up summary
A Roll-up Summary field is not a relationship type. It’s a field on the parent object that aggregates values (like COUNT, SUM, MIN, MAX) from related child records — but it only works with Master-Detail relationships. It cannot be used to define relationships or control access.

B. Master-detail field
Master-Detail relationships create a tight coupling between parent and child:
The child record inherits the parent’s ownership and sharing settings
If the parent is deleted, the child is also deleted
You cannot control access to child records independently
This violates the requirement for limited access to child records, making it unsuitable for this scenario.

C. Cross Object formula
Cross-object formulas allow you to reference fields from related objects in formulas, but they do not define relationships between objects. They are useful for displaying data, not for structuring object relationships or controlling access.

References:
Relationship Fields – Salesforce Help
Lookup vs Master-Detail – Trailhead
Control Access to Records – Salesforce Help

Explanation:

Why these are correct

B. Outbound Message
To initiate (push) an expense report from Salesforce to an external HR system without code, configure an Outbound Message. When the record meets your criteria (e.g., “Expense Report = Submitted”), Salesforce sends a SOAP message with selected field values to the HR system’s endpoint. You can attach outbound messages to approval steps or other automations.
C. Approval Process
The requirement says the process must be reviewed by managers and directors. That’s exactly what an Approval Process does—route a record through sequential approvals (manager → director), with step-level actions (notify, update, send outbound message, etc.).

Why the others are not

A. QuickAction
A Quick Action can launch a screen/flow or create/update a record, but it doesn’t handle multi-step review/approval or directly integrate to external systems by itself. You still need the Approval Process for routing and an Outbound Message (or integration) to reach the HR system.
D. Email Alert Action
Email alerts are useful notifications but don’t initiate integration to an external HR system and don’t enforce approval routing. They’re supplementary to (not a substitute for) Outbound Messages and Approval Processes.

Exam tip:
When you see “send data to an external system” + “multi-level approvals,” think Outbound Message (integration) + Approval Process (routing).