Praxis Academy
Home › Platform Administrator II › Process Automation

Platform Administrator II practice questions: Process Automation

Process Automation is 20% of the Salesforce Certified Platform Administrator II exam. It covers flow types, error handling, run order and approvals. Try these 8 free questions, then open each answer to see why every option is right or wrong.

01

In a Record-Triggered Flow on Opportunity, a Get Records element and an Update Records element are placed ahead of the first Decision element. What is the biggest risk of this design?

  1. The flow will fail, because Flow Builder does not allow Get Records and Update Records on the same path.
  2. Running DML (Update Records) before a Decision element makes every triggering record perform the update whether or not the update conditions are met -- needlessly consuming DML governor limits.
  3. Get Records will return only records the running user can see, leading to incomplete reads in automated contexts.
  4. Update Records will create duplicate records if the flow fires more than once for the same record.
Show answer

Answer: B

A. The flow will fail, because Flow Builder does not allow Get Records and Update Records on the same path.Incorrect. No such restriction exists; both elements can sit on the same path.
B. Running DML (Update Records) before a Decision element makes every triggering record perform the update whether or not the update conditions are met -- needlessly consuming DML governor limits. ✓Correct. Without an early Decision, the DML executes for every triggering record even when nothing needs to change, putting governor limits at risk.
C. Get Records will return only records the running user can see, leading to incomplete reads in automated contexts.Incorrect. Record-triggered flows run in system context by default and are not limited to the running user's access.
D. Update Records will create duplicate records if the flow fires more than once for the same record.Incorrect. Update Records modifies existing records and never creates duplicates; recursion is a separate issue.

Why: Best practice in Flow Builder is to filter with Decision elements early and run DML only when needed. Putting DML ahead of the Decision causes unnecessary updates and burns governor limits. The recommended order is entry criteria, then Decision, then DML elements.

02

For a given Account, a Flow must retrieve every related Contact, step through them, and send a custom notification only for Contacts whose email ends in '@enterprise.com'. Which two Flow elements are required? (Choose 2)

  1. A Get Records element that pulls all of the Account's Contacts into a record collection variable.
  2. A Loop element with a Decision element inside it that tests whether each Contact's email ends in '@enterprise.com' before the notification is sent.
  3. A Subflow element that calls another Flow to check the email domain of each Contact.
  4. A Create Records element inside the loop that logs every Contact that was notified.
Show answer

Answer: A, B

A. A Get Records element that pulls all of the Account's Contacts into a record collection variable. ✓Correct. Get Records queries the Contacts filtered by AccountId and stores them in a collection for the Loop.
B. A Loop element with a Decision element inside it that tests whether each Contact's email ends in '@enterprise.com' before the notification is sent. ✓Correct. The Loop walks the collection, and the Decision inside it checks the domain (for example with an ends-with condition or formula) for each Contact.
C. A Subflow element that calls another Flow to check the email domain of each Contact.Incorrect. A Subflow is possible but unnecessary; a Decision inside the main loop is simpler.
D. A Create Records element inside the loop that logs every Contact that was notified.Incorrect. Logging records is not part of the requirement, so Create Records is not needed.

Why: The pattern is Get Records (Contact collection) -> Loop (one Contact at a time) -> Decision (domain check) -> Send Custom Notification on the true outcome. Get Records supplies the data; Loop plus Decision supplies iteration and conditional logic.

03

Whenever an Opportunity's Stage becomes 'Closed Won,' a related Contract must be created automatically, with fields filled in from the Opportunity. Which declarative solution is recommended?

  1. Add a Validation Rule on Opportunity that asks users to create a Contract by hand when Stage = 'Closed Won.'
  2. Set up a before-save Record-Triggered Flow on Opportunity that runs when Stage changes to 'Closed Won' and creates the Contract.
  3. Create an after-save Record-Triggered Flow on Opportunity that fires when Stage changes to 'Closed Won' and uses a Create Records element to build the Contract with values mapped from the Opportunity.
  4. Put a Quick Action on the Opportunity page layout so reps can create a pre-filled Contract with a single button click.
Show answer

Answer: C

A. Add a Validation Rule on Opportunity that asks users to create a Contract by hand when Stage = 'Closed Won.'Incorrect. Validation Rules block bad data; they cannot create related records.
B. Set up a before-save Record-Triggered Flow on Opportunity that runs when Stage changes to 'Closed Won' and creates the Contract.Incorrect. Before-save flows run before the record is committed and cannot perform DML on other records such as a new Contract.
C. Create an after-save Record-Triggered Flow on Opportunity that fires when Stage changes to 'Closed Won' and uses a Create Records element to build the Contract with values mapped from the Opportunity. ✓Correct. An after-save flow can create the Contract with Create Records and populate it from the triggering Opportunity.
D. Put a Quick Action on the Opportunity page layout so reps can create a pre-filled Contract with a single button click.Incorrect. A Quick Action can prefill values but needs a user to click it; the requirement is fully automatic creation.

