Free Salesforce-Platform-Administrator Practice Test Questions 2026

Explanation:

A record-triggered Flow is the right solution because it can run automatically when an Opportunity is updated to Closed Won and then find and update related records—in this case, all other open Opportunities on the same Account—to Closed Lost. Build an after-save record-triggered flow on Opportunity with entry criteria like ISCHANGED(StageName) = TRUE and StageName = "Closed Won". In the flow, use Get Records (or a fast lookup) to retrieve all sibling Opportunities where AccountId = $Record.AccountId and Id != $Record.Id and IsClosed = FALSE. Loop through that collection (or use Update Records on a collection without a loop if you prefer) to set StageName = "Closed Lost" (and, if required by your process, a Loss Reason value), then perform a single bulk update. This approach is fully declarative, respects FLS, handles bulk operations (e.g., multiple opportunities closed by data load), and keeps all changes in one transaction so they either succeed together or roll back together. Add guardrails such as checking for primary opportunity flags or record types if only certain deals should force-close their siblings, and consider enabling “Run Asynchronously” (via a scheduled path or an async path) if you anticipate very large sibling sets to reduce save-time latency.

Why the others are not correct

A. Quick Action
Quick Actions require a user to click something and act on a single record. They don’t automatically trigger when an Opportunity is closed won, nor do they naturally update other related records in the background. You’d still need automation (like Flow) behind the scenes to cascade the change.

B. Workflow Rule
Workflow Rules (legacy) can’t mass update related records like sibling Opportunities; they primarily update the same record or send emails/outbound messages. Even with field updates, you can’t iterate other Opportunities on the account and set them to Closed Lost. Salesforce also recommends Flow over Workflow for new automation.

D. Outbound Message
Outbound Messages send data to external endpoints (SOAP) and do not update Salesforce records by themselves. They’re for integration, not for enforcing internal cross-record business rules like closing sibling Opportunities.

Practical admin tip:
Use an after-save flow to avoid recursion issues when you’re updating other records and to ensure the triggering Opportunity’s state is final. Add criteria to skip updates if the sibling is already closed, and include meaningful loss reason defaults so reports remain consistent.

Explanation:

Email-to-Case automatically creates Cases from incoming customer emails sent to designated routing addresses (e.g., support@company.com). To route these Cases to the correct queue (e.g., based on subject keywords, sender domain, or priority):
In Email-to-Case settings (Setup > Service > Email-to-Case):
Create multiple Routing Addresses (each with a unique email).
For each address, specify a Queue as the default owner.
Optionally, enable Assignment Rules integration: Link to active Case Assignment Rules for dynamic routing (e.g., criteria like "Subject contains 'Billing'" → Queue: Billing Support).
Emails to a specific address auto-create Cases owned by its queue—no extra automation needed for basic routing.
This is built-in, declarative, and ensures immediate queue assignment on creation.

Why Not the Others?

A. Utilize a flow to identify the correct queue and assign the case:
Possible (Record-Triggered Flow on Case create to update OwnerId), but unnecessary overhead. Email-to-Case handles routing natively; Flows add complexity for post-creation updates.
B. Use a custom email services to set the owner of the case upon creation:
Custom Email Services (Apex-based) process inbound emails for custom logic/objects. Overkill and code-required; standard Email-to-Case is no-code and queue-focused.
C. Create an Escalation Rules to send cases to the correct queue:
Escalation Rules monitor open Cases for SLA breaches and reassign/notify—not for initial routing on email receipt.

Step-by-Step Setup:
Enable Email-to-Case: Setup > Email-to-Case > Enable (Premium/On-Demand versions).
Create Queues: Setup > Queues > New (add Cases as supported object).
Add Routing Addresses: Setup > Email-to-Case > Routing Addresses > New.
Enter email, select Queue, verify address.
Optional: Activate Case Assignment Rules for criteria-based routing within a queue/address.
Test: Send email to routing address > Verify Case in queue's list view.

References:
Salesforce Help: Set Up Email-to-Case (routing and queues).
Trailhead: Service Cloud Basics (Email-to-Case automation).

For the SP25 exam, note:
Use verified domains for routing emails. Premium Email-to-Case adds threading/auto-responses. Combine with Auto-Response Rules for acknowledgments. For advanced routing (e.g., Entitlements), layer Assignment Rules.

Explanation:

Cloud Kicks needs a self-service way for customers to submit Cases directly from the public homepage without logging in. Web-to-Case generates an HTML form (via Setup > Web-to-Case > Generate) that captures details (e.g., Subject, Description, Contact info) and auto-creates Cases in Salesforce.
Embed the form code on the homepage (e.g., in a web page or Experience Cloud site).
Customize fields, add CAPTCHA for spam prevention, and set default values (e.g., Origin = Web).
Route via Assignment Rules to queues/owners; trigger Auto-Response emails for confirmation.
Supports up to 5,000 Cases/day (standard limit); no licenses needed for customers.

