Process Automation Accredited Professional — Practice Exam Set 1

Question 1

Salesforce's recommended declarative automation tool for new automation projects is:

Accepted Answer

Salesforce's current recommended declarative automation tool is Flow Builder. Workflow Rules and Process Builder are legacy tools being retired by Salesforce. Flow Builder has superseded both with more powerful capabilities. Apex Triggers are for code-based automation when declarative tools are insufficient.

Question 2

An admin is deciding whether to use a Before Save or After Save Record-Triggered Flow. Which two use cases require an After Save flow? (Choose 2)

Accepted Answer

After Save flows run after the record is committed to the database and can perform DML on other records or send external actions: creating child records (requires the parent record's ID, which only exists after save) and sending email alerts (external actions not available in Before Save context). Before Save flows run before the record is written to the database and can only update fields on the triggering record itself — they cannot create related records or send emails.

Question 3

Which automation tool is appropriate when the requirement is for a user to interact with a multi-step wizard to collect data and create multiple records in Salesforce?

Accepted Answer

Screen Flows present interactive UI screens to users, collecting input through questions, dropdowns, data tables, and other components across multiple steps. They can create, update, and delete records based on user input. Screen Flows are embedded in Lightning App Builder pages, Experience Cloud sites, or launched from Quick Actions. Record-Triggered Flows run automatically without user interaction. Scheduled Flows run on a time schedule. Approval Processes route records for approval.

Question 4

A company has both a Workflow Rule and a Record-Triggered Flow that both fire when an Opportunity is Closed Won and both attempt to update the same field. What is the likely outcome?

Accepted Answer

In Salesforce's order of execution, Before Save Flows run first, then Validation Rules, then After Save Flows, and then Workflow Rules (field updates trigger another evaluation). When both a Flow and a Workflow Rule update the same field, the Workflow Rule's field update (which runs after After Save flows in the initial save cycle) can overwrite the value set by the Flow. This is a critical gotcha when migrating from legacy automation to Flows.

Question 5

A Salesforce admin needs to choose between a Flow and Apex for an automation requirement. Which two scenarios favor choosing Flow over Apex? (Choose 2)

Accepted Answer

Flow is preferred when: (1) Creating related records based on trigger conditions — this is a straightforward Flow capability (Create Records element); (2) User-facing multi-step screens — Screen Flows are purpose-built for this with rich UI components. Recursive mathematical algorithms and real-time HTTP callouts are better served by Apex, which provides full programming language constructs and supports @future/Queueable/Callable patterns for callout limitations.

Question 6

In a Record-Triggered Flow, what does the 'Trigger Condition' determine?

Accepted Answer

The Trigger Condition in a Record-Triggered Flow specifies WHEN the flow fires in relation to the DML operation: 'A record is created', 'A record is updated', 'A record is created or updated', or 'A record is deleted'. This determines the entry point of the flow. The Run timing (Before or After Save) is a separate setting. Conditions inside the flow logic determine what happens after the flow starts.

Question 7

An admin creates a Record-Triggered Flow on the Opportunity object that should only fire when the Stage field changes to 'Closed Won'. Which Entry Condition configuration achieves this?

Accepted Answer

To fire only when Stage changes TO 'Closed Won' (not every time any field is updated): Trigger = Record is updated; Entry Condition = {!$Record.Stage} Equals 'Closed Won'; and critically, set 'Run only when a record is updated to meet the condition requirements' (formerly 'Only when specified changes are made'). This prevents the flow from re-running on subsequent updates when the Stage is already Closed Won.

Question 8

A Record-Triggered Flow running in After Save context needs to update a field on the parent Account whenever an Opportunity is created. Which element updates the Account record?

Accepted Answer

In an After Save Record-Triggered Flow, the Update Records element can update any related record using an ID from the triggering record. To update the parent Account, use the Update Records element with the filter condition ID = {!$Record.AccountId}. This performs a DML update on the Account in the same transaction. After Save Flows support cross-object DML operations, unlike Before Save Flows.

Question 9

A Scheduled Flow needs to send a follow-up task reminder 30 days after a Contact's Last Activity Date. Which two steps are required to configure this? (Choose 2)

Accepted Answer

Scheduled Paths in Record-Triggered Flows allow time-delayed actions: (1) Configure a Scheduled Path with the time offset (30 Days After) and the date/time source field (Last Activity Date on Contact); (2) The offset must reference a DateTime or Date field on the triggering record (Last Activity Date). The flow re-evaluates the entry criteria at the scheduled time before executing the scheduled path actions. A separate Scheduled Flow would not have access to the specific record's Last Activity Date in context.

Question 10

A Scheduled Automation Flow (not a Scheduled Path, but a standalone Scheduled Flow) runs nightly at 2am to update a Status field on all Opportunities closing in 7 days. What is the maximum number of records this flow can process per run?

Accepted Answer

Scheduled Flows (and Record-Triggered Flows) operate in bulk context. A Scheduled Automation Flow can process up to 250,000 records per run when Salesforce's Flow Runtime Scaling is in effect (the current default). The flow processes records in batches, with each batch interview processing one record at a time from a collection, subject to standard governor limits per transaction batch.

Question 11

In a Record-Triggered Flow, the {!$Record} variable and the {!$Record__Prior} variable are used for which purpose?

Accepted Answer

{!$Record} contains the triggering record's current values (what it is being saved as), while {!$Record__Prior} contains the record's previous values (what it was before this save). Using both together, a Flow can detect changes (e.g., if {!$Record.Stage} != {!$Record__Prior.Stage} then the Stage changed). {!$Record__Prior} is available in both Before Save and After Save contexts in Record-Triggered Flows.

Question 12

An admin needs a Flow to loop through a collection of Contact records and update an 'Outreach Status' field on each. Which two Flow elements are required? (Choose 2)

Accepted Answer

To process a collection of records in a Flow: (1) Get Records retrieves a collection of Contact records matching the criteria into a collection variable; (2) Loop iterates over each item in the collection one at a time, allowing the flow to process each Contact (e.g., update the Outreach Status field using Assignment elements, then add to an update collection). After the loop, a single Update Records DML operation updates all contacts in bulk (best practice to reduce DML operations).

Question 13

What is a Screen Flow used for?

Accepted Answer

Screen Flows create interactive UI experiences for Salesforce users. They display screens with input components (text fields, dropdowns, radio buttons, data tables, lookup fields) and guide users through multi-step processes. Screen Flows are ideal for data collection wizards, guided selling processes, case intake forms, and any scenario requiring user decision-making within an automation.

Question 14

A Screen Flow component showing a Salesforce record lookup field (e.g., Account lookup) is added to a screen. What component type supports this?

Accepted Answer

Flow Builder's Screen component library includes a Lookup component (Record Lookup) that provides a native Salesforce lookup field experience — users can type to search for records and select one by name. This populates an ID variable in the flow that can be used in subsequent Get/Create/Update Records elements. A Picklist with hardcoded values is not appropriate for dynamic record lookups across large datasets.

Question 15

An admin wants a Screen Flow screen to show a different next screen based on which option the user selects on the current screen. Which two Flow elements achieve this conditional navigation? (Choose 2)

Accepted Answer

Two approaches for conditional screen navigation: (1) A Decision element after the current screen branches the flow path to different screens based on the selected value; (2) Screen-level conditional navigation using the screen's 'When to Navigate' settings (available in newer Flow Builder versions) to control which screen the 'Next' button navigates to based on conditions. Both achieve conditional multi-path screen flows. Conditional Visibility shows/hides components on the SAME screen, not navigates to different screens.

Question 16

How can a Screen Flow be made available as a button on a Salesforce Lightning record page?

Accepted Answer

Screen Flows can be surfaced as Quick Actions on object page layouts. Create a Quick Action with Action Type = 'Flow' on the desired object, selecting the Screen Flow to launch. Add this Quick Action to the Lightning page's action bar or button group. Users can click the button to launch the Screen Flow in a modal overlay on the record page, with the record's ID automatically passed as an input variable.

Question 17

In Flow Builder, what is a Subflow?

Accepted Answer

A Subflow is a flow called by another flow using the Subflow element (formerly 'Call Apex' for code, but 'Subflow' for flow-calling-flow). Subflows enable modular flow design: common automation logic (e.g., 'create a follow-up task') can be built once as a reusable flow and called from multiple parent flows using the Subflow element, passing inputs and receiving outputs. This reduces duplication and improves maintainability.

Question 18

A Screen Flow is used by a call center agent to capture Case information. The admin wants the flow to pre-populate the Account Name field with the currently viewed Account's name. Which two configurations are needed? (Choose 2)

Accepted Answer

To pre-populate a Screen Flow with data from the current record: (1) Define an Input Variable on the Flow that receives the Account ID when launched from the Quick Action (Quick Actions automatically pass the record ID to an input variable named 'recordId' if correctly mapped); (2) Use a Get Records element at the start of the flow to fetch the Account's Name using the received Account ID. Quick Actions do not automatically pass all fields — only the record ID to the designated input variable.

Question 19

What happens to a record when it is submitted for approval in Salesforce?

Accepted Answer

When a record is submitted for approval in Salesforce, it is locked — only the approver (and users with 'Modify All' permission) can edit the record while the approval is pending. This prevents the record from being modified during the review process. The record remains on its object; it is not moved. Field updates (like setting a Status) can be configured in the Approval Process but are not automatic default behavior.

Question 20

An Approval Process has two approval steps in sequence: Step 1 = Manager Approval, Step 2 = VP Approval. If the Manager Rejects in Step 1, what happens by default?

Accepted Answer

When an approver Rejects an approval request in an Approval Process, the rejection triggers the Rejection Actions defined in that step and/or the Final Rejection Actions (if the rejection is final). These actions can include email notifications, field updates (e.g., setting Status back to 'Draft'), and Outbound Messages. The record is unlocked and returned to the submitter. The process does not continue to subsequent steps after a rejection.

Question 21

A company needs a parallel approval process where the record must be approved by BOTH the Legal team and the Finance team before it is fully approved. Which two configurations in the Approval Process support this? (Choose 2)

Accepted Answer

Parallel approval can be achieved two ways in Salesforce Approval Processes: (1) Configure multiple steps with no entry criteria between them so they both initiate simultaneously (parallel step configuration); (2) Within a single step, configure multiple approvers with the approval requirement set to 'Unanimous' so all designated approvers must individually approve before the step is considered approved. A separate process per team creates orphaned workflow chains without guaranteed synchronization.

Question 22

How can an Approval Process be automatically triggered without requiring the user to click 'Submit for Approval'?

Accepted Answer

Approval Processes are submitted either manually (user clicks 'Submit for Approval') or programmatically. A Record-Triggered Flow or Apex code can call the 'Submit for Approval' action on a record when specific criteria are met (e.g., when a discount exceeds 20% on save). This makes the approval submission automatic and transparent to the user. Apex uses Process.ProcessWorkitemRequest to interact with approval processes programmatically.

Question 23

When troubleshooting a failing Flow, which Salesforce tool provides a step-by-step execution trace showing which elements were evaluated and what values were assigned?

Accepted Answer

Two tools provide Flow execution traces: (1) The 'Debug' button in Flow Builder (Debug Run) allows running the flow interactively with test inputs and shows a step-by-step execution path with variable values at each element; (2) Apex Debug Logs filtered for FLOW_xxx log category events capture flow execution during real transactions. Both are valid for troubleshooting. The Debug Run in Flow Builder is easier for initial diagnosis; Apex Debug Logs capture production execution.

Question 24

A Flow that works correctly in the sandbox is failing in production with a governor limit error. Which two approaches help diagnose and resolve this? (Choose 2)

Accepted Answer

Production governor limit failures often occur because production has more data than sandbox, exposing limits that weren't hit in smaller datasets. (1) Apex Debug Logs reveal exactly which limit was exceeded (DML statements, SOQL queries, heap size, etc.); (2) DML inside loops is the most common Flow governor limit violation — refactoring to collect records in a loop and perform a single bulk Update Records after the loop is the fix. Governor limits cannot be increased per profile; they are platform-wide constants.

Question 25

A Record-Triggered Flow has an unhandled fault path. When the flow encounters an error during execution, what is the default behavior?

Accepted Answer

When a Record-Triggered Flow encounters an error without a fault path configured, the entire transaction is rolled back (the record save fails) and the user sees a generic error message. This is the default fault behavior for unhandled errors. To handle errors gracefully, admins should configure Fault Paths that catch errors, display user-friendly messages, or send admin notification emails. An email is sent to the admin only if a Fault Email is configured in Flow Settings.

AP-221 — Salesforce Certified Process Automation Specialist