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

Explanation:

Why: Change sets move metadata only (reports, fields, objects, etc.), not the underlying record data. If your UAT org doesn’t have sample Opportunity (or related) data—or if sharing/visibility differs—the report will return no rows.

Why the others are wrong:
A. Reports don’t require SFDX to deploy.
B. Reports don’t need to be manually re-created; they can be deployed via change sets.
C. Change sets can’t include data at all.

Reference:
Salesforce docs on Change Sets note they deploy customizations (metadata), not data (records).

Explanation:

The sales team at Universal Containers receives approximately 800 leads daily from the marketing team, with the potential for duplicates since the list is sent in full each morning without prior deduplication. The Data Import Wizard is the most suitable tool for importing these leads into Salesforce while preventing duplicates:

B. Data Import Wizard:
The Data Import Wizard is a browser-based, declarative tool designed for importing up to 50,000 records (well above the 800 daily limit) and includes a deduplication feature. It can match leads based on standard fields like Email, Lead Owner, or Company Name (configurable during import) and prevent duplicate entries by either skipping existing records or updating them. This tool is user-friendly, requires no additional setup beyond enabling it in Setup, and aligns with the app builder’s focus on low-code solutions.

Why not the other options?
A. Dataloaderio:
"Dataloaderio" appears to be a typo or misreference (possibly intended as "Data Loader IO," a third-party tool). Data Loader IO is a cloud-based data loader with deduplication capabilities, but it is not a native Salesforce tool and requires a subscription, additional configuration, and potentially more technical expertise, making it less ideal for this scenario.
C. Data Loader:
Data Loader is a desktop tool for bulk imports (up to 5 million records) and supports deduplication via upsert operations with external IDs or matching fields. However, it requires more technical setup (e.g., CSV configuration, command-line or UI use) and is better suited for larger, more complex imports or automated processes, not the daily 800-lead task manageable by the Wizard.
D. Manual entry:
Manually entering 800 leads daily is impractical due to time constraints and human error risk. It lacks automation or deduplication features, making it unsuitable for this volume and requirement.

Implementation Notes:
Enable the Data Import Wizard via Setup > Data Import Wizard.
Upload the lead CSV file, select "Leads" as the object, and choose the deduplication option (e.g., match by Email).
Review and adjust mappings, then run the import to skip or update duplicates.
Schedule a daily process if needed, though manual upload per morning suffices for this volume.

References:
Salesforce Help: Data Import Wizard (Details deduplication and usage for leads).
Salesforce Trailhead: Import Data (Covers Wizard vs. Loader for small imports).
Salesforce Help: Prevent Duplicates During Import.

Explanation:

The Lightning Record Page is designed to display all the details of a single record. The Record Detail component is the primary component responsible for rendering the fields from the page layout.

Why C is Correct: The Record Detail component is built to show all the fields that are configured in the record's page layout. It provides a comprehensive view of the record's data, organized according to the layout sections (e.g., Details, Related Lists). This is the standard component for viewing the complete set of fields on a record page.

Why A is Incorrect: The Highlights Panel is designed to show a subset of key fields at the top of the record page for quick reference. It does not display all fields from the page layout; it only shows the fields that are specifically assigned to it.

Why B is Incorrect: The Recommendations component is part of Salesforce's Einstein AI features. It provides intelligent suggestions (e.g., next best actions) based on the record data, but it does not display the record's fields.

Why D is Incorrect: The Path component is a guidance tool that shows the stage of a record in a process (e.g., a sales process). It helps users understand what step comes next but does not display the record's field data.

Reference:
Salesforce Help Article: "Add Components to Lightning Pages." The Record Detail component is explicitly described as the component that "displays fields from the page layout associated with the record."

Explanation:

B. Update the account search layouts search results columns displayed. When multiple accounts have similar names, adding additional columns to the search results page can help users differentiate between them. For example, including the Billing City, Phone Number, or Account Number in the search results provides more context and helps the user quickly identify the correct record.
C. Update the account search layouts search filter fields. By adding additional fields to the search filter layout, users can narrow their search results using criteria other than just the company name. This is crucial when the company names are similar. For instance, an app builder could add filters for "Billing City" or "Industry" to help users find the correct account more efficiently.

Incorrect answers
A. Update the account search layout’s view filter settings. This is not a standard configuration option for search layouts. View filters are typically associated with list views, not the search results themselves.
D. Update the account search layouts accounts tab columns displayed. While this does affect the "Recently Viewed" list on the Accounts tab, it does not directly impact the search results page shown after a user performs a search. This is a subtle but important distinction.

Explanation:

Why:
To display the total value of all won Opportunities on the Account, use a Roll-Up Summary field on Account with:
Summary Type: Sum (of Opportunity Amount)
Filter Criteria: Opportunities where IsWon = True (or Stage = “Closed Won”)

Why the others are wrong:
A. Count – counts records, not their monetary value.
B. Max – shows the single highest Amount, not the total.
D. Min – shows the single lowest Amount, not the total.

Explanation:

The scenario describes a one-to-many relationship:
One experienced Realtor can mentor many new Realtors
Each new Realtor is assigned to only one experienced Realtor
The relationship is not tightly coupled (i.e., deleting the mentor shouldn’t delete the mentees)
This setup is best modeled using a Lookup relationship, which allows:
Flexibility in record ownership and deletion
Simple linking between two records without enforcing strict dependency

