Magic Tricks with the Power Platform

Pieter Veenstra

0 comments

When you get started in the Power Platform it sometimes looks like everybody else’s apps and flows are better than yours. In this eBook, you’ll learn 8 magic tricks to make your apps and flows more reliable, less complicated, and much faster.

What are magic tricks?

In Power Platform, you can use flow magic to help you make flows perform better. For example, can you make a flow run fast? There are different ways to call a flow from a Power App, which can have a marked and very noticeable impact on the performance and speed of that flow.

How can we make performance or flows better? We can use better APIs, but it’s all about creating that WOW moment. When you build a flow, you will go through a couple of steps and then think about what to do next. This is the logical way of developing, but sometimes you need a magic trick. That’s what this eBook is all about.

What is performance?

Performance is about running faster but also about handling all failures. If your flow fails very often, it doesn’t perform very well. Another important thing is the number of actions you’re running. Reducing the number of actions isn’t just about speed; it helps you understand the flow as well. If you have lots of actions and loops and it’s overly complicated, you might understand the flow now, but will you (or someone else) understand it in six months’ time? There might also be some licensing implications in reducing the number of actions.

Apply to each

Flows can sometimes be slowed down by ‘Apply to each’ actions, but there are things you can do to fix this. In the example flow below, there are three ‘Apply to each’ actions, but they haven’t been renamed, so it’s difficult to debug. It’s a good idea to rename ‘Apply to each’ steps – perhaps with the original name but adding to it, such as ‘Filter array – My test plan’ so you can easily distinguish between them.

‘Apply to each’ steps can be complicated – sometimes when you run a flow it will go halfway through, get stuck on ‘Apply to each’, complete the ‘Apply to each’ steps and then show you the actions inside the ‘Apply to each’ steps.

Nested Apply to each

In general, it’s a good idea to avoid all nested ‘Apply to each’ steps. This ‘Apply to each’ has been running for 11 seconds. You can’t see what’s happening inside there or how long it will take. This makes it very difficult to debug, improve, correct errors, or indicate early on that it is not working as intended.

This is just a simple, short flow, but imagine if you had a flow that was due to run for 8 hours, and you only found out at the end that the flow had a problem. Now you’ve got to fix your flow, rerun it, and then potentially find out it still didn’t run properly. That kind of debugging becomes very, very painful.

Trick 1: Use first() function

Let’s get rid of some of these ‘Apply to each’ steps. This flow collects all the teams it has access to and filters for ‘My Test Team’. We know there’s only one item there at the moment. If we could guarantee that just one team matches the query, we could replace this ‘Apply to each’ and just process the single item rather than an array of one. You can always replace arrays of one (somehow) using the first() function.

Now compare the original flow (on the left) with the flow using first() functions (on the right). The new flow is much clearer, with just four steps instead of nested data.

The Original one on the left is using nested ‘Apply to Each’ function in order to go through each one in the original array. The new on the right is looking at the array and using the First() function to get to 1 item or row of the array and then carrying out the actions required.

Taking a closer look at the branch on the right:

In the new flow, how do we turn the array that’s being processed in the first step into a single object? Here we can see the result of the filter action. We’re using a first() function to get the team id (Group Id) from the original array, so taking the ID from the first row in the array. If we were to have just selected the Dynamic Content of ‘Team ID’ from the array, the flow would assume there is more than one row and therefore automatically create us an ‘Apply to each.’ We know, however, there is one result in our array, so we are going to use the First function, so the ‘Apply to each’ is not needed and not created.

Then if we wanted these actions to happen on a known set of teams, ‘My Test Team 1’ and ‘My Test Team2’, we could repeat the process for each. Filter the array to ‘My Test Team2’, then list the plans using the ‘first()’ functions again, then carry out our actions. In this scenario, this can be more efficient than using the ‘Apply to each’ approach that Power Automate will try to use.

Trick 2: Use Select action

Here is a list task action in Power Automate that lists the task straight out of Microsoft Planner. It shows a list of tasks and lots of information.

The date (in createdDateTime) is quite ugly. We want a nicely formatted date.

We could use an ‘Apply to each’, process the whole thing, and use a ‘formatDateTime’ function to convert the date that we find (shown below).

