Rollback Design for Failed SharePoint Actions in Power Automate
You are creating a Power Automate cloud flow. The cloud flow will create several SharePoint Online list items based on a variety of conditions. 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.
Community Insight
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.
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.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
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.Official Reference
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?
Power Automate's SharePoint connector does not create list items through an atomic changeset, so several independent item creations cannot be rolled back as one transaction; a compensating Scope is required instead.
Does adding a Scope alone satisfy the rollback requirement?
No. A Scope only groups the actions so failures can be detected; you still need a second step whose Run After is set to 'Has failed' to run the cleanup that deletes or corrects the created items.