This is no-code, public-facing, and ideal for external submission.

Why Not the Others?
A. SMSResponse: Not a feature. SMS-to-Case exists in some contexts, but not for web forms.
C. Email-to-Case: Customers email a routing address; Cases create from inbox. No web form—requires email client, not homepage integration.
D. Omni-Channel: Routes work (chat, cases) to agents post-creation. Not for customer submission.

References:
Salesforce Help: Set Up Web-to-Case.
Trailhead: Service Cloud Basics (self-service channels).

For SP25 exam, note:
Web-to-Case uses verified domains; combine with reCAPTCHA v2. For branded portals, use Experience Cloud Sites with Case object. Test form submission in sandbox.

Explanation:

The requirement is to display a screen flow for the sales team to add new leads. There are multiple standard ways to launch a screen flow in the Lightning Experience.

Let's evaluate the options:

A. Create a tab and add the screen flow to the page. This is a correct method. An administrator can create a custom Lightning tab of type "Flow." This provides a dedicated tab in the navigation bar that, when clicked, launches the flow in its own window. This is a clean and simple way to give users direct access to the flow.
B. Use a flow element and add the screen flow to the record page. This is another correct and highly contextual method. The administrator can use the Lightning App Builder to add the "Flow" component to any Lightning record page (like the Home page or an App page). This embeds the flow directly on the page, making it easily accessible without needing a separate tab.

Why the other options are incorrect:

C. Add the flow in the utility bar of the console. This is a specific feature for Service Cloud Console applications. Since the scenario involves the sales team adding leads, and does not mention a console app, this is not the standard or intended method for a general sales team.
D. Install an app from the AppExchange. This is completely unrelated. The AppExchange is for third-party applications. The flow has already been built internally; no external app is needed to display it.

Reference:
Salesforce Help: "Add a Flow to a Lightning Page"
Salesforce Help: "Create a Custom Lightning Tab for a Flow"

Explanation:

✅ Correct Answer: C. Create three record types, each with 2 page layouts
Universal Containers has:
Three separate lines of business → each needs its own Record Type
Two user groups (Sales and Service) → each needs a different Page Layout per Record Type
This means:
3 Record Types (one for each line of business)
2 Page Layouts per Record Type (one for Sales, one for Service)
Total: 6 Page Layouts
This configuration allows the administrator to:
Show business-specific fields using Record Types
Tailor user-specific layouts using Page Layouts assigned via Profiles

❌ Why the other options are incorrect:

A. Create two record types, each with 3 page layouts
This only covers 2 lines of business, not all 3. It also assumes 3 layouts per type, which doesn’t align with the 2 user groups.
B. Create one record type with six page layouts
One record type cannot differentiate between three distinct business processes. Record Types are essential for controlling picklists, layouts, and logic per business line.
D. Create six record types, each with 1 page layout
This overcomplicates the setup. You’d need to create redundant record types just to handle layout differences, which is inefficient and harder to maintain.

References:
Record Types Overview – Salesforce Help
Customize Page Layouts – Salesforce Help
Trailhead: Customize Record Types and Page Layouts

Explanation:

A validation rule is the appropriate declarative tool to enforce data quality and business requirements automatically when a user attempts to save a record.

D. Create a validation rule that ensures Showing Date contains a date within the current year.
A validation rule can use a formula to compare the entered Showing Date with the current year using functions like YEAR(TODAY()) and YEAR(Showing_Date__c). The rule would fire (displaying an error message) if the year entered is not the current year, thereby preventing the record from being saved incorrectly.

A. Sync the users' Showing Calendar to Salesforce and filter it to only look at this year.
This is a usability/viewing preference and doesn't prevent invalid data entry into the core database field.

B. Create a report that shows any Showing Dates not scheduled in the current year to the updated.
Reports are reactive tools used for data analysis and cleanup after the fact. They do not proactively prevent bad data from being saved.

C. Add Help Text so the user knows to only add a Showing Date within the current year.
Help text is a good guidance tool, but it relies on the user reading and following instructions. It does not enforce the rule (users can still enter an incorrect date).

Explanation:

Flows in Salesforce must be activated to run and perform actions like creating records. An inactive flow (saved but not activated) won't execute, even if triggered correctly via a button, Quick Action, Process Builder, or record update. This is a common oversight—saving creates a version, but only the active version processes interviews and DML operations (e.g., Create Records element).
Check/fix: In Flow Builder > Open the flow > Click "Activate" (or "Save As" new version and activate).
Production flows can have multiple versions; only one is active at a time.
Debug: Run in Flow Builder Debug mode (simulates execution); check Setup > Flows > Paused & Failed Flow Interviews for errors.