Why: After-save Record-Triggered Flows handle DML on other records once the triggering record is saved. The entry condition watches for Stage changing to 'Closed Won,' and Create Records builds the Contract with mapped values (Account, dates, amount). Before-save flows cannot create or update other records.

04

New users created with a particular profile must be added automatically to a specific public group. Which declarative tool can automate this?

  1. A Record-Triggered Flow on User that runs on creation and uses a 'Group Member' Create Records element to add the user to the group.
  2. An Auto-Assignment Rule that places new users with that profile into the chosen public group.
  3. An Apex trigger on User that fires on creation and inserts a GroupMember record linking the user to the group.
  4. No fully declarative option exists for profile-based public group membership; use a Platform Event-triggered Flow or Apex, or add users manually after they are created.
Show answer

Answer: D

A. A Record-Triggered Flow on User that runs on creation and uses a 'Group Member' Create Records element to add the user to the group.Incorrect. Per the source, the standard Create Records element in a User-triggered flow cannot reliably insert GroupMember records because of DML restrictions in that context.
B. An Auto-Assignment Rule that places new users with that profile into the chosen public group.Incorrect. Salesforce has no 'Auto-Assignment Rule' for public group membership.
C. An Apex trigger on User that fires on creation and inserts a GroupMember record linking the user to the group.Incorrect. An Apex trigger would work, but it is code, and the question asks for a declarative tool.
D. No fully declarative option exists for profile-based public group membership; use a Platform Event-triggered Flow or Apex, or add users manually after they are created. ✓Correct. Per the source, this is a known declarative limitation; the practical routes are Apex, a Platform Event-based approach, or manual assignment.

Why: Per the source, automatically adding new users to public groups is a declarative gap: flows triggered on User face DML restrictions on GroupMember. The suggested options are an Apex trigger on User, a Platform Event-based process, or manual assignment after creation.

05

A Flow must take a different path depending on the triggering Account's annual revenue tier: Low (<$1M), Mid ($1M-$10M) or High (>$10M). What is the recommended way to build this branching?

  1. Build three separate Record-Triggered Flows, one per tier, each with entry criteria for its revenue range.
  2. Use one Decision element with three outcomes (Low, Mid, High), each checking its Annual Revenue range, and route each outcome to its own logic.
  3. Put nested If-Else formulas in one Assignment element to compute the tier into a variable, then use that variable later in the flow.
  4. Use a Loop element that runs three times, testing a different revenue tier on each pass and running the matching logic.
Show answer

Answer: B

A. Build three separate Record-Triggered Flows, one per tier, each with entry criteria for its revenue range.Incorrect. Splitting one piece of logic across three flows adds maintenance and makes the automation harder to follow and debug.
B. Use one Decision element with three outcomes (Low, Mid, High), each checking its Annual Revenue range, and route each outcome to its own logic. ✓Correct. A single Decision element supports several outcomes, each with its own conditions, and the Default outcome catches anything left over.
C. Put nested If-Else formulas in one Assignment element to compute the tier into a variable, then use that variable later in the flow.Incorrect. Assignment elements set values; they do not branch the flow. A Decision element is the right tool for different paths.
D. Use a Loop element that runs three times, testing a different revenue tier on each pass and running the matching logic.Incorrect. Loops iterate over collections, not over a list of conditions.

Why: The Decision element is Flow Builder's branching tool. It evaluates outcomes in order and follows the first one whose conditions are met. Three named outcomes (Low, Mid, High) plus the Default outcome give a clean multi-branch structure based on fields, variables or formulas.

06

A Flow has a scheduled path that should follow up on Opportunities 7 days after the Close Date, but some qualifying Opportunities are never processed. The admin finds that their Close Dates were already in the past when the Flow was activated. What best explains this?

  1. Scheduled paths in Record-Triggered Flows only evaluate records created AFTER the Flow was activated; records that existed before activation are not evaluated retroactively.
  2. The admin must start the scheduled path manually for each Opportunity using a custom button.
  3. Scheduled paths exist only in Salesforce Unlimited Edition and are not supported in Enterprise Edition.
  4. The Flow must be reactivated every 24 hours for its scheduled paths to keep processing.
Show answer

Answer: A

