Free Platform-App-Builder Practice Test Questions 2026

Explanation:

The user wants to allow an applicant to apply for multiple positions, and for a position to receive multiple applications. This is a classic many-to-many relationship scenario, which cannot be modeled with a single master-detail or lookup relationship in Salesforce.

Junction Object:
A third, intermediary custom object must be created to link the two primary objects (Applicant__c and Open_Position__c). In this case, the Application__c object serves as the junction object.
Master-Detail Relationships:
The junction object (Application__c) needs to have two master-detail relationships—one to Applicant__c and one to Open_Position__c. This allows a single Applicant__c record to be linked to multiple Application__c records, and a single Open_Position__c record to be linked to multiple Application__c records, effectively creating the many-to-many relationship.

Breakdown of the options:
A. Create a master-detail relationship on Open_Position__c to Application__c:
This is one part of the solution, but it's not the complete picture. This alone would imply a one-to-many relationship from the application to the position.
B. Create a master-detail relationship held on Applicant__c to Application__c:
This is also only one part of the solution. The master-detail fields should be on the junction object (Application__c), not the master objects.
C. Create a master-detail relationship field on Application__c to Open_Position__c:
This is one of the two relationships needed on the junction object.
D. Create a master-detail relationship field on Applicant__c to Apphcabon_c:
This option contains a typo (Apphcabon_c) and describes only one side of the relationship. It is also incomplete.

The most accurate and complete recommendation would involve creating the junction object Application__c and then creating the two master-detail relationship fields on it. Given the choices, none are complete, but C is one of the two relationships required.

Explanation:

The question asks for three common items that an app builder can move using change sets in Salesforce to support Universal Containers’ sandbox release schedule. Change sets are a deployment tool in Salesforce used to migrate metadata (configuration and code) between related orgs (e.g., from sandbox to production). Let’s analyze each option step-by-step to determine which items can be included in a change set:

A. Web-to-lead:
Web-to-lead is a Salesforce feature that generates HTML code for lead capture forms on external websites. While web-to-lead settings (e.g., default lead owner, form fields) are configurable, they are considered data or org-specific settings, not metadata. Change sets are used for metadata migration, and web-to-lead configurations cannot be included in a change set. This option is incorrect.
B. Standard fields:
Standard fields are predefined fields provided by Salesforce on standard objects (e.g., Name, CreatedDate on Account). These fields are part of Salesforce’s core platform and cannot be modified or migrated via change sets because they are not custom metadata. Only custom metadata or configurations (like custom fields or page layouts) can be included. This option is incorrect.
C. Custom object:
Custom objects are user-defined objects created to store specific data (e.g., a custom object for tracking projects). Custom objects, including their definitions, fields, relationships, and associated metadata (like page layouts or validation rules), are considered metadata and can be included in a change set. This is a common item moved by app builders during deployments, making this option correct.
D. Apex class:
Apex classes are custom code written in Salesforce’s Apex programming language to implement business logic. Apex classes are metadata and can be included in a change set for deployment between orgs. This is a common item for developers and app builders to migrate, especially when custom functionality is part of the release. This option is correct.
E. Custom field:
Custom fields are user-defined fields added to standard or custom objects to capture additional data (e.g., a custom “Project Deadline” field on a custom object). Custom fields, including their definitions and configurations, are metadata and can be included in a change set. This is a very common item for app builders to migrate, making this option correct.

Why These Three?
Custom object (C): Essential for deploying new data structures and associated configurations (e.g., fields, page layouts).
Apex class (D): Critical for deploying custom business logic, often part of complex release schedules.
Custom field (E): Commonly used to extend standard or custom objects, frequently included in change sets for schema updates.

These items are all metadata, align with the capabilities of change sets, and are commonly managed by app builders during deployments.

Additional Notes:
Change sets require a deployment connection between orgs (e.g., sandbox to production) and are limited to metadata components. Other tools, like Data Loader or third-party backup solutions, are needed for data migration (e.g., web-to-lead form data).
While standard field configurations (e.g., picklist values or field-level security) can sometimes be included in change sets, the fields themselves cannot, which rules out option B.