Why Not the Others?

A. The flow is read only: Incorrect.
Flows aren't "read only"—this might confuse with object permissions or sharing, but flows have versions (editable until activated). Read-only access (via permissions) prevents editing, not execution.
C. The flow URL is deactivated: Incorrect.
Autolaunched/Screen Flows don't rely on "URLs" for triggers (unlike classic Visualforce). URLs are for manual runs (e.g., /flow/MyFlow); deactivation isn't a feature—invalid URLs just error.
D. The flow trigger is missing: Partially misleading.
For Record-Triggered Flows, missing entry conditions or trigger settings (e.g., no "When" create/update) could skip runs. But the question implies a general flow (likely Screen/Autolaunched for record creation). Even with a trigger, inactive flows never fire.

References:
Salesforce Help: Activate or Deactivate a Flow.
Trailhead: Flow Builder Basics (activation and versioning).

Explanation:

B. Flow Builder (Screen Flow for guided submission)
To simplify how users submit expense reports, the best front-end, no-code tool is a Screen Flow built in Flow Builder. A screen flow lets you guide users step-by-step through required inputs (dates, categories, amounts, receipts), apply conditional visibility to show only relevant fields (e.g., show “Mileage” fields when Type = Travel), and perform inline validations before save. You can also prefill user/context data (current user, default cost center), calculate totals or policy thresholds with Assignment and Formula elements, and then create or update the Expense Report record and its related lines in one seamless experience. Because it runs right in Lightning (record page, app page, utility bar, or quick action), a screen flow dramatically reduces errors and back-and-forth, ensuring submissions are complete and policy-compliant at the point of entry.

C. Approval Process (routing and authorization)
Once the expense report is created, an Approval Process is the standard Salesforce mechanism to route the record to the correct approvers (e.g., manager → finance → director, or dynamic approvers based on amount, department, or policy). Approval steps can send notifications, lock the record during review, and run entry, approval, and final actions—such as stamping an approved status, updating a reimbursement date, or notifying AP. This provides a consistent, auditable workflow that satisfies the “routing and authorizations” requirement with minimal maintenance and without custom code.

Why the others are not correct

A. Validation Rule
Validation rules are excellent for enforcing field-level constraints (e.g., “Amount must be > 0” or “Receipt required when Amount ≥ 100”), but they don’t provide a guided UI, nor do they perform routing or authorization. They are complementary to a flow (you may still use them to enforce key policies), yet they cannot, by themselves, deliver the end-to-end submission and approval experience the business is requesting.

D. Quick Action
A Quick Action can provide a launch point (e.g., a button) and simple create/update forms, but it lacks the depth of multi-step guidance, conditional logic, calculations, and record orchestration that a Screen Flow offers. You can certainly use a Quick Action to launch the screen flow, but the action alone won’t handle the guided process or the multi-level authorization—those are delivered by Flow Builder and the Approval Process, respectively.

Practical admin pattern:
Build a Screen Flow for data capture (with conditional visibility and calculations), save the Expense Report, and then submit for approval automatically from the flow (or expose a “Submit” action that kicks off the Approval Process). Add targeted Validation Rules only for universal guardrails, not as the primary workflow engine.

Explanation:

The relationship type dictates available functionality:

Master-Detail relationships tightly couple parent and child records. A key feature available only in master-detail relationships is the Roll-Up Summary field, which aggregates data (like count, sum, min, max) from the child records to the parent record.
Lookup relationships are looser connections and do not support roll-up summary fields on the master (parent) object.

When an administrator attempts to convert a Master-Detail relationship to a Lookup relationship, Salesforce checks for the existence of any Roll-Up Summary fields on the master object. If any exist, the conversion will be blocked because those fields would become invalid once the strict master-detail link is removed.

Why other scenarios are incorrect:

A. A junction object is required to support the lookup:
A junction object (linking two master-detail relationships) is unrelated to the ability to downgrade an existing master-detail to a lookup.
B. The lookup field in all the records contains a value:
The "lookup field" is the child object's reference field to the parent. While it might be good practice to ensure all child records have a value before changing the relationship type if required later, it's not a technical blocker for the type conversion itself.
C. The Look-Up field is required for Saving Records:
The "Required" property of a field can be adjusted before or after the conversion; it doesn't prevent the fundamental change of relationship type in the way that dependent features (like roll-up summaries) do.

Explanation:

This requirement involves three distinct business processes, each needing a unique set of stages and fields. The correct configuration must account for both the sales stages (Sales Process) and the user interface with specific fields (Record Type and Page Layout).

