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

Explanation:

Customers and Dealers are separate business entities:
Since both customers and dealers are distinct business entities with whom UC has direct relationships and sends separate bills, they should each be represented as separate accounts in Salesforce.
Representatives are individuals:
Each individual at the customer and dealer should be created as a contact and associated with their respective account.
Relationship between customers and dealers:
The Account Hierarchy feature in Salesforce allows you to establish a parent-child relationship between accounts. This would enable UC to represent that the customers sell their products through dealers.
Clear display of relationships:
This approach clearly displays the customers and dealers as distinct business entities and their relationship through the Account Hierarchy. The individual representatives are linked to their corresponding organizations as contacts.

Why other options are incorrect
A. Create a single parent record, add each rep as a contact to the parent account and add each dealer as a child record:
This option suggests creating a single parent record for both customers and dealers, which doesn't accurately represent them as distinct entities with direct billing relationships.
B. Create both customer and dealer as accounts, create account teams on each account and associate the dealer records with the parent account:
While creating both as accounts is correct, using account teams is for internal collaboration on an account, not for defining the primary business relationship between a customer and its dealers. The association mentioned is better represented by an account hierarchy.
C. Create a single account record, add each rep as a contact and create a custom dealer object:
Creating a single account record for the customer would not correctly represent the dealer as a separate billable entity. While custom objects offer flexibility, using the standard Account object with its hierarchy feature is the most straightforward and recommended approach for representing related business entities like customers and dealers.

Explanation:

The issue described involves a high number of inactive picklist values on the Account object’s picklist fields, which negatively impacts system performance and user experience. Salesforce provides Global Value Sets (also known as Picklist Value Sets) as a solution to manage picklist values more efficiently, especially when values are reused across multiple fields or need frequent updates.

B. Set up Global Values in Picklist Value Sets (Correct):
Global Value Sets allow you to define a single set of picklist values that can be reused across multiple picklist fields in different objects. By converting the picklist fields on the Account object to use a Global Value Set, Universal Containers can centrally manage the values, including deactivating or removing outdated ones. This reduces redundancy, simplifies maintenance, and can improve performance by minimizing the number of inactive values stored for each field. Additionally, Global Value Sets make it easier to update values across all associated fields at once, addressing the issue of frequent changes due to evolving business requirements.
Reference: Salesforce Help - Define Picklist Value Sets

Why not the other options?
A. Establish upper bound on existing picklists in Picklist Settings (Incorrect):
Salesforce does not provide an option in Picklist Settings to set an upper bound on the number of picklist values (active or inactive). While there are system limits (e.g., 1,000 total values for a standard picklist, including active and inactive), these are not configurable by the admin in the way described. This option does not address the issue of managing inactive values or improving performance.
Reference: Salesforce Help - Picklist Limitations

C. Remove upper bound on inactive picklist values in Picklist Settings (Incorrect):
There is no setting in Salesforce to specifically “remove an upper bound” on inactive picklist values. The platform imposes limits on the total number of picklist values (active and inactive), and inactive values still count toward this limit. Removing or adjusting such a bound is not a feature in Salesforce, and this option does not solve the performance or user experience issue.
Reference: Salesforce Help - Picklist Field Limits

D. Convert the picklist fields to a different field type that will still meet the business requirements (Incorrect):
Converting picklist fields to another field type (e.g., text, multi-select picklist, or lookup) may not be feasible or desirable, as it could disrupt existing business processes, reports, or integrations that rely on the picklist structure. Additionally, this does not directly address the issue of managing inactive values or improving performance. It’s a drastic change that may not meet the business requirements without significant rework.
Reference: Salesforce Help - Change Field Type

Recommended Approach:
Navigate to Setup > Object Manager > Picklist Value Sets.
Create a new Global Value Set with the required picklist values.
Update the Account object’s picklist fields to use the Global Value Set instead of individual picklist values.
Review and remove unnecessary inactive values from the Global Value Set to streamline performance.
Test the updated fields to ensure they meet business requirements and improve user experience.

Additional Notes:
Inactive picklist values can impact performance, especially in large orgs, as they are still stored and processed in the background (e.g., in reports, list views, or SOQL queries). Using Global Value Sets reduces redundancy and simplifies value management.
If the number of inactive values is significantly high, you can also archive or delete unused values (if not referenced in historical data) to further optimize performance, but this must be done cautiously to avoid data integrity issues.

Reference:
Salesforce Help: Create and Manage Global Picklist Value Sets
Salesforce Trailhead: Data Modeling - Picklist Administration

Explanation:

Formula fields in Salesforce are powerful tools that allow you to:
Reference parent fields (via relationships)
Concatenate text, numbers, and dates
Apply logic using functions like IF(), TEXT(), CONCAT(), etc.
In this case, the Opportunity Product (technically the OpportunityLineItem object) can access fields from its parent Opportunity using relationship syntax like Opportunity.Name or Opportunity.Description.
So, combining two text fields from the parent Opportunity — such as Opportunity.Text_Field__c + " " + Opportunity.Description__c — is fully supported in a formula field.