References:
Salesforce Help: Change Sets Overview – Describes change sets and the types of metadata components that can be included.
Salesforce Help: Components Available in Change Sets – Lists metadata types, including custom objects, Apex classes, and custom fields, that can be migrated.
Trailhead: Change Management – Covers deployment strategies, including using change sets for metadata migration.

Explanation:

The problem has two parts: 1) gathering feedback from core team members, and 2) understanding who is available to respond. The correct answers directly address these two specific needs.

B. Polls: This feature directly solves the problem of "gathering feedback from core team members." A user can create a poll within a Chatter group to quickly get opinions, make decisions, or gather input from the team in a structured, easy-to-consume format. This is more efficient than parsing through long comment threads.

C. Out of Office: This feature directly solves the problem of "understanding who is available to respond." When users set their Out of Office status in Chatter, it automatically displays an indicator on their profile and posts in relevant feeds. This informs colleagues that the person is unavailable and might not respond promptly, managing expectations within the fast-paced sales environment.

Why the other options are incorrect:
A. Streams: Streams are customized feeds that allow users to monitor specific topics, people, or groups. While incredibly useful for filtering information and staying updated, they are a consumption tool, not a tool for actively gathering feedback or signaling availability. They help you see what's happening but don't directly facilitate the two-way communication required for the problems stated.
D. Topics: Topics are used to tag and categorize content (like posts, files, and records) to make it discoverable. While using topics could help someone find content related to "feedback" or "availability," they do not actively provide a mechanism to create a feedback poll or to indicate one's own availability. They are for organization and search, not for direct action.

Reference:
This falls under the exam section "Collaboration and Visibility." A key objective is to demonstrate knowledge of "Chatter features and functionality." Understanding the practical application of specific Chatter tools like Polls for engagement and Out of Office for presence is essential for the Platform App Builder exam.

Explanation:

To display a related list on a parent object (in this case, Product), a relationship must be established between the parent and child objects (Product and Component). The relationship field is created on the child object (Component) and points to the parent object (Product).

Lookup Relationship:
This creates a one-to-many relationship where multiple Component records can be linked to a single Product record.
Create the Field on the Child Object:
When you create the lookup relationship field on the Component object and link it to the Product object, Salesforce automatically creates the related list on the Product object's page layout.
Add to Page Layout:
The final step is to add the new Component related list to the desired Product page layout so that users can see the associated components.

Why other options are incorrect:
A. Create a master-detail relationship on Product to Component:
This is incorrect because the relationship field is always created on the child (Component) object, not the parent (Product). While a master-detail relationship would also create a related list, it enforces stricter data integrity and sharing rules that may not be necessary.
B. Create a junction object to relate Component and Product:
A junction object is only needed to solve a many-to-many relationship. In this case, the requirement is to show components of a product, which is a one-to-many relationship (one product, many components). A junction object is not necessary.
C. Create a roll-up on Product:
A roll-up summary field is used to aggregate data from child records onto a parent record. It does not create or display a related list of records.

Explanation:

Universal Containers needs a custom object to track installation information for purchased containers, with sales reps able to see all installations linked to their opportunities. The new custom object (e.g., Installation__c) must be related to the Opportunity object, and the relationship type determines how they are connected.

A. Lookup: Correct.
A lookup relationship links the Installation__c object to Opportunity, allowing each installation to be associated with one opportunity. Sales reps can view all installations related to their opportunities via related lists. Lookup relationships are flexible, don’t enforce dependency, and allow the child record (Installation__c) to exist independently, which fits the scenario where installations are tracked post-purchase.
B. Hierarchical: Incorrect.
Hierarchical relationships are specific to the User object for defining reporting structures (e.g., manager hierarchies) and are not applicable for relating custom objects to opportunities.
C. Master-Detail: Incorrect.
A master-detail relationship creates a tight dependency where the child (Installation__c) is deleted if the parent (Opportunity) is deleted, and it enforces ownership and security from the parent. This is too restrictive, as installations may need to persist independently of opportunities (e.g., for historical tracking post-opportunity closure).
D. Many-to-Many: Incorrect.
A many-to-many relationship requires a junction object to link multiple Installation__c records to multiple Opportunity records. The requirement suggests a one-to-many relationship (one opportunity can have multiple installations), not many-to-many, making this option unsuitable.

