Category: Power Platform

As I have a number of articles to write on Power Automate child flows, I’ve decided to break these out into a sub-series of the main Working with Power Automate series; they will appear as posts within both series in the order written, so you can easily access and read them from within either.

The series index, below, will automatically update if you’re reading the original article on azurecurve | Ramblings of an IT Professional. If you’re reading elsewhere, the original article, which will update automatically is here.

This article is part of the Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

Over the last couple of articles of this series, I’ve described scopes and shown how they are used.

That’s fine for the basics, but there are a few best practices I try to follow when I use them.

Not everything needs to be in a scope, so try to avoid going overboard. I would only add a scope when there are several related items, such as the document handling on OneDrive I showed in the example article I linked above.

Actions I would not put into a scope would include loops (called Apply to each in Power Automate) and calls to child flows (called Run a Child Flow) as well as the responses to a child flow.

Like all actions, I would recommend renaming the scope action to include a brief description of what the combined actions in the flow are doing and if more detail is required add a note, which is done by clicking the ellipsis button on the scope heading and clicking Add a note.

This article is part of the Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

In the previous article of this series, I explained what a scope in Power Automate was and what it did; in this post I am going to show an example of a scope.

This example is within a flow created to perform various tasks, one of this is to create a mail merge document and convert it to a PDF document, which is performed over a number of actions; in the below diagram, these are the actions after the condition and before the append variable one:

Continue reading “Working with Power Automate: Example of How to Use a Scope”

This article is part of the Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

I briefly introduced scopes in the last article of this series and thought I’d give a bit more detail on what scopes are and how they’re used.

Scopes in Power Automate are a type of action, but one which doesn’t do anything by itself.

Instead scopes are used to organise a flow, allowing you to group together related actions. As actions can be expanded and contracted, a scope allows you to control which scopes are expanded and the steps visible or not, making the view smaller when you close the scopes you’re not working on.

Scopes, like all actions, can be renamed so that they have a name which makes it clean what that action does; in terms of a scope, the scope name should clearly describe what the actions in the scope collectively do. For example, you might have a scope renamed to “Scope | Handle customer document on OneDrive”.

In addition, scopes can also be used to improve error handling (a topic I haven’t yet covered).Each action can have error handling attached to it for the result of that step, or, in the case of a scope, error handling for all the actions within the scope.

This article is part of the Working with Power Automate series I am writing on my experiences working with the Power Automate, which is part of the Power Platform from Microsoft. I also have a related series of articles on Power Automate with Microsoft Dynamics 365 BC.

While you can build a flow with as many steps as required, they will, in my experience, become more and more unwieldy the larger they become. This means the flow is both hard to navigate and difficult to maintain as you need to do a lot of scrolling and hold the structure in your mind.

There are two ways that you can make flows easier to understand and manage.

The first is through using scopes, which allows you to group steps together into logical groupings.

However, this does have it’s limitations as the steps within the workflow are still contained within the same flow, meaning you still have the same number of steps within the flow.

The second approach, and the one which I’d say forms part of the ALM (application lifecycle management) is child flows. As well as allowing you to break a flow down into multiple smaller flows, making them easier to understand and maintain, the individual child flows also become reusable so you can use them again and again without needing to create the same set of steps within every flow.

Over the next few articles of this series, I’ll run through scopes and child flows with some further explanation and examples.