Using a ‘Select’ action does almost exactly the same thing as the ‘Apply to each’. It takes in a value returned from the ‘List tasks 2’ action, then we have a Title and Created field. We use the ‘Select’ function to massage the data how we want it to be.

While we are simplifying it (by reducing the number of fields) we also change the format of the created field using the formatDateTime function. Rather than processing this through and applying to each step, we now have just one action. This means it will run a lot faster.

Trick 3: Pieter’s Method

Generally, it makes sense to avoid using ‘Apply to each’ altogether, but there is one reason why sometimes you might want to use them. In this example, we could use a ‘Select’ action, but it’s probably better to use an ‘Apply to each’.

Here we have a Compose action inside an ‘Apply to each’:

The Compose action doesn’t do a lot – it just takes data and spits it out. This means that for each item that is run through the ‘Apply to each’, it runs the actions inside the Compose action. For example, here we are formatting the Datetime. You would expect that, outside of the ‘Apply to each’, you can’t reference it, but actually, you can.

In a second Compose inputs field, we have entered: ‘outputs(‘compose’)’, referencing the first Compose action. You can’t find it in the dynamic data, but you can type it, so you can reference an action inside the ‘Apply to each’.

Any action that generates output can be referenced outside the ‘Apply to each’, but you can’t do that if you have nested ‘Apply to each’ steps. This is another good reason to remove as many ‘Apply to each’ steps as possible because they can really make your flow complicated.

What if your data comes from multiple places? The data that Microsoft Planner returns is actually quite horrible. You get a user field which is just a guid, a big, ugly number that represents my user account or somebody else’s user account.

So, we want to search for that user id using the ‘Get user profile’ action. In the ‘Compose’ action, we can use the output from the ‘Get user profile’ and create an array with the fields Title, Created and User in our first ‘Compose’ action.

We can then reference the output of that first ‘Compose’ in a second ‘Compose’ action to get an array but with those fields updated with meaningful data.

Remember you won’t be able to select the output data that is within the ‘Apply to each’ from the Dynamic data like you would for other items, but you can type it in, and it will show. E.g. for this example. Outputs(‘Compose’)

The user date will come out of the ‘Get User Profile (v2)’ action in a raw format similar to this:

The first ‘Compose’ action will clean the data for each entry, and the second ‘Compose 2’ action will take that output and put it into the array in the much cleaner format you can see below.

Trick 4: Variable vs Compose

When should you use, Variables or Compose actions? The purpose of this flow is to get lots of items from a SharePoint list – in fact, it’s a total of 100 items. We take each item and add it to an array. If we use an ‘Append to array variable’, it takes 30 seconds. If we use a ‘Compose’, it takes 26 seconds (as shown below). This saving seems hardly worth the bother.

If we enable the concurrency on these steps, we’ll see the real magic. The revised flow timings are shown below. The ‘Append to array variable’ is 16 seconds – much faster than without concurrency, of course – and the ‘Compose’ takes 4 seconds. That’s a lot faster! If we turn off the concurrency setting, the flow is noticeably slower. If we turn it back on and up to the maximum (50), it means, of the 100 items, the flow will process 50 items in one go, and that will speed things up quite a lot.

The concurrency setting is set against each action by clicking on the action in edit view, clicking the ‘…’ then ‘Settings’.

When we run the flow again, the ‘Apply to each’ with the ‘Append to array variable’ is slower as expected (15 seconds), but the Compose is only 2 seconds, which is a useful improvement.

Trick 5: REST API for SharePoint

The action ‘Send an HTTP request to SharePoint’ uses a REST API.

People think REST API is complicated, but it has lots of benefits. You can use it for anything you can do to SharePoint: creating a list item, creating a list, updating an item, setting permissions. Anything you could possibly think about doing with SharePoint you can do with REST API. There are lots of other actions, and that list is getting bigger and bigger and the need for the REST API call is potentially becoming smaller, but if you want to do things that are possible (but not available) you might need to switch over to the REST API calls. If we compare some actions, such as Update item, in the Connector, and REST API, it doesn’t make too much difference. Get items is almost identical.

However, if we look at Update item or Create item a bit closer, we find you can supply lots of fields in a long form. Imagine if you do an Update item and you don’t want to update the title. It’s actually a required field – would you want to do that? Not really. This form also becomes a little bit tricky when you have lots of fields, so it’s often easier to go for the REST API.