🔍 Why the other options don’t fit:
A. Indirect lookup
❌ Used for linking external objects via matching fields—not applicable here
B. Many-to-many
❌ Would imply new Realtors could have multiple mentors, which contradicts the requirement
C. Master-detail
❌ Too rigid—deleting the master (mentor) would delete the detail (mentee), which isn’t desired

🔗 Reference:
Lookup vs Master-Detail Relationships – Salesforce Help
Data Modeling – Trailhead

Explanation:

Why this works:
Validation rules can 1) block status regressions using functions like PRIORVALUE() (e.g., disallow moving from a later status back to an earlier one) and 2) require fields conditionally (e.g., when Status = “Closed”, ensure Close Reason, Resolution, etc., are filled). You can add clear error messages (the “help text” here) to guide users on what to fix.
Example ideas:
Prevent going backward: create a rule that evaluates the current Status against PRIORVALUE(Status) based on your defined sequence and throws an error if it’s a regression.
Require fields by criteria: AND(ISPICKVAL(Status, "Closed"), ISBLANK(Resolution__c))

Why the others are wrong:
B. Dependent picklist fields — Dependency controls available values, not status progression, and “required” here won’t enforce conditional requirements across the scenario.
C. Approval process — Approvals don’t inherently prevent status regression or make fields required on edit; they route for sign-off.
D. Page layout required fields — Page layout “Required” is always required (not conditional) and doesn’t stop status regressions. It also doesn’t enforce via API/integrations.

Reference:
Salesforce Help — Validation Rules (including using PRIORVALUE() and conditional requirements).

Explanation:

Service agents at Ursa Major Solar need a more condensed case view and the ability to modify associated Contact and Account records directly from the Case page layout on a Lightning record page. The following components meet these requirements:

C. Related Record:
The Related Record component allows users to view and edit related records (e.g., Contact or Account) directly on the Case page without navigating away. By adding this component and configuring it to display the associated Contact and Account, service agents can modify key fields (e.g., phone number, email) inline, meeting the requirement for editing from the Case layout. This also helps condense the view by reducing the need for separate page navigation.
D. Tabs:
The Tabs component enables the app builder to organize sections of the Case page (e.g., Case Details, Contact Info, Account Info) into collapsible or switchable tabs. This condenses the layout by grouping related information, making it easier for agents to focus on essential data without overwhelming the screen, thus supporting the condensed view requirement.

Why not the other options?
A. Path:
The Path component provides guided navigation for record stages (e.g., Case Status progression) but does not facilitate editing related records or condensing the layout beyond its specific guidance role. It’s unrelated to the core requirements.
B. Rich Text:
The Rich Text component allows adding formatted text or images to the page but does not support editing related records or condensing the view. It’s a static display tool, not a functional solution for this scenario.

Implementation Notes:
Add the Related Record component to the Case Lightning page, configure it for Contact and Account with editable fields (e.g., via Field Sets or custom layout), and ensure the component visibility aligns with agent permissions.
Add the Tabs component, create tab sections (e.g., "Case," "Contact," "Account"), and assign relevant components or fields to each tab for a condensed, organized layout.
Test the page in Lightning App Builder to ensure usability on both desktop and mobile.

References:
Salesforce Help: Related Record Component (Details editing related records).
Salesforce Help: Tabs Component (Explains layout organization).
Salesforce Trailhead: Customize a Lightning Page (Covers component usage).

Explanation:

In a master-detail relationship, the detail (child) record does not have its own independent security or sharing model. Its access is entirely controlled by the master (parent) record.

Why C is Correct:
A key characteristic of a master-detail relationship is that the detail record inherits its sharing and ownership settings from the master record. The detail record does not even have a visible OwnerId field in the database. Its access is determined solely by the owner of the parent master record and the sharing settings applied to that master record.

Why A is Incorrect:
There is no "default owner" setting on a parent object that applies to detail records. The owner of the master record is what matters.

Why B is Incorrect:
Detail records in a master-detail relationship do not have an Owner field. This field is removed from the detail object's schema because ownership is inherited.

Why D is Incorrect:
The detail object cannot have its ownership set independently. This is the defining difference between a master-detail relationship and a lookup relationship. The detail object's sharing model is automatically set to "Controlled by Parent" and cannot be changed.

Reference:
Salesforce Help Article: "Master-Detail Relationship Considerations." The documentation explicitly states: "Sharing access to the detail record is determined by the sharing access to the master record. For example, if a user has Read Only access to a master record, the user has Read Only access to the related detail records." and "The detail record doesn’t have its own owner...".

Explanation:

Why:
When a permission set is deployed (Metadata API v40+), the metadata in the deployment replaces the target org’s permission set—absent permissions are treated as false. This is Salesforce’s documented behavior and applies to change sets as well.

Eliminate the others:
A. “Only contain changes related to the change set” — that describes how profiles behave for included components, not permission sets. Permission sets deploy as a whole.
B. False — field-level security in a permission set is included and applied. (Standard object/field permissions are part of permission set metadata.)
C. Merge behavior was pre-API 40.0; current behavior is overwrite.

Tip:
Always review the full permission set diff before deployment—because it overwrites, any missing permissions in the file will be turned off in production.