Free Platform-App-Builder Practice Test Questions 2026

Explanation

CASESAFEID(Id) is the correct formula function. This function returns the 18-character, case-insensitive version of a 15-character ID. The 15-character ID is case-sensitive, which can cause issues when exported to external systems like Excel, as those systems may not preserve the case. The 18-character ID includes a 3-character checksum that ensures its uniqueness regardless of case, making it safe for export and use in spreadsheets or databases where case-sensitivity might be an issue.

Why the other options are incorrect:
A. ISNUMBER(Id):
This function returns a Boolean value (TRUE or FALSE) checking if the referenced value is a number. A Salesforce ID is a text string, not a number, so this formula would always return FALSE. It is useless for this requirement.
C. TEXT(Id):
While this function correctly converts the ID to a text string, it does not perform the necessary conversion from a 15-character ID to an 18-character ID. If the record has already been saved and has the 18-character ID, TEXT(Id) would simply return that 18-character ID. However, for consistency and to guarantee the 18-character format (especially in any context), CASESAFEID() is the more explicit and functionally correct choice.
D. VALUE(Id):
This function converts a text string representing a number into a numeric value. Since a Salesforce ID is an alphanumeric text string (e.g., 0015j00000X1Y2Z3), it cannot be converted to a number. Using this function would result in an error.

Reference:
This falls under the Data Modeling and Management section. It tests knowledge of Salesforce record IDs and the specific formula functions available for handling them within a custom formula field.

Key Takeaway:
Always use CASESAFEID(Id) in formula fields when you need a guaranteed case-insensitive, 18-character record ID for data export or integration purposes.

Explanation:

Schema Builder is the most efficient tool for creating a custom object, adding multiple fields, and defining relationships — all from a single visual interface.
It provides a drag-and-drop canvas that lets you:

Create custom objects
Add fields (standard and custom)
Define relationships (lookup, master-detail)
View the entire data model in real time

This is ideal when you're building a new object with several fields and want to visualize how it fits into your org’s data architecture.

❌ Why Not the Other Options?
B. Developer Console
Primarily used for coding (Apex, SOQL, etc.). Not designed for declarative object/field creation.
C. Manage Field Permissions
Used to control visibility/access to fields, not for creating objects or fields.
D. Lightning Object Creator
Allows creation of a custom object from a spreadsheet, but doesn’t support creating multiple fields and relationships in one place visually.

🔗 Reference:
Salesforce Help: Create Objects with Schema Builder
CRS Info Solutions: Step-by-step guide to creating objects and fields

Explanation:

Flow for Interactive Guided Processes:
A Flow is the correct tool for creating a series of question prompts. A Screen Flow, specifically, can present a user (in this case, the customer service representative) with a series of screens to collect information and guide them through a business process.
Approval Process:
An Approval Process is used to automate how records are approved in Salesforce, not to collect information interactively.
Validation Rule:
A Validation Rule is used to ensure data quality by preventing users from saving records with incorrect data. It doesn't guide users through a series of questions.
Path:
A Path is a visual tool on a record page that guides users through stages in a process (like a sales process). While helpful for visualizing progress, it is not designed to present a series of questions and prompts to collect information.

How a Flow would work
An app builder would create a Screen Flow and embed it on the appropriate record page (e.g., the Case record page). The flow would then:
Display a screen with the first question.
Use the user's input to determine the next screen or action.
Continue this process, collecting all necessary information from the customer via the representative.
Finally, the flow would perform an action, such as creating a new record, updating the current record, or sending an email.
The correct option is B. Flow.

Explanation:

When custom tabs are deployed to a Salesforce org (e.g., Production) via change sets without including profile settings or permission sets, the visibility of those tabs is not automatically configured for users. Let’s break down the options:

A. Custom tabs are default off for all users:
Correct. In Salesforce, when a custom tab is deployed without associated profile settings or permission sets, the tab is not automatically visible to any users. The tab exists in the org, but its visibility must be explicitly enabled by updating profiles or permission sets to grant access (e.g., setting the tab to "Default On" or "Tab Hidden"). By default, the tab is "Default Off," meaning users cannot see it until permissions are configured.
B. Custom tabs are default on for all users:
Incorrect. Custom tabs are not automatically visible to all users upon deployment. Visibility requires explicit configuration in profiles or permission sets, such as setting the tab to "Default On."
C. Custom tabs are hidden for all users:
Incorrect. While this sounds similar to "Default Off," the term "hidden" implies the tab is explicitly set to "Tab Hidden" in profiles, which is not the default behavior. "Default Off" means the tab is not visible unless a user’s profile or permission set explicitly enables it, whereas "Tab Hidden" is a specific setting to hide the tab even if permissions exist.
D. Custom tabs are NOT deployed:
Incorrect. The question states that the custom tabs have been deployed via change sets, so they are present in the Production org. The issue is about their visibility, not whether they were deployed.

Why "Default Off"?
In Salesforce, tab visibility is controlled by profiles or permission sets. When deploying custom tabs without these settings, Salesforce does not assume any visibility settings. The tabs are deployed but are effectively "Default Off" for all users, meaning they won’t appear in the user interface (e.g., in the App Launcher or navigation bar) until an administrator configures access. This is a security and governance feature to ensure that new tabs are only visible to the intended users.

