Platform-App-Builder Practice Test Questions

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:

The solution that an app builder should use to meet this requirement is creating a custom report type with converted leads as the primary object.
A custom report type is a template that defines the objects and fields that are available for a report. The app builder can create a custom report type that has converted leads as the primary object and includes fields from related objects, such as accounts, contacts, and opportunities. This way, sales reps can create reports on converted leads and see their related information.

Option A is incorrect because enabling preserve lead status in the lead conversion settings does not affect the reporting on converted leads, but rather allows users to retain the original lead status after conversion.

Option B is incorrect because assigning the representative view and edit converted leads permission does not affect the reporting on converted leads, but rather allows users to view and edit converted lead records.

Option C is incorrect because ensuring the representative has read access to the original lead records does not affect the reporting on converted leads, but rather allows users to view the original lead records.

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:

A. Highlights panel:
This component, located at the top of the record page, displays key fields from the compact layout and shows the primary actions (buttons) that you have defined on the page layout.
D. Path:
This component displays a visual representation of a process (like a sales or support process) and can be configured to display specific actions relevant to each stage of that process. These actions are also defined in the page layout.

Why other options are incorrect
B. Chatter:
The Chatter component displays the Chatter feed and collaboration actions like Post, Poll, and Question. While it uses quick actions, it is not the component that displays the Mobile & Lightning actions defined on the page layout for tasks, events, etc..
C. Activities:
The Activities component (the Activity tab) displays the history and upcoming tasks, events, and logged calls for a record. It uses specific quick actions for creating tasks, events, and logging calls, but it does not display the general Mobile & Lightning actions defined in the page layout's action section.

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 order of operations in Salesforce is crucial to understanding this scenario. Salesforce executes validation rules after workflow field updates. Here is the step-by-step flow when the user saves the record:
User Action: A salesperson populates the Billing City field with "San Francisco" and saves the Account.
Workflow Rule Execution: The workflow rule evaluates and finds the criteria are met (Billing City equals "San Francisco"). It then performs its field update, setting the Industry field to "Technology".
Validation Rule Execution: After all automation (like workflow field updates) is complete, Salesforce checks all validation rules. The validation rule evaluates the Industry field. The value "Technology" is 9 characters long. The validation rule, which requires the length to be 6 characters or less, fails.
Result: Because a validation rule failed, the entire transaction is rolled back. The record is not saved, and the validation rule's custom error message is displayed to the user.

Why the other options are incorrect:
A. The record will save...: This is incorrect because the validation rule, which runs after the workflow update, will prevent the save.
C. The record will not save and no error message...: This is incorrect. Validation rules are always configured to display a custom error message to the user explaining why the save failed.
D. The record will save but the Industry field will not change...: This is incorrect. The workflow rule will execute and change the field, but this change will be rolled back when the subsequent validation rule fails.

Reference:
This falls under the Business Logic and Process Automation section. It tests the critical knowledge of the order of execution in Salesforce. A key concept is that validation rules are the final checkpoint before a record is committed to the database, and they evaluate the record after all automation (workflow field updates, processes, flows, etc.) has modified it.

Order of Execution Key Point:
Validation rules run after most automation (like workflow field updates, Process Builder, and auto-launched flows) but before the record is finally saved.

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:

Why: By default, when a user converts a Lead, validation rules on the target records (Account/Contact/Opportunity) don’t run unless the org enables the Lead Setting “Require Validation for Converted Leads” (previously known as “Enforce validation and triggers from Lead Convert”). If that setting is not enabled, Account validation rules won’t fire during conversion—so incomplete Accounts can slip through.

Why the others aren’t right
B. Not universally true—Account validation rules can run on conversion if the setting is enabled.
C. Misleading—this isn’t about users “intentionally” bypassing anything; it’s an org-level setting.
D. Leads (and tabs) are still deployed; this answer doesn’t address validation behavior.