Free Salesforce Platform-App-Builder Practice Exam with Questions & Answers | Set: 8

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.

===========

The correct answer is C. AppExchange package.

The key word is daily. Salesforce’s native Data Export Service supports manual and scheduled exports, but Salesforce documentation states that backup files can be generated manually once every 7 days for weekly export or 29 days for monthly export, depending on edition. That does not meet an automatic daily backup requirement.

For daily automated backups, the app builder should recommend a backup solution from AppExchange. Report export is not an org backup, and refreshing a full copy sandbox is not a backup automation tool.

===========

The validation rule must fire when two things are true:

Job_Accepted__c is already populated

Hire_Date__c is being changed

Salesforce’s ISCHANGED() function returns true when a field’s value changes from its previous value, and formula functions can be used in validation rules.

So this formula prevents users from changing the hire date after the candidate has accepted the offer:

NOT(ISBLANK(Job_Accepted__c)) & & ISCHANGED(Hire_Date__c)

Why others are incorrect:

The other options either use the wrong logical operator or validate the opposite condition. A validation rule must return TRUE only when Salesforce should block the save.

===========

The correct answer is C. Unable to reference the child records.

A formula field on Account cannot directly pull data from multiple related Contact records because Contacts are child records of Account. Cross-object formulas work by referencing fields through supported parent relationships, not by traversing from a parent record down to multiple child records. Salesforce documentation describes cross-object formulas as formulas that reference fields on related objects, especially parent records through relationships.

Because an Account can have many Contacts, Salesforce does not expose that child relationship in the formula editor as a single field reference. For summarized child data, the app builder would normally use a roll-up-style solution where supported, or automation such as Flow.

A is unrelated unless the formula has already exceeded character limits.

B is misleading because the core issue is not simply that Account and Contact lack master-detail; it is that formulas cannot directly reference child records.

D is not supported by the scenario.

===========

The correct answer is C.

A junction object is commonly created with two master-detail relationships. Salesforce documentation states that sharing access to a junction object record is determined by the user’s access to both associated master records and the sharing setting on the relationship fields.

Here, Account Interest is the junction object between Account and Interest. If users do not have read access to the Interest object, they cannot view the Interest records. Because access to the junction object depends on access to both master records, they also cannot view the associated Account Interest records.

Why not others:

A is wrong because lack of read access to Interest does not give read-only access automatically.

B is wrong because the user can still view the Account if they have Account access.

D is wrong because junction object access is not simply “show junction but hide Interest details.”

===========

Use a Roll-Up Summary field on Account to count the related Opportunity records. Salesforce roll-up summary fields can calculate values from related records, and the COUNT summary type totals the number of related records. Trailhead also gives the Account and Opportunity example for roll-up summaries.

A formula field cannot count child records by itself. A lookup field only creates a relationship. AppExchange is unnecessary for this standard use case.

===========

The correct answer is C.

The Lightning record page already supports both mobile and desktop, but the downloaded custom component is not visible on mobile. That points to the component itself, not the page activation. Lightning components must be configured to support the required form factors. Salesforce developer documentation explains that components can be configured for desktop form factor Large, phone form factor Small, or both.

So, if the AppExchange component was built only for desktop pages or only supports the large form factor, users cannot view it in the Salesforce mobile app.

A and D are incorrect because the issue is not page activation if the page already supports mobile and desktop. B is incorrect because the scenario states the record page supports both mobile app and desktop.

===========

This question is testing the classic Salesforce Process Builder automation best practice , not a generic Flow-only rule. Salesforce’s official process design guidance states that an org should have only one record-change process per object . The reason is simple: every time a record is created or updated, Salesforce evaluates the record-change processes for that object. If an object has multiple record-change processes, the automation becomes harder to predict, harder to troubleshoot, and more likely to hit governor limits. Salesforce specifically explains that consolidating automation into one record-change process gives admins a single view of all criteria and actions for that object, reduces duplicated automation overhead, and allows the app builder to control the order of criteria evaluation.

A is not the best exam answer here. In modern Flow architecture, “one Flow per object” is often discussed as a design pattern, but it is not the exact best-practice wording being tested by this Platform App Builder-style question. Salesforce Flow design is more nuanced today because record-triggered flows can vary by trigger timing and event. B is wrong because validation rules should be separated by validation requirement, not forced into one rule per object. C is wrong because invocable processes are reusable modular processes, not the main record-change automation container.

Flow Trigger Explorer is specifically designed to manage the execution sequence of record-triggered flows for the same object and trigger category. Salesforce documents that changing a flow ' s order in Flow Trigger Explorer changes its Trigger Order value, and that this value determines the sequence in which applicable flows execute. Therefore, the discount calculation flow should receive the earlier/lower trigger order and the notification flow the later order. This preserves separate flows while guaranteeing deterministic sequencing. An asynchronous path does not provide the same explicit ordering contract. A zero-minute scheduled path unnecessarily changes transaction timing. Combining both flows violates the stated ownership requirement and is not necessary because Salesforce provides native trigger-order controls. The correct Platform App Builder solution is therefore Flow Trigger Explorer.

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

The correct answer is A. Page structure will automatically adapt to the device being used to view the record page.

When choosing a Lightning record page template, the app builder should consider how the template displays across supported devices. Salesforce Lightning pages are designed for Lightning Experience and the Salesforce mobile app, and Salesforce documentation states that the chosen template controls how the page displays across devices.

B is incorrect because users do not need “View All Data” just to view a Lightning record page; normal object and record access applies.

C is incorrect because Salesforce supports switching Lightning page templates, subject to template-switching considerations.

D is incorrect because the app builder does not create a separate template for every device type.

===========