Rollback Design for Failed SharePoint Actions in Power Automate
Short answer
AB Wrap the SharePoint Online item-creation actions in a Scope and set Run After to Has failed on a compensating step so the flow reverts the created items when any dependent action fails.
Question
If any of the dependent SharePoint Online actions fail, you must revert the changes while the automation runs.
You need to design the cloud flow to meet the requirement.
Which two actions should you implement for the design? Each correct answer presents part of the solution.
NOTE: Each correct selection is worth one point.
Key Takeaways
The tested concept is error handling via Scope plus Run After configuration, and the trap is believing SharePoint item writes can be transactionally reverted by a changeset request inside Power Automate.
This question covers how to build a compensating-transaction pattern in a Power Automate cloud flow that writes multiple SharePoint Online list items. Adding a Scope around the SharePoint actions and configuring a follow-up action with Run After set to 'Has failed' is the pair that enables rollback when any dependent item creation fails.
Common mistake: Learners often choose 'Perform a changeset request' (C), because changesets sound like database-style transactions. Power Automate's SharePoint connector does not create list items through an atomic changeset, so it cannot guarantee a revert of several independent item creations.
Expert Analysis
Why the Answer Is Correct
A Scope action groups the multiple SharePoint Online list-item creation actions into a single container whose overall status reflects whether any contained action failed. Once the main work is placed inside that scope, you add a second scope (or a cleanup sequence) and set its Run After property to 'Has failed' (and typically 'has timed out'). That configuration executes the compensating logic — deleting or correcting the items that were already created — whenever the primary scope fails, which is exactly the requirement to revert changes while the automation runs. This Scope + Run After failure pattern is Microsoft's documented approach for compensating transactions in cloud flows.
Why the Other Options Are Wrong
A changeset request (C) is an OData batch mechanism for SOAP/SharePoint web-service calls, and the Power Automate SharePoint connector does not create list items transactionally through it, so it cannot atomically revert several dependent item creations. Retriggering the flow run (D) simply re-executes the same automation and would re-create duplicate items rather than undo the partial writes. Note that 'Add a scope' alone is incomplete, which is why the question requires two selections — the scope must be paired with the Run After failure setting on the compensating step.
Community Comment Notes
The single submitted community comment, from exam_upskill, selected A and B, matching the Scope-plus-Run-After design described in Microsoft's flow error-handling guidance. The comment offers no additional reasoning beyond the option letters, so it should be treated as corroboration rather than as independent evidence. The vote pattern nonetheless aligns with the documented compensating-transaction pattern for cloud flows.
Exam Strategy
On Power Automate error-handling questions, look for the compensating-transaction pair: a Scope to contain the risky actions plus a Run After 'Has failed' step to perform cleanup. Avoid options implying true database transactions — Power Automate compensates rather than rolls back.
Frequently Asked Questions
Why is a changeset request not valid for reverting SharePoint list items in this flow?
Does adding a Scope alone satisfy the rollback requirement?
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 1
-
exam_upskill 👍 1A. Add a scope. B. Set Run After to Has failed.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.