As part of the Flow design process, I often end up building in some debug actions like Send email, Set variable etc. to capture/troubleshoot values that in turn help along with the actual design. But I’d want to retain those actions for debugging later rather than recreate them. Also when building/designing complex Flows I need to find failing actions and test or disable subset of actions.
Ideally, you want to be able to deactivate or skip a specific action or set of actions. Microsoft Flow does not have this feature available at this point of time. This requires you to either create a copy of the flow for testing purposes or debug by deleting actions only to realize later that those actions you just deleted weren’t causing the issue. This means you’ll need to re-configure those actions from scratch to restore your Flow design which can be time consuming.
Below are two approaches I’ve used and found useful for disabling/skipping actions for testing and debugging purposes.
Add a Condition control and set the condition logic to be something that would never return true (e.g. 2=1). Then drop the actions you’d want to skip under the true branch.
You could also invert the logic ( e.g. 1=1) so that the condition returns true and you can enable debugging or testing set of actions in ad-hoc manner.
Condition Control to Skip or Debug actions
Add a Scope control and drop action(s) you’d want to skip. Then configure the Scope control to run after the previous action failed or timed out. This way the Scope is never triggered and can be skipped. Now you can run the actions outside of this scope that you want to test.
This approach also allows you to capture information if the previous action failed and is ideal for debugging actions that cause you grief.
Configure Scope Control
Scope Control to Skip or Test Actions
These are quite simple approaches that can end up being very valuable not only during the design process but also for retaining and debugging when you need to troubleshoot Prod version of Flow for cause of failures. I like the Scope approach better since it eliminates the need to update or republish failing Flows or any disruptions while it’s actively being used. The Scope will run on failure if it’s placement is right after action(s) that you’d prefer to troubleshoot on failure.