Why Lookup?
A lookup relationship supports a one-to-many structure where one Opportunity can have multiple Installation__c records. It provides visibility through related lists on the Opportunity page, is less restrictive than master-detail, and aligns with the need to track installations tied to specific opportunities without forcing dependency.

References:
Salesforce Help: Relationships Among Objects
Trailhead: Data Modeling

Explanation:

Ursa Major Solar wants to display the Type field from the parent Galaxy__c object on the child Star__c object, but the app builder is encountering an error: "Picklist values are only supported in certain functions." This indicates that the Type__c field on Galaxy__c is a picklist, and the formula used to reference it is incorrect. The goal is to create a formula field on Star__c to show the value of the Type__c picklist from the related Galaxy__c record.

A. ISPICKVAL(Galaxy__r.Type__c): Incorrect.
The ISPICKVAL function checks if a picklist field matches a specific value (e.g., ISPICKVAL(Type__c, "Value")). It requires a value to compare against and is used in conditional logic, not for directly displaying a picklist value. This causes the error since it’s misused here.
B. VALUE(Galaxy__r.Type__c): Incorrect.
The VALUE function converts a text string to a number (e.g., VALUE("123") returns 123). It’s not designed for picklist fields, which are text-based, and would cause an error when applied to a picklist field like Type__c.
C. TEXT(Galaxy__r.Type__c): Correct.
The TEXT function converts a picklist value to its text representation, allowing it to be displayed in a formula field. Since Type__c is a picklist on the parent Galaxy__c object, using TEXT(Galaxy__r.Type__c) retrieves the selected picklist value (e.g., "Spiral" or "Elliptical") and displays it on the Star__c record. This avoids the error and meets the requirement.
D. FIND(Galaxy__r.Type__c): Incorrect.
The FIND function searches for a substring within a text string and returns its position (e.g., FIND("a", "abc") returns 1). It’s not suitable for displaying a picklist value and would cause an error when applied to a picklist field.

Why TEXT?
Picklist fields in Salesforce store values as text, but formulas require the TEXT function to properly reference and display picklist values. The formula TEXT(Galaxy__r.Type__c) correctly retrieves the text value of the Type__c picklist from the parent Galaxy__c record via the relationship field (Galaxy__r) and displays it on the Star__c object.

Implementation:
Create a formula field on Star__c with return type Text.
Use the formula: TEXT(Galaxy__r.Type__c).
This displays the Type__c picklist value from the related Galaxy__c record.

References:
Salesforce Help: Formula Operators and Functions – Explains using TEXT for picklist fields.
Trailhead: Formulas and Validations – Covers formula field creation and picklist handling.

Explanation:

Why:
Schema Builder gives a visual ERD-style view of objects and all their relationships in one place, letting you inspect and create fields/relationships quickly.

Why not the others:
B. Lightning Object Creator: Creates objects from spreadsheets; not for mapping relationships.
C. Object Manager: Configure one object at a time; no holistic relationship diagram.
D. Lightning Record Page: Controls page layout/components, not data model relationships.

Explanation:

The requirement is for service agents to confirm a user’s identity before providing support information over the phone. This implies a need for a structured process to guide agents through specific steps (e.g., verifying identity) on the Case record page. Let’s analyze the options:

