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

The correct answers are C. Email Alert, D. Task, and E. Outbound Message.

In a standard Salesforce approval process, available approval action types include Email Alerts, Tasks, Field Updates, and Outbound Messages. Since Field Update is not listed in the answer choices, the three valid action types from the options are Email Alert, Task, and Outbound Message. Salesforce documentation identifies approval-process actions around task, email alert, field update, and outbound message automation.

A. Invocable Flow is incorrect because it is not a standard approval-process action type in this exam context.

B. Decision Element is incorrect because Decision is a Flow element, not an approval-process action.

===========

The correct answers are A. Unique and D. External ID.

The legacy ID should be marked as an External ID because Salesforce can use an external ID field to match records during import, integration, and upsert operations. Salesforce REST API documentation states that records can be inserted or updated using a specified external ID field.

The field should also be marked Unique so that the legacy system ID identifies one Salesforce Account record only. Salesforce documentation explains that an external ID can represent an ID from another external system, and uniqueness helps prevent duplicate matching values.

B is incorrect because encrypted text is not appropriate for a matching/upsert key.

C is incorrect because Required only forces a value; it does not make the field usable for upsert matching or prevent duplicate legacy IDs.

===========

The correct answer is A because Salesforce provides the Establish upper bound on existing picklists option to protect picklist performance by limiting inactive picklist values. Salesforce documentation states that this setting runs a query to identify picklists with fewer than 4,000 inactive values and enforce the limit.

Why others are incorrect:

B is for reusing picklist values across fields, not reducing inactive picklist performance impact.

C would worsen the issue because it removes limits on inactive values.

D is too drastic and not the recommended Salesforce feature for this issue.

===========

\

The correct answer is B. Use field-level security on page layouts with record types to restrict editing fields.

The requirement changes after the Opportunity is closed. The best configuration is to use record types with assigned page layouts so the closed Opportunity layout can make most fields read-only while allowing the Sales Operations team to edit the two post-close fields. Salesforce page layouts can control which fields are visible, read-only, or required, and page layouts can be assigned by profile and record type.

A is incomplete because it does not account for different behavior after close. C is incorrect because field sets are not used for page-layout field editability. D is too broad because it would make fields read-only for the Sales profile regardless of Opportunity stage.

Salesforce imposes a daily limit on mass and list email sent to external recipients. Current Salesforce documentation specifies a limit of 5,000 external email addresses per day per licensed org , meaning a recurring campaign to 7,000 contacts cannot be completed using standard Salesforce mass-email functionality in one day. Salesforce recommends considering a third-party mass-email solution from its marketplace when higher-volume sending is required. This corresponds to option B in the question. Requesting an arbitrary increase does not remove the standard product limitation. Exporting contacts to an external email client creates additional data-management and compliance concerns, while developing Apex and an LWC does not bypass Salesforce ' s applicable email limits. A purpose-built marketplace solution is therefore the appropriate scalable approach. Salesforce

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

Executing Get Records inside a Loop generates another SOQL query for every iteration. In bulk processing, that pattern can quickly exceed Salesforce ' s per-transaction SOQL governor limit. Salesforce explicitly documents that a Flow retrieving records from inside a Loop can consume one SOQL query per iteration and fail after exceeding the transaction limit. The correct bulkification pattern is to retrieve the needed records once outside the Loop, store them in a collection, and then iterate over the already-retrieved data. Changing from after-save to before-save does not eliminate repeated queries. A Fault Path can handle an error but does not prevent the governor limit from being reached. Replacing the Loop with Assignment is not appropriate when multiple items still require iteration. Moving Get Records outside the Loop resolves the root architectural problem. Salesforce

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

The correct answer is D. Create an Apex Trigger on the Account object.

The requirement is conditional: allow Account deletion generally, but block deletion when the Account has open Opportunities. A validation rule is not the correct tool because validation rules evaluate record data during save operations, while this requirement is specifically about preventing a delete operation.

An Apex before delete trigger can query related open Opportunities and call addError() on the Account record to stop the delete. Salesforce Apex documentation confirms that triggers can run before or after delete events, and trigger errors can prevent DML operations from completing.

A is incorrect because removing Delete permission blocks all Account deletion.

B is incorrect because removing the Delete button is not security and does not stop deletion through other channels.

C is incorrect because validation rules are not the right mechanism to block conditional deletes.

===========

Path is designed to give users a visual representation of a record ' s progression through a process based on a picklist field such as Status or Stage. Salesforce describes Path as an at-a-glance indicator that shows where a record currently sits in a process and where it is progressing next. For delivery tracking, the app builder can configure delivery statuses as Path stages and place the Path component on the Lightning record page. Related Lists display associated records rather than process progression. Details displays record fields, while Related Record exposes information from another related record. Because the stated requirement is specifically for a visual representation of delivery status, Path is the native declarative component that directly satisfies the requirement.

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

Flow Builder supports debugging a flow as another user, allowing an administrator to execute the flow under that user ' s profile, permission sets, object permissions, and field-level security. This is exactly what is needed to reproduce a permission-context failure. Salesforce documents the Run flow as another user option under Flow Builder ' s Debug functionality. However, Salesforce also specifies an important current-platform restriction: debugging as another user is supported only in a sandbox/non-production environment . Therefore, the intended solution is C, with the production flow first available in an appropriate sandbox for safe testing. Options A and D require involvement from the sales rep, while B analyzes an existing failure rather than actually reproducing it in the user ' s security context.

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

The correct answers are A. Flow Launcher and D. Quick Action.

A flow can be exposed to users through a page-based launcher/component. Salesforce Trailhead explains that users can access a flow by adding it to a Lightning page through Lightning App Builder. The Flow component can be dragged onto the Lightning page so users can run the flow from that page.

A Quick Action can also launch a flow. Salesforce documentation states that quick actions help users launch and navigate through workflows, and Trailhead confirms that custom actions can invoke flows.

Why others are incorrect:

B. Apex can invoke automation programmatically, but it is not the best user-facing access feature in this question.

C. Approval Process routes records for approval; it is not a general method for users to access flows.

===========