Variables and Looping in Microsoft Power Platform

Variables

Variables inflow are like having scratch paper or a whiteboard that you jot notes on when you know you need the info later.

Variables are initialised and then can be set, incremented, or decremented depending on their data type. They can be used in condition criteria, used to hold a value you plan to use later, for example in an update action, or other uses where you need to hold a value for later use. To use a variable, you must first initialise it. Search actions on “var” and you will see all of the variable actions.

When you use the Initialise variable action, it must be done at the top level of the flow. You can’t initialise variables in loops, conditions, or scopes. To initialise a variable, you are going to set the name, a type, and, optionally, an initial value. Once you choose your name, it is not recommended to change it, even though the editor will allow you. If you do change the name, you will need to update any flow steps that reference the variable to avoid errors when you try to save the flow. The following are the available types you can use: Boolean, Integer, Float, String, Object, or Array.

The initial value can be set to a static value, or to a value from a prior action. Additionally, you can use complex expressions to set the value. Then you are able to use that value without having to re-enter the complex expression each time. A good example of common use of this is if you need to retrieve the Common Data Service System User ID of the user that executed the flow. That would involve a number of actions to query the information and an expression to extract the ID field. Using a variable to store this would make it easy to use multiple times later in the flow. This example also demonstrates the use of a variable that is initialised but never used with any variable actions like a set, increment, decrement or append.

Once you have initialised a variable, when you choose any other variable action it will show up in the list of variables you can choose from in any other variable action. The list is filtered based on the type of variable so if you don’t see it listed it probably isn’t compatible with the action you are trying to use. The set variable action allows you to set a variable to a specific value. This can either be a static value like 1, or true, or “Contoso” or you can use the dynamic values panel to set it to a value from one of the prior actions.

Increment and decrement actions can be used to increase or decrease the value of the integer or float variable by the amount specified in the value on the action.

Append to strings and arrays also allow you to add the value you are working with to the end of the current value. For example, you might be building a list of emails and use append to string to build the list.

Variables can be used anytime later in the flow after they have been initialised. To use the variable, look for it in the dynamic content panel after you click into a field to set its value. The following is an example of using RecordCount in the condition action. Notice on the right the dynamic content panel shows a variables section with all the compatible variables.

Variables can be helpful to keep track of information as you progress through your flow. Look for opportunities to use them to simplify your flow, and to streamline your condition checking and value set.

Looping

Two of the constructs Microsoft Flow offers to do loop processing are the application for each and do until actions. Apply for each action executes for each item in an array and do until action executes until a condition is met. Both are examples of additional flexibility Microsoft Flow provides over classic Common Data Service workflow.

Using Apply for Each

The apply for each action can be used on any array of items. Common use with the Common Data Service is having a list records action to retrieve a set of records and then using apply for each to process the results. The following example sets the application for each to process each of the contacts retrieved by the ListAccountContacts action.

In the above example, the “value” is the array from the ListAccountContacts action and update a record will be invoked for each item in the array. When update a record is called, the context of any of the dynamic content bound to that action is set to the current item in the array. In this example, only one action was in the loop, but using the add an action multiple actions can be included.

You may find yourself with an apply for each being automatically added to your flow. This happens if you try to use a dynamic content item that belongs to an array. When this happens the Microsoft Flow editor automatically adds an apply for each and wraps your current action. If this happens and you didn’t mean to select an array item, remove the reference to the array item just added, drag your action outside of the apply for each, and then remove the auto-generated apply for each action.

Apply for each action does not have any ability to filter and only process some of the items on the array. Generally, it is best to filter those at the data source query, e.g. List Record from the Common Data Service and reduce to only the items you need to process. You can also use the filter array action to reduce the array content in the flow process. For example, if you only wanted to process the contact records that were located in Seattle, you could use filter action to create that subset and then apply for each to only the subset by referencing the filtered action output.

Using Do Until

Use the do until control when you want to loop until a condition occurs. The do until condition works similar to the standalone condition action only it is checked in a loop and controls if the loop keeps going. It’s important to note that by default the loop will only occur up to 60 times, you can increase the limit to 5,000 using the change limits section.

A common use for do until is to keep checking if something is done. However, beware of the common pitfalls when using values that come from an external connector like Common Data Service, in a condition of the do until action. For example, consider a scenario where you want to wait until a task is completed and then proceed to do more work. At first, you might think that you could trigger a flow when the task was created, and then simply use the do until action with a condition check that the triggering task is completed and use the delay action to wait between each condition check. The problem with this approach is that unless you get a record on the task each time in the loop the status value you received on the trigger of the flow will never be updated. The way to work around this is to do the condition check on a variable, retrieve the task record as one of the do until loop actions, and set the variable to true if the task is completed.