A. Scheduled paths in Record-Triggered Flows only evaluate records created AFTER the Flow was activated; records that existed before activation are not evaluated retroactively. ✓Correct. Only records created or updated after activation are queued for the scheduled path; older records require a Scheduled Flow that queries them.
B. The admin must start the scheduled path manually for each Opportunity using a custom button.Incorrect. Scheduled paths run automatically and need no per-record trigger from a user.
C. Scheduled paths exist only in Salesforce Unlimited Edition and are not supported in Enterprise Edition.Incorrect. Scheduled paths are available in several editions, including Enterprise and Unlimited.
D. The Flow must be reactivated every 24 hours for its scheduled paths to keep processing.Incorrect. An active flow keeps processing scheduled paths without any periodic reactivation.

Why: Scheduled paths are queued only when a record is created or updated after the flow is active and meets the trigger. Existing records are not picked up retroactively. To catch up older records, use a separate Scheduled Flow that queries and processes them.

07

In a before-save Flow on Opportunity, the admin must stop the save when a business rule fails (for example, Stage is 'Closed Won' but Close Date is in the future). How should this be done inside the Flow?

  1. Use a Decision element to test the condition, and in the FALSE outcome add an Update Records element that sets a custom 'Block_Save__c' checkbox, which then fires a Validation Rule that blocks the save.
  2. Skip the Flow and use a Validation Rule on Opportunity, since Validation Rules are the purpose-built feature for blocking saves.
  3. Use a Decision element in the before-save Flow to test the condition, and on the failing path add a 'Custom Error' element (or 'Error Message' element) that shows an error message and stops the record from being saved.
  4. Force a 'Fault' by placing a Create Records element on the error path, generating a fault event that blocks the save.
Show answer

Answer: C

A. Use a Decision element to test the condition, and in the FALSE outcome add an Update Records element that sets a custom 'Block_Save__c' checkbox, which then fires a Validation Rule that blocks the save.Incorrect. This indirect workaround is unnecessarily complex; before-save flows do not use Update Records for this, and a Validation Rule is not needed to block the save.
B. Skip the Flow and use a Validation Rule on Opportunity, since Validation Rules are the purpose-built feature for blocking saves.Incorrect. A Validation Rule can block saves, but the question asks how to do it within the Flow.
C. Use a Decision element in the before-save Flow to test the condition, and on the failing path add a 'Custom Error' element (or 'Error Message' element) that shows an error message and stops the record from being saved. ✓Correct. The Custom Error element displays a message and blocks the save, similar to a Validation Rule error, while allowing more complex logic.
D. Force a 'Fault' by placing a Create Records element on the error path, generating a fault event that blocks the save.Incorrect. Fault paths are for unexpected errors; deliberately forcing a fault is not the way to validate. Use Custom Error.

Why: The 'Custom Error' element in record-triggered flows shows a user-friendly message and blocks the save when a condition fails, much like a Validation Rule. It is useful when the check needs complex conditions, related-record lookups or calculations that are hard to express in one Validation Rule formula.

08

The company wants a 'red flag' alert sent to the owner of any Opportunity that has had no logged activity (tasks or events) for over 30 days. Which Flow type and trigger fit best?

  1. A Record-Triggered Flow on Opportunity that runs on 'record is updated' with a scheduled path 30 days after the Last Activity Date.
  2. A Platform Event-triggered Flow that fires when a Last Activity Date platform event is published and notifies the owner.
  3. An Autolaunched Flow behind a custom button on the Opportunity page that reps click to check their own activity status.
  4. A Scheduled Flow that runs daily, queries every Opportunity whose Last Activity Date is more than 30 days ago (or blank) and whose Stage is not Closed, and notifies the owner of each match.
Show answer

Answer: D

A. A Record-Triggered Flow on Opportunity that runs on 'record is updated' with a scheduled path 30 days after the Last Activity Date.Incorrect. A scheduled path on update only starts when the record is edited; an inactive Opportunity may never be updated, so it would never enter the path.
B. A Platform Event-triggered Flow that fires when a Last Activity Date platform event is published and notifies the owner.Incorrect. Salesforce has no standard 'Last Activity Date' platform event; Last Activity Date is a standard field.
C. An Autolaunched Flow behind a custom button on the Opportunity page that reps click to check their own activity status.Incorrect. A button requires a user to act, so it is not an automatic alert.
D. A Scheduled Flow that runs daily, queries every Opportunity whose Last Activity Date is more than 30 days ago (or blank) and whose Stage is not Closed, and notifies the owner of each match. ✓Correct. A daily Scheduled Flow can evaluate all Opportunities for 30 days of inactivity, whether or not they were recently updated, and alert each owner.

Why: A daily Scheduled Flow suits proactive, time-based alerts across many records. It finds open Opportunities whose Last Activity Date is over 30 days old and notifies each owner. This is more dependable than a scheduled path, which only starts when a record is created or updated.

Find out if you're ready to pass

Take the free Platform Administrator II diagnostic: 20 questions, no account needed. Then unlock all 180 questions, full practice exams and the study guide.

Start the free diagnosticSee plans

Other sections of this exam