Free Practice Questions for Salesforce Platform-App-Builder Exam

Changing the data type of custom fields in Salesforce has specific limitations that need to be considered to ensure system integrity and prevent errors:

A. It is not possible to change the data type of a formula field to any data type. Formula fields are calculated based on other field values and cannot be converted into a storage data type because they do not store data themselves.

D. It is not possible to change the data type of a Text Area (Long) field to Text. Text Area (Long) fields support up to 131,072 characters, which far exceeds the 255 character limit of standard Text fields. Converting such a field to a smaller capacity field would potentially lead to data truncation or loss.

For official guidance on data type changes, refer to Salesforce's Custom Field Considerations.

The requirement is to auto-populate the “Last Maintenance Date” field on the Asset record whenever a Maintenance-type Work Order is closed. This can be achieved declaratively using Flow — specifically, a Record-Triggered Flow that updates the parent record (Asset).

Why D (Flow) is correct:Exact Extract:“Record-triggered flows can update related records when specific changes occur, such as when a Work Order’s status is updated to Closed.” — Salesforce Help | Record-Triggered FlowsIn this scenario, the flow can:

Why D (Flow) is correct:Exact Extract:“Record-triggered flows can update related records when specific changes occur, such as when a Work Order’s status is updated to Closed.” — Salesforce Help | Record-Triggered FlowsIn this scenario, the flow can:

Trigger when a Work Order is updated to “Closed.”

Check if Type = “Maintenance.”

Update the related Asset record’s Last Maintenance Date field with the Work Order’s Closed Date.

Why not B (Roll-up Summary):Roll-up summary fields can only summarize numeric or date values using MIN, MAX, COUNT, or SUM, but only on Master-Detail relationships. Work Order → Asset is a Lookup relationship, so roll-up summaries are not supported natively.

Why not A (Einstein Next Best Action):NBA provides recommendations, not field updates.

Why not C (Apex Trigger):Apex could achieve this, but Salesforce recommends Flow first as a best practice.

 The app builder should recommend building a global action to create Contacts. A global action allows users to create records quickly from any page in Salesforce on their mobile devices. The app builder can also specify predefined values for some fields in the global action, such as Account Name or Phone Number, to make data entry easier for users. Option A is incorrect because customizing the mobile menu to move Contacts to the top does not help users create new contacts quickly or follow up later. Option C is incorrect because adding a compact layout to Contacts does not help users create new contacts quickly or follow up later, but rather shows them more fields on record detail pages or list views. Option D is incorrect because using Path and setting pre-defined values does not help users create new contacts quickly or follow up later, but rather guides them through different stages of a record.

Set up a delegated approver for the manager is the recommended solution to ensure all of the appropriate deals are reviewed and the leaderboard is up to date. According to the Salesforce documentation, “A delegated approver can approve records that are submitted for approval by users below them in the role hierarchy.” Forwarding the approval request to the manager’s assistant, having the manager log on and reassign the approval request, and using Process Builder to assign a delegated approver are not valid or feasible options.

The Highlights Panel in the Lightning Record Page displays key fields and record actions prominently at the top of the page, exactly as described in the requirement.

Why A (Highlights Panel) is correct:Exact Extract:“The highlights panel displays important fields and key record actions at the top of the record page in Lightning Experience.” — Salesforce Help | Highlights Panel

Why not B:Path is used to visualize progress through stages (e.g., Opportunity Stage), not display multiple fields.

Why not C:A custom component is unnecessary since the standard Highlights Panel fulfills the requirement.

Why not D:Accordion is used to organize information in collapsible sections, not display key fields at the top.

 Apex. This is correct because Apex is a programming language that can perform complex logic and manipulate data in Salesforce. Apex can be used to create a trigger on the opportunity object that copies the value of the billing state from the related account record when the opportunity is created, and prevents it from being changed afterwards. The other options are not suitable for this requirement because they either cannot copy data from a related object (formula field, roll-up summary field) or cannot prevent data from being changed (workflow).

Email alert, task, and invocable flow are three action types that can be used in an approval process. Email alert can send an email message to one or more recipients. Task can assign a task to a user or queue. Invocable flow can launch a flow that performs complex logic and actions

Managed packages from the AppExchange are designed to provide automatic updates, upgrades, and vendor support, minimizing the need for ongoing manual maintenance by the customer.

Why D (Managed Package from AppExchange) is correct:Exact Extract:“Managed packages are maintained by the provider and can be automatically upgraded. They’re ideal for apps distributed and maintained through AppExchange.” — Salesforce Help | Managed and Unmanaged Packages OverviewManaged packages allow publishers to push automatic updates and ensure compatibility with future Salesforce releases — minimizing maintenance effort.

Why D (Managed Package from AppExchange) is correct:Exact Extract:“Managed packages are maintained by the provider and can be automatically upgraded. They’re ideal for apps distributed and maintained through AppExchange.” — Salesforce Help | Managed and Unmanaged Packages OverviewManaged packages allow publishers to push automatic updates and ensure compatibility with future Salesforce releases — minimizing maintenance effort.

Why not A (Open-source custom development):Open-source code must be maintained internally by developers.

Why not B (Unmanaged package):Unmanaged packages are customer-controlled and do not receive automatic updates.

Why not C:Open-source unmanaged packages combine the same issue — no automated support or maintenance.

The new custom object (“Installation__c”) must store installation details that are related to an Opportunity. Since each installation should be tied directly to a single opportunity, and inherit ownership and visibility from that opportunity (as per “sales reps should have visibility”), a Master-Detail relationship is appropriate.

Why B (Master-Detail) is correct:Exact Extract:“In a master-detail relationship, the detail record inherits the sharing and security settings of its master record.” — Salesforce Help | Relationships OverviewBecause Opportunities already have ownership and sharing settings that determine sales reps’ visibility, making Installation__c the detail record ensures that sales reps automatically see related installations.Exact Extract:“The master-detail relationship closely links objects so that the master record controls certain behaviors of the detail record, such as record ownership, sharing, and deletion.” — Salesforce Help | Master-Detail Relationships

Why B (Master-Detail) is correct:Exact Extract:“In a master-detail relationship, the detail record inherits the sharing and security settings of its master record.” — Salesforce Help | Relationships OverviewBecause Opportunities already have ownership and sharing settings that determine sales reps’ visibility, making Installation__c the detail record ensures that sales reps automatically see related installations.Exact Extract:“The master-detail relationship closely links objects so that the master record controls certain behaviors of the detail record, such as record ownership, sharing, and deletion.” — Salesforce Help | Master-Detail Relationships

Why not A (Many to Many):Many-to-many relationships are only used when multiple records on both sides need to relate (e.g., Opportunities linked to multiple Installations and vice versa). That is not described here.

Why not C (Hierarchical):Hierarchical relationships are only available on the User object.

Why not D (Lookup):Lookup relationships do not automatically grant visibility or inherit ownership, so sales reps might not see all related installations.

References (Salesforce Platform App Builder documentation / Study Guide topics):

Salesforce Help | Relationships Overview

Salesforce Help | Master-Detail Relationships

Salesforce Platform App Builder Exam Guide | Data Modeling and Management