The Scope Action is not commonly used, but it’s a super important one. Overall it doesn’t change your Flow, but it provides context to your actions. Let’s imagine that you have a long Flow with a lot of actions. It would be useful to group them into logical blocks. If there’s an error, the scope action will display an error, and it will guide you into the “block” of failing actions. I wrote about the scope action some time ago, but I wanted to write about it in the reference because there’s more that we can explore.
Where to find it?
You can find it in the “Built-in” section under “Control.”
If you don’t see it right away, you can click the “Control” section, and you’ll see it.
Here’s how it looks like:
It’s a block that you can insert actions into.
Let’s start with a simple example:
In this case, we have 3 distinct blocks of actions:
- The first to get the information from a data source
- The second to parse the information in some way
- The third to save the new information
The above sequence of actions is quite clear and makes things much more readable and manageable. Imagine that you had a sequence of actions that did all of that. The result will be the same, but you would not know where the “parsing” ended and where the “save information” begins (not quickly, at least).
You can’t declare variables inside a scope. You can change them, but you need to be in the “root” part of the Flow to initialize them.
You can’t add triggers also.
Here are some things to keep in mind.
Name it correctly
Since the scope action encompasses some actions, it’s important to name it correctly. The name should be as descriptive as possible, but avoid using numbers to define the steps. The steps are either sequential (they don’t need numbers because they happen one after the other), they are in parallel (numbering doesn’t make sense since multiple things are happening), or there’s a branch (then it’s either one or the other).
Always add a comment.
Building upon the previous one, please add comments to your scopes. Since the name only gets you so far in describing what the context does. You can describe the expected input and output of the scope action, providing context to “future you.” Also, it’s important when debugging to understand the main point of the scope action if the result is not what’s expected.
Don’t put everything inside a scope.
The scope action is only useful if you provide a separation of responsibilities. If not, it doesn’t make sense to add the scope and put all actions inside it. There’s nothing to be gained in doing so.
Don’t be cheap on scopes.
There’s no major overhead in having scopes, so don’t put too many actions in a scope. Strive for less than 10. It won’t break above 10, but after that, you’ll have a complex scope. You’re trying to have a separation of responsibilities always to know what each block is doing, so don’t overcomplicate the scopes.
Don’t nest them
You can do it, but it doesn’t mean you should.
The mindset should always be simple, and nesting scopes make things harder to understand. Break them down into multiple scopes but don’t nest them unless you have a strong reason to do so.
Avoid putting a response or terminate inside scopes.
A Flow must be clear on what it does. If it stops in the middle of the Flow inside a scope action, it becomes difficult to debug. If you have exit conditions, be careful in putting them inside the scopes. It makes everything less readable.
With this, we continue with the separation of responsibility. The scope action takes care of saving the information and the response action for returning the information.
Don’t call other Flows.
For example, when you use the “Run a child Flow” action, put it outside the scope. This action already encompasses a lot of information inside another Flow, so it’s a kind of scope on itself.
Above, you can clearly see the 3 blocks of responsibilities. The “Run a Child Flow” signals clearly that the data will be parsed inside that “block” and will come out with some result that will provide to the next step.
Avoid “decisions” inside a scope.
Do it with care, at least. Having a Condition action, for example, outside a scope, will provide a clear path. Inside a scope, it may hide some of the logic that you’re developing. All of this boils down in the end to debugging. If something doesn’t go as planned, having the conditions at the “root” of the Flow will allow you to quickly scan and know where the Flow went with the data.
Back to the Power Automate Action Reference.