Free Platform-App-Builder Practice Test Questions (2026)

Explanation:

Ursa Major Solar wants to autopopulate a field on the Asset record with the last maintenance date whenever a maintenance Work Order is closed. This is a classic use case for record-triggered automation, and the best declarative tool for this is Flow.

✅ Why Flow is the right choice:
Record-Triggered Flows can run when a Work Order is updated (e.g., status changes to "Closed").
You can add a condition to check if the Work Order type is "Maintenance".
The Flow can then find the latest maintenance Work Order for the related Asset and update the Asset's Last Maintenance Date field.
This is a declarative, scalable, and maintainable solution — no code required.

❌ Why the other options don’t work:
A. Visualforce
Visualforce is used for custom UI pages, not for automation or data updates.
B. Roll-up Summary
Roll-up summary fields only work with master-detail relationships, and Work Order → Asset is typically a lookup, not master-detail. Also, roll-ups can’t filter by status or type dynamically.
C. Apex Trigger
Apex can do this, but it’s code-heavy and harder to maintain. Since Flow supports this declaratively, Apex is unnecessary unless there are complex logic needs.

🔗 References:
Salesforce Help: Record-Triggered Flows
Trailhead: Automate Business Processes with Flow

Explanation:

Why these work
A. Lead Matching Rule + Duplicate Rule: Salesforce Duplicate Management lets you define a Lead Matching Rule (e.g., match on Email) and a Duplicate Rule that blocks new duplicates during import or UI/API creates.
B. Import Wizard with matching: The Data Import Wizard supports deduping for Leads—choose a matching option (e.g., Email or Salesforce ID) and set it to prevent creating duplicates and/or update existing where appropriate. Perfect for a ~400-record upload.

Why not the others
C. Data Loader update by Email: Data Loader’s Update requires record IDs or an External ID field; Email isn’t an external ID by default, so it won’t reliably match existing Leads.
D. “Duplicate Matching” / “Lead-to_Lead scenario”: Those aren’t real setup options. Use Matching Rules and Duplicate Rules instead.

Explanation:

This scenario tests the understanding of implicit sharing and record access inheritance in Salesforce's sharing model.

Why A is Correct:
In Salesforce, when a user is granted Read access to an Opportunity (a child object), they automatically gain Read access to the parent Account (the parent object) through a mechanism called implicit sharing. This is true even if the sharing model for the Account is Private and the user is not in the Account's territory. Manual sharing of the Opportunity with Sales Rep B grants them Read access to that specific Opportunity. This access implicitly grants them Read access to the related Account, explaining why they can see it.

Why B is Incorrect:
The scenario does not provide any information suggesting that Sales Rep B was added to the Account team. This is an assumption not supported by the facts given.

Why C is Incorrect:
Sharing Sets are a feature used with Customer Portal and High Volume Portal users to grant them access to records based on a relationship between their user account and a field on the record. They are not applicable to standard internal Salesforce users like Sales Reps.

Why D is Incorrect:
The scenario explicitly states that the Account was NOT in Sales Rep B's territory and does not mention the Account being manually shared. The question asks for the reason based on the information given, and manual sharing of the Account is not indicated.

Key Concept:
The principle at work here is that access to a child record can grant implicit read-only access to its parent record. This is a fundamental behavior of Salesforce's security model designed to ensure users can see the context of records they have access to.

Reference:
Salesforce Help - "How Sharing Access Is Calculated". The documentation explains that "Users who have access to a child record (like an Opportunity, Case, or Contact) generally need access to the parent record (like an Account). To ensure users have the access they need, Salesforce automatically grants Read access to the parent record if the user has access to the child." This is known as implicit sharing.

Explanation:

Why this is correct:
ROI for marketing spend is tracked in Salesforce via Campaigns. Create a parent campaign for the advertising buy and child campaigns for each channel/ad/creative. Salesforce rolls up child metrics to the parent via Campaign Hierarchy “statistics” fields, and you can run the built-in Campaign ROI Analysis Report to calculate ROI using costs and influenced/won opportunity amounts. This works fine with a private sharing model; no need to change org-wide defaults—just share the specific Campaigns as required.

Why the others are wrong:
A. Account Hierarchies and Roll-Up Summary fields — Account roll-ups don’t measure marketing ROI; ROI is a Campaign concept with Campaign-to-Opportunity attribution. Salesforce
B. Opportunities pipeline report — Shows stage/amount forecasts, not campaign spend vs. return.
C. Change to a public security model — Unnecessary; Campaign ROI can be measured without altering OWDs.