With the REST API, you have a long URL that you have to supply. First, the site number, then the URI for the endpoint you want to use. In the example, we want to do something with items in the test list. There are a couple of settings and, importantly, the title that you want to set.

So, all we want to do is update an item and set a title to ‘MyTitle’. The settings are quite important. ‘accept’ and ‘content-type’ are saying that you’re happy for your call to accept JSON and other formats, and that you’re going for ‘odata=verbos’. In fact, it’s easier if you don’t use odata=verbos. Instead, you could use odata=nometadata, and this makes the body much simpler.

Imagine if you wanted to update a list, and the list must be specified somewhere else in your flow or the site. In this case, we’ve created two Compose actions that collect the site URL and the list name, and you can then construct your REST API call. It will now work for any site, any list, and you can parse the parameters into your flow. You can also make your field name dynamic. If you want to update a field depending on values of data, you can do that using the REST API.

So, there are good reasons for using the REST API, but sometimes you might want to avoid it. If you look at ‘Create item’ action and you enter a dynamic site address, you can use pretty much the same syntax as the REST API does. A lot easier!

Even though it’s recommended to sometimes use the REST API, you may sometimes prefer to use an out-of-the-box action if it can do the same thing. Connectors permanently evolve. Keep an eye on them – even though today you might not be able to do something, tomorrow it might be possible.

Trick 6: JSON/Text and replace

This is a text replacement trick. In this example, a Compose takes the output from a List tasks action, but we want to replace the user id again. If you have a lot of data and are processing 100 items, imagine if you could do it all in one go – well, you can. We’re going to take the output from the List tasks action, but we’re going to turn it into a text string. We’ll take the long guid, replace it with a name, and then turn it back into a JSON object.

Just by calling this one expression within a ‘Compose’ action (or variable), all the occurrences of this guid will be replaced by the name. That’s a lot quicker than having to step through each one of the items.

In this example flow, we add expressions to a ‘Compose’. Whatever the output from the List tasks is turned into a text string.

When we run it, we can verify that we did the right thing. The output value of the ‘List tasks’ is where flow will identify this as a JSON object (or array in this case).

In the ‘Compose’, outputs is just plain text. It’s now ready for one text to be replaced with another.

We use the ‘Replace’ function and turn it back into a JSON object; in this case, we have used ‘xxxxxxxxxx’ as the replacement value just for demonstration.

Back in the flow, once we have done the replacement, this is all nicely formatted again, with plain text and the values replaced.

Trick 7: Expressions

Expressions can improve your performance an awful lot. Here is a SharePoint list with two fields: Title and Number, prepopulated with the numbers 1-10.

We want to filter, for example, all items that start with the letter ‘s’ and we want to total them up. We’re going to use the Select action to transform the data a little bit.

We want an array that, if the number is 1, shows us one character in a record. If we have the number 2, we want to see two characters, and so on.

This means if we use a substring function and we have a long string, the Select action creates an array of strings that represents all the numbers returned by the Get items action. The bigger the number, the longer the string is.

If we now join all the strings together and take the length of it, we have the sum of all the numbers in the SharePoint list.

When we run the flow, the first item in the array has one character, the second two, the third three, and so on. If we add 1 to 2 to 3 and so on up to 10, the sum is 55 (as shown in Compose – Sum).

This flow works well for low numbers (below 100-200 characters) and with approximately up to 1000 items.

Trick 8: APIs

You can use APIs directly. There’s an HTTP action, for example, that you could use to talk to APIs that we simply haven’t got connectors for yet. Or you could create a custom connector. You could even publish your custom connector to the ‘connector store’. Microsoft will then certify it and make it available as a standard connector. Also, you might find a lot of connectors are focused on citizen developer needs, whereas you may need the real technical stuff.

In one example, people wanted to enable and disable user accounts using a flow. There were no connectors that could achieve this, but it could be done using a Graph API call. Even though there’s no connector that can do what you need it to do, you could create a custom connector, and you could make an API call directly – you do have options. Good advice is to look through the connectors regularly and see what’s new.

0000-00-00 00:00:00


Leave a Reply

Your email address will not be published. Required fields are marked

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}