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

Explanation:

Why Criteria-Based Sharing Rules Are Correct?
Criteria-based sharing rules are the best tool for this scenario because they allow you to share records based on specific field values. In this case, AW Computing wants to share Opportunities with the Type field set to “Service Agreement” with all users in the Service Manager role. A criteria-based sharing rule can be set up to check if the Opportunity Type equals “Service Agreement” and then grant read access (or more, if needed) to users in the Service Manager role.

For example, imagine an Opportunity record with Type = “Service Agreement.” The criteria-based sharing rule would automatically share this record with all Service Managers, allowing them to view it, even though the Opportunity object uses a private sharing model. This solution is declarative (no coding required), automated, and perfectly matches the requirement to share based on a field value (Type).

Why the Other Options Are Incorrect?

A. Owner-based sharing rules: Owner-based sharing rules grant access based on who owns the record, not based on the record’s field values. For example, you could use an owner-based sharing rule to share all Opportunities owned by users in the “Sales Team” role with the “Service Manager” role. However, this scenario requires sharing based on the Opportunity Type (“Service Agreement”), not the owner, so owner-based sharing rules don’t meet the requirement.

C. Apex sharing rules: Apex sharing rules involve writing custom code (Apex) to programmatically share records. For instance, you could write Apex to share Opportunities with Type = “Service Agreement” with Service Managers. However, this is unnecessarily complex because criteria-based sharing rules can achieve the same result declaratively, without coding. Apex sharing is typically used for complex sharing logic that can’t be handled by standard sharing rules, which isn’t the case here.

D. Manual sharing: Manual sharing allows users to manually share individual records with other users or roles. For example, an Opportunity owner could manually share a “Service Agreement” Opportunity with Service Managers. However, this is not automated and requires users to take action for each record, which is inefficient and doesn’t meet the requirement for automatic sharing when the Opportunity Type is “Service Agreement.”

Summary:
Criteria-based sharing rules (Option B) are the best choice because they automatically share Opportunities with Type = “Service Agreement” with users in the Service Manager role, based on a field value, in a private sharing model. Owner-based sharing rules focus on the owner, not field criteria; Apex sharing rules are overly complex for this task; and manual sharing isn’t automated, making it impractical.

Reference:
Salesforce Help: Criteria-Based Sharing Rules
This documentation explains how criteria-based sharing rules work, including how to share records based on field values like Opportunity Type.

Explanation:

To track the number of times a case has been reopened, you need a solution that can detect when a case's status changes to "reopened" and increment a counter field (e.g., a custom number field like Times_Reopened__c). Let’s evaluate the options:

A. Scheduled Triggered Flow:
This is the most suitable solution for modern Salesforce development. A Record-Triggered Flow (not specifically "Scheduled Triggered Flow," but likely a typo in the question for a record-triggered flow) can be configured to run when a Case record is updated, check if the status changes to "reopened," and increment a custom field. Salesforce recommends using Flows for declarative automation over Process Builder, as Flows are more powerful, flexible, and actively supported. You can create a flow that triggers on Case updates, checks the status field, and updates the counter field accordingly.
B. Screw Flow:
This is not a valid Salesforce term or tool. It seems to be a distractor or typo in the question.
C. Process Builder:
While Process Builder could technically handle this by triggering on Case updates and updating a counter field, it is an older tool that Salesforce is phasing out in favor of Flows. Process Builder is less efficient and harder to maintain for complex logic compared to Flows. As of 2025, Salesforce strongly recommends using Flows for new automation.
D. Apex Trigger:
An Apex Trigger could achieve this by writing custom code to detect status changes and update the counter. However, Salesforce encourages using declarative tools like Flows for such tasks unless complex logic requiring Apex is needed. Since this requirement can be handled declaratively, Apex is overkill and not the best choice.

Why Scheduled Triggered Flow?
The question specifies "Scheduled Triggered Flow," but in Salesforce, the appropriate tool is likely a Record-Triggered Flow that runs when a Case record is updated. A scheduled flow would run on a schedule (e.g., daily), which isn’t ideal for real-time tracking of case reopen events. Assuming the intent is a record-triggered flow, it’s the best choice because:
It’s declarative, requiring no coding.
It can evaluate the Case status change and update a field using simple logic.
It aligns with Salesforce’s modern automation strategy (replacing Process Builder).

Implementation Steps (High-Level):
Create a custom number field on the Case object (e.g., Times_Reopened__c).
Build a Record-Triggered Flow on the Case object, set to trigger on update.
Add a condition to check if the Case Status is changed to "reopened" (e.g., Status = 'Reopened' and PRIORVALUE(Status) != 'Reopened').
Use an Update Records element to increment Times_Reopened__c by 1.
Save and activate the flow.

References:
Salesforce Trailhead: Automate Your Business Processes with Flow Builder
Salesforce Help: Record-Triggered Flows
Salesforce Blog: Process Builder to Flow Migration

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