Free Practice Questions for Salesforce Platform-App-Builder Exam

The correct answer is C. Custom object with Master-detail field to Opportunity.

AW Computing needs many help requests related to one Opportunity, so the help request should be a custom child object under Opportunity. Because the Opportunity page must show the most recent request date, the app builder needs a Roll-Up Summary field on Opportunity using MAX on the request date field.

Salesforce roll-up summary fields work on the master side of a master-detail relationship, and MAX can be used for date/date-time fields.

A is backward because the master-detail field belongs on the child object, not Opportunity.

B and D use lookup relationships, which do not support standard roll-up summary fields.

===========

The correct answer is C. Add the standard Chatter feed component.

To add Chatter feed functionality to a custom object Lightning record page, the app builder should use the standard Chatter component in Lightning App Builder. Salesforce documentation states that the Feed component was renamed Chatter in Lightning App Builder and is used to place the publisher and feed combination on a record page.

A is incorrect because no custom Chatter feed component is required. B is incorrect because related lists do not add the Chatter feed. D is incorrect because the standard Chatter component is already available; an AppExchange component is unnecessary.

===========

omprehensive and Detailed Explanation with all Platform App Builder documents: =

The correct answer is A. The report type is already based on Opportunities with or without Shipments, so the app builder should not change the report type’s primary object. To expose Account Rating, the app builder should edit the custom report type layout and use Add fields related via lookup from the Opportunity view, because Opportunity has a relationship to Account. Salesforce documentation confirms that custom report types allow fields from objects not directly included in the report type structure by using Add fields related via lookup.

Why others are incorrect:

B is incorrect because the standard Account–Opportunity relationship cannot simply be changed to master-detail.

C is incorrect because changing the primary object to Account would change the report purpose.

D is incorrect because adding a field to a record page does not make it available in a report type.

===========

If a new report type is created but users cannot select it, it is usually because the report type status is “In Development”. Salesforce only makes report types available in the Report Type list once they are deployed. (Salesforce Help)

B. Access to objects could prevent report creation, but the question assumes the user can create reports on records they own.

C. Deploye is the correct deployed state, which would make the report type selectable.

D. Create and Customize Reports permission is required, but the question specifies users are trying to create the report.

===========

The correct answers are B. Flow Builder and D. Escalation rules.

Escalation rules are the most direct Salesforce Service feature for this requirement. They are designed to automate case escalation when cases are not resolved or not acted on within a defined time period. Salesforce documentation explains that escalation rule entries can use business hours, and escalation actions can send notification emails when the case escalates.

Flow Builder can also be used because record-triggered flows support scheduled paths, allowing automation to run after a defined time from a triggering record event. A flow can check whether the Case is still in New status and then send a notification. For strict business-hour calculation, the app builder must design the flow carefully around the correct time source/business-hour logic.

A is incorrect because validation rules only prevent invalid data from being saved; they do not wait four business hours and send notifications.

C is incorrect for the Platform App Builder context because Scheduled Apex is a programmatic approach, while declarative automation tools are available and preferred for this requirement.

===========

Flow Orchestration is designed for sophisticated, long-running business processes that coordinate multiple flows, users, teams, and stages. Salesforce distinguishes ordinary Flow from Orchestration by describing flows as primarily record-centric, whereas orchestrations are user-centric and coordinate processes involving different people and different parts of an organization. Interactive orchestration steps can create work items and assign them to individual users, groups, or queues, making them suitable for onboarding activities distributed across multiple participants and days. A Screen Flow can guide one interactive session but is not the strongest choice for coordinating long-running work across multiple users. Entitlement processes are primarily service-management mechanisms, and a custom LWC would introduce unnecessary development. The multi-user, multi-stage nature of the requirement therefore directly aligns with Flow Orchestration. Salesforce

================

Path is the best solution because it provides users with a structured, stage-oriented experience based on a picklist field. For each Path step, an app builder can highlight key fields and provide Guidance for Success so users know which information should be captured and how to handle the record consistently. Salesforce officially documents that Path steps are based on selected picklist values and can display up to five key fields plus guidance, tips, links, and company policy information. This makes Path appropriate for helping service users consistently address Case Priority within a defined process. In-App Guidance provides contextual prompts but does not structure the record process in the same way. Flow is unnecessarily complex for simple user guidance, while Next Best Action is intended for recommendations rather than standardized field-entry guidance.

================

The correct answer is A. Highlights panel.

In Lightning Experience, record actions such as New Task appear in the Highlights Panel area of the Lightning record page. Salesforce documentation explains that the actions in the highlights panel come from the object’s page layout, specifically the Salesforce Mobile and Lightning Experience Actions section, unless dynamic actions are enabled.

Since the custom action was already added to the Mobile & Lightning Actions section on the page layouts, the app builder must add the Highlights Panel component to display those actions on the Lightning record page.

Activities shows activity timeline/composer-related functionality, but it is not where page-layout actions are generally displayed. Related Lists and Related Record do not display the main action bar.

===========

The correct answer is C. The user wants to update the related Account directly from the Opportunity page. The proper declarative solution is to create an Update a Record quick action for Account and expose it through the Related Record component on the Opportunity Lightning record page. Salesforce documentation identifies Related Record as a standard Lightning page component and notes that quick actions such as Create a Record and Update a Record are supported in Lightning page experiences.

Why others are incorrect:

A updates fields through automation, but the user wants to edit directly.

B formula fields are read-only.

D the Record Detail component is for the current record, not editing a related Account from Opportunity.

===========

The correct answers are A. Create a custom-based sharing rule and B. Update the organization-wide defaults.

Here, “custom-based” is most likely referring to a criteria-based sharing rule. UC wants to move from public sharing to a more restrictive model, so the app builder must first update the Organization-Wide Defaults for Accounts. Salesforce OWDs define the default access users have to records they do not own.

Then, to continue giving the Sales team access to all Account records with the Sales record type, the app builder should create a criteria-based sharing rule based on record criteria, such as Record Type. Salesforce criteria-based sharing rules share records based on field values.

C is incorrect because profiles control object permissions, not record-level sharing by record type.

D is incorrect because owner-based sharing rules share records based on record owner, not record type.

===========