Let's evaluate the options:

C. Create three sales processes. Create three record types and three page layouts. This is the correct configuration.
Three Sales Processes: Each sales process defines a unique set of Opportunity Stages. The two sales teams will have different sales pipelines (e.g., "Residential Sales" and "Commercial Sales" stages), and the Services team will have a completely different set of stages for tracking installation (e.g., "Scheduled," "In Progress," "Completed").
Three Record Types: Each record type is assigned one sales process. This links the business logic (the stages) to the record. The record type also controls which page layouts and picklist values are available.
Three Page Layouts: Each team (and thus, each record type) needs a different page layout to display the specific fields relevant to their process. The sales teams need product and pricing fields, while the services team needs scheduling and resource fields.

Why the other options are incorrect:

A. Create three sales processes. Create three record types and one page layout. This is incorrect because a single page layout cannot display three different sets of fields. All users would see the same fields, which does not meet the requirement.

B. Create one sales process. Create three record types and three page layouts. This is incorrect because a single sales process means all three teams would be forced to use the same set of stages. The Services team cannot use sales-oriented stages like "Prospecting" or "Closed Won" to track an installation.

D. Create one sales process. Create one record type and three page layouts. This is the most incorrect. With only one record type, you cannot assign different sales processes or control which page layout is shown to which team. All users would have the same stages and could potentially see any of the three layouts, leading to confusion.

Reference:
Salesforce Help: "Sales Processes & Record Types"

Explanation:

To export a precise slice of Opportunity data—Closed Won deals from the last 90 days, with exactly the fields Opportunity Name, Id, CloseDate, and Amount—the most appropriate tool is Data Loader using an Export operation with a SOQL query. Data Loader lets you (1) filter by conditions (e.g., StageName = 'Closed Won' AND CloseDate = LAST_90_DAYS), (2) select only the fields you want (e.g., SELECT Id, Name, CloseDate, Amount FROM Opportunity WHERE …), and (3) output a clean CSV ready for analysis or sharing. This gives you a targeted, minimal dataset without extraneous columns or older records, and it’s repeatable if the business wants the same extract again later. You can run it on demand or script it (via the command-line interface) if the export needs to be scheduled.

Why the other options are not correct

A/C. Data Export Wizard
The Data Export Wizard (weekly/monthly backup export) is designed for bulk backups of whole objects, not narrow, field-level extracts with date filters. While you can choose which objects to include, it does not let you specify a WHERE clause (like last 90 days) or pick a small field subset; instead, it exports all fields of the selected object, often across multiple CSVs in a ZIP. That’s overkill for a tightly scoped, analytical export and requires downstream cleanup to remove unwanted columns and records.

B. Data Import Wizard
The Data Import Wizard is for loading data into Salesforce (Leads, Accounts/Contacts, custom objects, etc.), not for exporting it. It doesn’t provide an export function or SOQL filtering, so it can’t produce the requested file.

Practical admin tip:
In Data Loader’s Export tab, pick Opportunity, switch to SOQL mode, and use:
SELECT Id, Name, CloseDate, Amount FROM Opportunity WHERE StageName = 'Closed Won' AND CloseDate = LAST_90_DAYS Save the results as CSV, and you’ll have exactly the four requested columns for the correct time window.

Explanation:

In Salesforce Flow Builder, the available elements in the Toolbox depend on the flow type, particularly for Record-Triggered Flows:
Before-save Record-Triggered Flows run before the record is committed to the database. They are optimized for fast updates without additional queries/DML and are limited to logic elements only: Assignment (set field values), Decision (branching), Get Records (limited querying), and Loop (iterating collections). Screen elements, Create/Update/Delete Records, or actions like Email Alerts are unavailable to maintain performance and avoid side effects pre-save.

This matches the exact four elements described, as before-save flows focus on manipulating the triggering record ($Record) directly.
To confirm/edit:
Open the flow > Check the Start element: "Run the flow: Before the record is saved."
If needed, clone and change to after-save for more elements (e.g., screens, external calls).

Why Not the Others?

A. The flow is a screen flow: Incorrect. Screen Flows include Screen elements (inputs, displays) plus logic—far more than four. Screens are for user interaction, not limited here.
B. The version of the flow is inactive: Incorrect. Inactive versions are fully editable with all elements available for their type. Activation status doesn't restrict the Toolbox.
D. The version of the flow is activated: Incorrect. Activated flows are read-only (can't edit), but you can "Save As" a new version to edit with full Toolbox. The question states the flow is open for editing, so activation isn't the cause.

References:
Salesforce Help: Record-Triggered Flows Considerations (before vs. after-save limitations).
Trailhead: Record-Triggered Flows (element availability by trigger timing).