❌ Why the other options don’t work:
A. A hyperlink to the parent Account of the parent Opportunity
Formula fields cannot traverse two relationships (i.e., from Opportunity Product → Opportunity → Account). You can only go one level up.
B. A Rich Text area field that uses HTML to bold certain characters
Formula fields do not support Rich Text formatting or HTML styling like < b > tags.
D. A mix of functions and concatenation of 10 Account fields and 10 Opportunity fields
You cannot access Account fields from Opportunity Product via formula — that’s two levels up.
Also, this would likely hit the formula character limit (3,900 characters for compiled size).

🔗 References:
Salesforce Help: Formula Field Limits and Capabilities
Trailhead: Formulas & Validations

Explanation:

Why:
Create an Update a Record quick action on the Account object (include the Account fields the user should edit). Then add a Related Record component to the Opportunity Lightning record page, point it at the AccountId lookup, and select that update action. This lets users edit the parent Account directly from the Opportunity page.

Why not the others:
B. Details component only edits the current record (Opportunity), not the related Account.
C. Formula fields are read-only—no editing.
D. Process/flow updates are automation, not a UI for the user to directly edit the Account.

Explanation:

Universal Containers (UC) needs a custom component built within a tight 4-week timeline, but their developers are backlogged for months and require additional enablement. An AppExchange solution is the most suitable option to meet this time-sensitive requirement, as it allows UC to leverage pre-built, third-party components or applications that can be quickly installed and configured, bypassing the need for extensive custom development.

A. Use an AppExchange solution (Correct):
The AppExchange is Salesforce’s marketplace for pre-built apps, components, and solutions created by Salesforce partners or ISVs (Independent Software Vendors). These solutions can often be installed and configured quickly, meeting UC’s 4-week timeline without requiring significant developer effort. AppExchange solutions can range from free to paid and often include components that address common business needs, reducing the need for custom coding and enabling faster deployment.
This option is ideal given the developer backlog and the need for additional enablement, as many AppExchange solutions come with documentation, support, and configuration options that non-developers (like app builders) can utilize.
Reference: Salesforce Help - AppExchange Overview

Why not the other options?
B. Build a screen flow page (Incorrect):
While Screen Flows are powerful for creating guided user experiences, building a custom component using flows still requires significant design and configuration effort. Given the developer backlog and the need for additional enablement, creating a flow from scratch within 4 weeks may not be feasible, especially if the component is complex.
Reference: Salesforce Help - Screen Flows

C. Build a Lightning record page (Incorrect):
Creating a Lightning Record Page involves customizing the user interface for a specific object using the Lightning App Builder. While this is within an app builder’s skill set, it does not address the creation of a custom component (e.g., custom logic, functionality, or reusable code). Building a record page from scratch would also require developer input for any custom components, which is not viable given the backlog and timeline.
Reference: Salesforce Help - Lightning Record Pages

D. Use a Boit solution (Incorrect):
The term “Boit solution” appears to be a typo or misinterpretation in the context of Salesforce, likely intended to mean “Bolt solution” (Salesforce Bolt solutions are pre-built industry-specific templates). However, even if corrected to “Bolt solution,” this option is not ideal. Bolt solutions are typically industry-specific and may not address UC’s specific custom component needs. Additionally, Bolt solutions are less common and not as broadly applicable as AppExchange solutions for general custom component requirements.
Reference: Salesforce Help - Salesforce Industry Solutions

Recommended Approach:
Visit the AppExchange (accessible via Salesforce or at appexchange.salesforce.com).
Search for solutions or components that match UC’s requirements for the custom component. Evaluate options based on functionality, reviews, cost (free vs. paid), and compatibility with UC’s Salesforce org.
Install the solution in a sandbox for testing, then configure it to meet specific needs within the 4-week timeline.
Work with the provider’s documentation or support team to ensure proper setup without requiring extensive developer involvement.

Additional Notes:
AppExchange solutions can include managed packages, unmanaged packages, Lightning components, or flows, many of which are designed to be plug-and-play or easily configurable by app builders, aligning with UC’s resource constraints.
If no AppExchange solution fully meets the requirements, a partially suitable solution can often be customized more quickly than building from scratch, still addressing the time-sensitive need.
The app builder should verify licensing costs and security compliance (e.g., passing Salesforce’s security review) when selecting an AppExchange solution.

Reference:
Salesforce Trailhead: Explore AppExchange
Salesforce Help: Install a Package from AppExchange

Explanation:

DreamHouse Realty wants each team member to begin small projects in their own sandbox before moving into shared environments like partial or full sandboxes. The key requirements here are:
Low cost
Individual use
Quick setup
Basic development and testing
🔹 Developer Sandbox is ideal for this:
It’s lightweight and cost-effective
Provides a copy of metadata only (no data)
Perfect for unit testing, configuration, and development
Refreshes quickly and can be spun up for each team member

❌ Why the other options don’t work:
A. Full sandbox
Too resource-intensive and expensive for individual use; meant for performance testing and staging
C. Developer pro sandbox
Similar to Developer sandbox but with more storage — useful for larger dev tasks, but not necessary for small projects
D. Partial sandbox
Includes sample data and is better suited for integration or UAT testing, not individual dev work

🔗 References:
Salesforce Help: Sandbox Types and Considerations
Trailhead: Application Lifecycle and Sandbox Strategy

Explanation:

A validation rule on the Contact object is the correct solution for this conditional requirement. The validation rule can use a cross-object formula to check the value of the Customer Status field on the parent Account record.
The formula would look something like ISPICKVAL(Account.Customer_Status__c, 'High Priority') && ISBLANK(Region__c).
This formula will return TRUE (and prevent the record from saving) if both conditions are met: the associated Account is 'High Priority' AND the Contact's Region field is blank.

Why other options are incorrect
A. Make the Region field required on Contact:
This would make the field required for all Contact records, regardless of the Account's priority, which does not meet the specific condition requested.
C. Create 4 validation rule on Account:
The validation needs to happen on the Contact record, as that is where the required field (Region) is located. A validation rule on the Account object cannot prevent a Contact from being saved.
D. Make the Customer Status field required or Account:
This would ensure the Customer Status field is filled out on the Account, but it would not enforce the conditional requirement for the Region field on the Contact.

Explanation:

Why these work
A. Big objects: Built for archiving massive/historical datasets without consuming your standard data storage. You can query them with SOQL/Async SOQL and they support certain field types including Lookup (from the big object to standard/custom objects). Standard reporting isn’t built directly on big objects; the recommended pattern is to use Async SOQL to extract a working subset into a (custom) reporting object or analytics dataset for dashboards, while keeping the archive in the big object.
D. External objects (Salesforce Connect): Keep archived data outside Salesforce (so it doesn’t count toward org storage) but still surface it in Salesforce as External Objects. These support reports (with limits), SOQL queries, and lookup-style relationships (External Lookup/Indirect Lookup) so users can relate archived records to Salesforce data and run reports on them.

Why not the others
B. Custom objects: Data would still live in Salesforce, so this doesn’t alleviate storage limits.
C. Related objects: Not an archiving mechanism—just a generic term for relationships.

References
Big Objects: Implementation guide & capabilities; querying & reporting guidance.
External Objects / Salesforce Connect: Reporting support; relationships; behavior.

Explanation:

The TODAY() function returns the current date, ideal for calculating whole days elapsed since a marketing communication was sent (e.g., TODAY() - Last_Communication_Sent__c). It ensures a whole number result, meeting the requirement for whole units.

A. DATETIMEVALUE(): Converts text to DateTime, not needed for current date.
C. DATEVALUE(): Converts DateTime/text to Date, unnecessary since TODAY() is simpler.
D. NOW(): Returns current date and time, producing decimal days, not whole units.

Reference:
Salesforce Help - TODAY()

Explanation:

Deploying a Lightning record page (often referred to as a "detail page layout" in the context of Lightning Experience) requires deploying all its dependent components to ensure it works correctly in the target org.

Why A is Correct:
The Detail page layout (officially called a Lightning Page) is the primary component you intend to deploy. This is the core item that must be included in the Change Set.

Why B is Correct:
If your page layout contains any custom fields, those fields must also be deployed. If the custom fields do not exist in the production org, the page layout will fail to load or will show errors for those missing fields. The deployment of the page layout will likely fail during validation if its dependent fields are missing.

Why C is Correct:
If you have added any custom actions (like an update record action) to the page's publisher layout, those actions must be deployed. The page layout references these actions. If they are missing in production, those specific components will not appear or function on the page.

Why D is Incorrect:
Lightning App Builder is the tool used to create and edit Lightning Pages. It is not a deployable component itself; it is a feature of the Salesforce platform. You deploy the output of the tool (the Lightning Page), not the tool.

Why E is Incorrect:
While profile settings control who can see the page layout, the System Administrator profile itself is not a component you include in a Change Set to make the page layout deploy or render correctly. Profile visibility for the page is handled by the page's assignment (which is part of the page deployment) or by permission sets. You do not deploy entire profiles for this purpose.

Reference:
Salesforce Help - "Change Sets Overview" and "Deploy Lightning Page Resources". The key principle is that when deploying any component, you must also deploy all its dependencies—the other metadata components it relies on to function. For a Lightning Page, this includes the fields, actions, and any other custom components placed on it.