Implementation Note:
To make the custom tabs visible after deployment:
Navigate to the relevant profiles or permission sets in Setup.
Edit the Tab Settings for the custom tab.
Set the tab to Default On (visible in the app navigation) or Default Off (available but not shown unless added by the user). Avoid Tab Hidden if you want users to access it.
Save and test visibility for affected users.

References:
Salesforce Help: Custom Tabs
Salesforce Help: Control Tab Visibility
Trailhead: Change Sets Best Practices

Explanation:

The utility bar is a part of the Lightning App Builder interface. To make a custom Lightning web component or Aura component available for placement on the utility bar, it must be explicitly configured to be compatible with the Lightning App Builder. This is done by including the tag in the component's XML metadata file and specifying the Lightning__AppPage target.
Why this is correct: Tagging a component "For use in Lightning App Builder" (Lightning__AppPage) is the prerequisite that makes it available for drag-and-drop into any region of an app page built with the tool, which includes the utility bar, the header, the main body, and the footer. The utility bar is not a separate tag but a specific location within the App Builder's purview.

Why the other options are incorrect:
A. For use on record pages: This is a more specific target (Lightning__RecordPage). While a component tagged for record pages is also available in the Lightning App Builder (because Lightning__RecordPage inherits from Lightning__AppPage), it is not the most direct or fundamental answer. The question is about general availability in the App Builder tool itself.
C. For use on the utility bar: There is no specific, standalone metadata tag for "utility bar." The utility bar is a location within an app built in the Lightning App Builder. Availability is controlled by the broader Lightning__AppPage target.
D. For use in App Manager: The App Manager is an administrative setup screen used to create and manage apps. Custom components are not added to the App Manager interface itself. This is not a valid target for a component.

Reference:
This falls under the User Interface section. It tests the understanding of how to configure custom components for deployment in different parts of the Lightning Experience, specifically the metadata targets required for the Lightning App Builder.

Key Takeaway:
To make a component available in the Lightning App Builder (and consequently its utility bar), its .js-meta.xml file must include the target Lightning__AppPage.

Explanation:

The solution that the app builder should configure to meet these requirements is creating three lead record types each with its own page layout containing the relevant fields. This way, the app builder can customize the fields and sections that appear on each record type based on the source of the lead.

Option B is incorrect because creating a partner community and a record type for web and trade show leads does not address the requirement of collecting information that is unique to each type of lead, as partner community users may have different fields and layouts than internal users.
Option C is incorrect because creating three sections on the lead layout and instructing users to collapse the non-relevant fields does not address the requirement of collecting information that is unique to each type of lead, as users may still see or enter data in the wrong fields.
Option D is incorrect because creating custom page layouts for each type of lead only containing the relevant fields does not address the requirement of collecting information that is applicable to all sources, as users may miss some common fields.

Explanation:

Why A is Correct:
A Custom Action is the modern and supported way to create a quick, inline editing experience directly from the Chatter feed on both desktop and the Salesforce Mobile App. You can create a "Update Record" action that is pinned to the publisher layout. This allows users to see and interact with specific fields (like Status and a custom Due Date) without having to navigate away from the feed to the full record edit page. This provides the "quick way" the business user requires, especially on mobile where screen space is limited.
Why B is Incorrect:
Custom Buttons are built using JavaScript or a URL. They are not fully supported or displayed in the Salesforce Mobile App. Even if they were, they typically navigate the user to a new page, which is not the "quick" inline experience requested from the feed.
Why C is Incorrect:
A Quick Access Link (part of the Utility Bar) is designed for global navigation within the Salesforce console or app. It is not used for editing specific fields of a record from its feed. It's a navigation tool, not an editing tool.
Why D is Incorrect:
A Custom URL Formula field is a read-only field that displays a hyperlink. It cannot be used to edit the data on the record itself. Its purpose is to link to an internal or external page.

Reference:
Salesforce Help - "Add Actions to the Publisher Layout" and "Actions Overview". The documentation specifically promotes using actions for quick updates: "Create actions to make your users more productive. For example, add an action that lets users update a record... without navigating away from the page they’re on." This functionality is core to the Lightning Experience and Mobile App.

Explanation:

In the Salesforce1 mobile app (now part of the Salesforce mobile experience), navigation menus can be customized by profile. This means:

You can create distinct mobile navigation menus for different user profiles.
The App Builder can configure what tabs, objects, and apps appear for each team.
This allows sales and marketing teams to see different navigation names and layouts, tailored to their needs.

This is the only option that directly addresses the requirement to customize navigation menus based on team.

❌ Why the other options don’t work:
A. Create sales and marketing profiles to ensure read access to different objects
This controls data access, not navigation layout.
B. Create roles and assign homepage layouts
Homepage layouts affect desktop experience, not mobile navigation.
D. Create public groups and mobile menus
Mobile navigation menus cannot be assigned to public groups — only to profiles.

🔗 Reference:
Salesforce Help: Customize the Salesforce Mobile App Navigation
Trailhead Module: Salesforce Mobile App Customization

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.