Reference:
Salesforce docs on Campaign Hierarchies (roll-up stats) and the Campaign ROI Analysis Report.

Explanation:

In Salesforce, when creating new automation on an object, the recommended best practice is to consolidate record-triggered automation into one Flow per object (or per trigger event, such as before/after save). This approach, often called the "One Per Object" design pattern, minimizes the number of triggers firing on the object, improves performance by reducing context switches and governor limit consumption, simplifies debugging and maintenance, and ensures predictable order of execution using features like Flow Trigger Order. It builds on the legacy Process Builder model and aligns with modern Flow-only automation strategies.
This practice helps avoid issues like unintended record updates from multiple overlapping automations, excessive CPU time, or challenges in tracing logic across disparate tools. For complex orgs, use subflows or decision elements within the single Flow to handle branching logic, rather than creating multiple independent Flows.

Why not the other options?
A. One Workflow rule per object:
Workflow Rules are a legacy automation tool (retired in Winter '24) that only support field updates, tasks, emails, and outbound messages. They cannot handle complex logic like Flows and are not recommended for new automation. Consolidating to one Workflow Rule per object was never a primary best practice, as multiple could be used but often led to order-of-execution problems.
B. One invokable process per object:
Invocable processes (autolaunched Flows) are designed for reusable sub-processes called from other Flows or Apex, not for primary record-triggered automation on an object. Limiting to one per object isn't a standard practice and doesn't address core record-change scenarios.
C. One record change process per object:
This phrasing refers to legacy Process Builder terminology (a "record-change process" is a Process Builder process triggered by record changes). While the one-per-object pattern originated here for performance reasons, Process Builder is retired (end-of-life in 2025). New automation must use Flows, making this outdated.

References:
Salesforce Architects: Record-Triggered Automation
Salesforce Help: Best Practices for Designing Processes (Note: Applies to Flow design patterns post-Process Builder retirement)

Explanation:

Why B is Correct:
The requirement is to improve the process to create Opportunity records related to an Account. A Quick Action placed on the Account page layout is the perfect solution. This allows a user to be viewing an Account and instantly create a new, related Opportunity without navigating away. The key benefit is that this action can be pre-configured to:
Pre-populate fields from the Account: The action can automatically set the Opportunity's AccountId and map any other relevant fields from the Account (e.g., Account Number, Billing Address) to the new Opportunity record using pre-defined field values.
Require input from the user: The action can present a compact form where the user must fill in the required fields that cannot be pre-populated (e.g., Close Date, Stage, Amount).

Why A is Incorrect:
Process Builder is an automation tool, not a user interface tool. A Process triggered on Opportunity update fires after a record is saved. It cannot help with the initial creation process or provide a UI for user input during creation.
Why C is Incorrect:
A Quick Action on the Opportunity object itself would be useful for updating existing Opportunities, but it is not the most efficient way to create one from a specific Account. The user would first have to navigate to the Opportunities tab, click "New," and then manually find and select the Account. This adds extra steps compared to starting from the Account record.
Why D is Incorrect:
Like option A, this uses an automation tool (Process Builder) incorrectly. A Process triggered from an Account update would fire when the Account is edited, not when a new Opportunity is being created. It cannot interact with the user to gather required input for the new Opportunity.

Reference:
Salesforce Help Article: "Create Object-Specific Actions." Quick Actions are designed specifically to streamline common tasks, like creating related records, directly from the parent record's page, making them a cornerstone of efficient UI design for App Builders.

Explanation:

Universal Containers wants sales managers to sign off when a discount falls within a specific range (20–30%). This is a classic use case for conditional approval and UI customization. Here's how each correct feature supports the requirement:

🔹 D. Approval Process
Automates the sign-off workflow based on criteria (e.g., discount between 20% and 30%).
Ensures that deals meeting the condition are routed to managers for approval.
Can be triggered from the Opportunity record using a button or action.

🔹 B. Dynamic Actions
Allows you to conditionally display the “Submit for Approval” button directly on the Opportunity record page.
Ensures that the action is only visible when the discount falls within the specified range.
Enhances user experience by keeping the page clean and context-aware.

🔍 Why the other options don’t fit:
A. Validation Rule
Prevents actions but doesn’t enable approvals or UI customization. It’s more for enforcing data integrity.
C. Schema Builder
Used for visualizing and creating object relationships, not for UI or process automation.

🔗 References:
Approval Processes – Salesforce Help
Dynamic Actions – Salesforce Admin Guide

Explanation:

Why this is correct
Only Path is stage-aware: you can define Key Fields and Guidance for Success for each Opportunity stage, so reps see exactly which fields to complete as they move through the process. Page layouts, record types, and Process Builder aren’t triggered by stage changes, so they can’t vary required fields per stage in the way the question asks.

Why the others are not ideal
A. Page layout required fields based on the current stage — Page layouts can’t change dynamically by Stage. Required fields on a layout apply at all stages.
B. Process Builder to prompt the user — Process Builder can’t present prompts/UI. (You’d need a Screen Flow, which isn’t an option here.)
C. Record types and page layouts for each stage — Record type doesn’t change automatically when Stage changes, and managing a record type per stage is brittle and not how Salesforce is designed for stage-by-stage guidance.

Explanation:

Why D is Correct:
To create reports that analyze data based on the presence or absence of a related record (i.e., "with" or "without" reports), you must first define the relationship between the objects in the reporting framework. A standard report type will not include the necessary relationships from your new custom object. A Custom Report Type allows you to explicitly define the primary object (your new custom object) and its relationship to other objects (the two different objects it looks up to). Once this report type is created, it becomes available in the report builder, enabling you to easily add filters like "with [Related Object]" or "without [Related Object]".

Why A is Incorrect:
A Row-Level Formula is used to calculate a value for each row in a report (e.g., calculating a custom ratio). It is a filter and calculation tool used within a report, but it cannot establish the object relationships needed to make "with/without" reporting possible in the first place.

Why B is Incorrect:
A Report Bucket Field is a powerful feature for grouping report values into custom categories (e.g., grouping Opportunity Amount into ranges like "Small," "Medium," "Large"). Like a formula, it is a feature used to analyze data within an existing report and does not define the underlying data structure available for reporting.

Why C is Incorrect:
Report Filters are used to narrow down the records displayed in a report after you have selected a report type. The "with" and "without" filters will only appear as options if the relationship between the objects has been defined in the report type. Without the correct Custom Report Type, these specific filters will not be available.

Reference:
Salesforce Help Article: "Create Custom Report Types." The primary purpose of a custom report type is to "define the set of records and fields available to reports based on the report type" by linking objects together via their relationships. This is a foundational concept for complex reporting in Salesforce.

Explanation:

This requirement can be met in different ways, but the question asks for the two most appropriate declarative (clicks-not-code) automation tools for this specific use case.
Why A (Escalation Rules) is Correct: Escalation Rules are explicitly designed for this exact purpose. They are built to monitor support cases and trigger actions (like sending an email alert to a user or queue) when a case remains in a certain status for a defined amount of time. You can easily set a rule that says: "If Status equals 'New' for more than 4 business hours, then send an email notification to the Director of Customer Service." Escalation Rules handle the timing and automation natively.
Why C (Process Builder) is Correct: Process Builder can also accomplish this by using a scheduled action. You could create a process that starts when a case is created or edited and meets criteria (e.g., Status is 'New'). The process would then schedule an action for 4 business hours later. That scheduled action would check if the case is still in the 'New' status and, if true, send an email alert. This is a powerful and flexible declarative approach.

Why B (Flow Builder) is Incorrect: While Flow is incredibly powerful for automating complex business processes, it is not the best tool for a time-based trigger like this on its own. You could potentially use a Scheduled-Triggered Flow, but this is a more advanced technique and is generally less straightforward for this specific use case than using a Process Builder scheduled action or an Escalation Rule.
Why D (Scheduled Apex) is Incorrect: Scheduled Apex is a programmatic (code-based) solution. While it would work (you could write a class that runs every hour to check for cases meeting these criteria), the question is aimed at a Platform App Builder who should prioritize declarative tools. Since declarative options exist that are perfectly suited for the task, Scheduled Apex is not the best choice.

Reference:
Escalation Rules: Salesforce Help Article: "Create Escalation Rules." This is the premier tool for time-based case actions.
Process Builder: Salesforce Help Article: "Use Scheduled Actions in Process Builder." This details how to use the "Schedule" node to create time-based logic.