A. Include Surveys as a Case related list:
Surveys collect feedback from users, typically after case resolution. They are not designed for real-time identity verification during a phone call, making this option irrelevant.
B. Case Validation Rules:
Validation rules enforce data quality by preventing record saves unless conditions are met (e.g., requiring a field to be filled). They don’t guide agents through an interactive process or prompt for identity verification steps, so this option doesn’t meet the requirement.
C. Add Path to the top of the Case layout:
Path (e.g., Kanban view) visualizes stages of a process (like case status) but is not designed for guiding agents through specific actions like identity verification. It’s more for tracking progress, not enforcing procedural steps.
D. Guided Action Flows on the record page: Correct.
Guided Action Flows (using Salesforce Flow, such as Screen Flows) can be embedded on a Case record page via the Lightning App Builder. A Screen Flow can prompt agents with interactive screens to collect and verify identity details (e.g., asking for a customer’s name, email, or security question). This ensures agents follow a standardized process before providing support, meeting the requirement effectively.

Why Guided Action Flows?
Guided Action Flows provide an interactive, step-by-step interface on the record page, ideal for ensuring agents confirm user identity in a structured way. Flows can include input fields, conditional logic, and validation to enforce identity checks before proceeding.

References:
Salesforce Help: Screen Flows – Explains how to create interactive flows for guided processes.
Trailhead: Build Flows – Covers embedding flows on Lightning record pages.

Explanation:

Why:
Lightning App Builder (C): The component palette shows all custom (and standard) Lightning components available for the selected page type, so builders can see what’s usable right there.
Lightning Components in Setup (D): In Setup (Quick Find → Lightning Components), you’ll see the list of custom Aura/LWC components deployed in the org.

Why not the others:
A. Visualforce components in Setup: Lists Visualforce components, not Lightning components.
B. Lightning component Generator: Not a standard Salesforce feature/page; components aren’t listed there.

Explanation:

Correct Answer: A. Import Wizard ✅

Why this is correct:
The Data Import Wizard is designed for smaller data volumes (up to 50,000 records), which fits Cloud Kicks’ need to load 25,000 records.
Import Wizard also includes deduplication features (it can prevent duplicates when importing by matching on record ID, name, or email depending on the object).
Since the question explicitly asks for deduplication, this is the right tool.

Why not the others:

B. Lightning Object Creator ❌
Used to quickly create custom objects from spreadsheets.
Not meant for mass data import into an existing custom object like Race_Track__c.

C. Data Loader ❌
Yes, Data Loader can handle very large volumes (millions of records).
But it does not provide deduplication on its own — it just inserts or upserts based on ID.
Since deduplication is the key requirement here, Data Loader isn’t the best choice.

D. Schema Builder ❌
Schema Builder is for creating/modifying objects, fields, and relationships visually.
It has nothing to do with importing records.

📖 Reference:
Salesforce Help: Data Import Wizard
Salesforce Help: Data Loader

Explanation:

The "Accordion" Lightning component is designed to break up content into collapsible sections. This component would be suitable for managing the visibility of large numbers of fields by grouping them into separate tabs or sections that can expand and collapse. This makes navigation easier and declutters the interface.

A: Highlights panel is used for displaying key record information at the top of the page and is not designed for managing multiple fields.
B: Record detail displays all fields on a single layout, which does not suit the requirement to break up the fields.
C: Field section does not exist as a standard Lightning component.

Explanation:

Why:
If you want to deploy a Flow as active (so it’s live immediately), Salesforce requires Flow test coverage via Apex tests. With the “Deploy processes and flows as active” setting enabled in Production, deployments will run Apex tests and fail unless tests launch at least 75% of your active processes and autolaunched flows. So you must have Apex tests that exercise this Flow (or a process that invokes it). Otherwise you’ll have to deploy it inactive and activate it manually.

Why not the others:
B. Grant user access to the Flow. Not required for an autolaunched Flow that’s invoked by automation.
C. Manually activate the Flow after deployment. That defeats the goal of deploying already active; it’s only needed if you don’t meet the active-deploy prerequisites. (By default, change sets deploy flows inactive unless you use the “deploy as active” setting.) Salesforce
D. Include the Process Builder calling the Flow. Not necessary; Process Builder calls the latest active version by API name.

Salesforce:
Salesforce Help — Deploy Processes and Flows as Active (coverage rules and setup), and community/Stack Exchange discussions confirming the 75% flow coverage requirement.