This book will show you 10 debugging tips you can use to improve and troubleshoot your Power Apps and Power Automate solutions. There are also some extra ‘bonus’ tips along the way…
Tip No. 1 – Environments
Environments are containers that allow you to group data, apps, and workflows within your Power Platform tenant. The example below shows a recommended way of using separate environments for development, testing, and a live production environment. This allows developers to develop solutions in the dev environment, which can then be exported to the test environment for a subset of users to test before being exported to the production environment.
This is a very simplified version of application life management, but if you want to find out more about how it can be used in the larger context of power platform adoption, you can access the Power platform Adoption Framework at https://aka.ms/ppaf.
Tip No. 2 – Results View
Formulas are used in Power Apps to control how controls function and how different parts of your app interact and behave. They are very powerful but can also be overwhelming, especially if you didn’t write them yourself. It can sometimes be difficult to work out exactly what a formula is going to do, but the results view can help you with this.
Take the below formula for example, which is used in an HTML control:
At first glance it can be difficult to see what the results of this formula will be, but if you click on the datasource name in the formula (in this case Accounts) and click the dropdown under the formula, the results view will show the data being loaded from that datasource:
You’ll notice that this datasource includes a number of different states in the address1_stateorprovince column. However, if you click on the Filter part of the formula, the results view will then update to show you the records that are being returned after being filtered. In this case only records with the state of Texas are being returned:
You can then move to the next part of the formula. Clicking on SortByColumns highlights that the formula is sorting the records by name in ascending order:
This is then again shown in the results view:
Finally, clicking on the concat and concatenate parts of the formula shows how the records are being wrapped in some HTNML code to turn them into a bullet point list:
The above example shows how using the results view for each section of a formula allows you to easily see exactly what is happening and what the end result will be.
Another useful use for the results view is in debugging data types. For example, did you know that the functions Now() and Today() return different datatypes? If you select the Now() function in a control you will see that the results view shows that it will return data of type DateTime:
However, doing the same with the Today() function show that it will return the Date datatype:
This way of using the results view to debug datatypes can help if you’re not getting the
datatype returned in your formulas that you’re expecting.
Lastly, you can use the results view to explore connectors in your app. In the example below, you can see the Microsoft 365 Users connector being used in a control:
The results view shows the display name of the current user, which will be displayed in the control. You can then explore other attributes that could be obtained from this connector by clicking one level up on the MyProfileV2() part of the formula:
Tip No. 3 – Hidden Documentation/Debug Panel
You can add documentation and debugging panels to your app but do so in such a way that they aren’t visible to users. This is especially useful for apps that you develop that will also be worked on by other developers as it allows you to pass information onto them. The example below shows a simple documentation panel that has been created using an HTML control, which is positioned outside of the app screen so anyone using the app won’t see it. It will only be visible in the design view:
You can also see that clicking the button in the app adds 1 to the number to the bottom left of the documentation panel. Again, this is a very simple example but shows that you can monitor what is going on inside your app by placing controls offscreen, which will only be visible to developers.
If you want more information about creating documentation and debugging panels, please visit Todd Baginski’s blog at https://toddbaginski.com
Tip No. 4 – Monitor
The Power Apps Monitor is a logging tool that allows you to view all the activity in your app in real-time, including information such as error messages, warnings, network calls and timings. In this section, the Northwind Traders sample app is used, which you can download from Microsoft at the link below:
The Power Apps Monitor tool can be accessed by clicking the Advanced Tools button on the left-hand menu and then click Open Monitor:
This will open a new monitoring session in a new tab in your browser. To start monitoring your app, you need to then go back to the Power Apps Studio tab and click the Play button to start your app. In this example, I then click the Load Data button:
As the data in the app starts to load, switching to the monitor session tab will show the corresponding details as each part of the datasource loads:
Once the Monitor has been running for a while, there may be many different events that have been picked up, and to help find the items you’re interested in; you can use the filter function. To do this, hover over the column header you want to filter by and then click the three lines to the right of the column name:
This will then display the filter panel where you can enter your filter query:
In the above example, clicking Apply will filter the monitor results to only show events with the operation type of getRows. Once the filter has been set on a column, clicking the Clear button will remove it. You can also sort by columns in the Monitor by clicking the column name.
To view more details about an event, you just have to click the row, and an information panel will pop out from the right-hand side of the page:
The details panel is split into four sections:
Details – a high-level overview of the event in JSON format
Formula – details of the formula/controls in the app that are responsible for the event Request – details of the network request that is being sent to the server from your app Response – the response returned to your app from the server
Once you have collected data from the Monitor you are able to download this as either a CSV file or as JSON:
Downloaded results can also be viewed in the Monitor by clicking the Upload button.
As well as monitoring your app while testing it in the Power Apps Studio, you can also monitor the ‘live’ published version of your app. To monitor a published app, you go to your list of apps in Power Apps, click the ellipsis to the right of the app name, and select Monitor:
This opens the monitor session in a new tab, and you have a button at the top of the screen where you can start your published app:
Bonus Tip No. 1 – Trace
The trace function can be used to send extra debugging and troubleshooting
information to the Power Apps monitor that wouldn’t normally be available natively. You can add trace information to any control in your app that has code associated with it (including screens or the app itself), and in the example below, I’m going to use a Timer control.
In my example, I have selected my Timer control and also selected the property of the control where I have code, in this case OnTimerEnd. The Trace function is then added to the code where you want it to trace events and has the following syntax:
Trace(message, trace_severity, custom_record )
On my Timer control I have added this function as follows:
In my code, the message will be a concatenation of **Loading: and a variable called Work, which is defined earlier in my app. The trace severity can be any one of critical, error, information, and warning, although this step is optional. You’ll notice I haven’t specified a custom_record step in my function. This is also optional, and I’m not going to go into it here, but if you want more information, please see the Microsoft documentation at the link below:
Once the trace is setup and the Monitor tool is opened, I can then see my custom trace messages being displayed:
Tip No. 5 – Test Studio
The other tool available in Advanced Tools is called Test Studio and can be accessed by clicking Tests:
Please note that at the time of writing this feature is experimental so isn’t recommended for production environments. You can find out more about it by clicking the Learn more link.
When you first open Test Studio, you will get the following message:
As the message states, in order for Test Studio to work properly you have to have formula-level error management enabled for your app. You can enable this by clicking the Go to app settings button and then go to Advanced Settings. If you then scroll to the bottom of the list of settings you will see the formula-level error management setting, which needs to be turned on:
Now, when you click on Tests under Advanced Tools, Test Studio will open:
Tests are made up of suites and cases. Cases are a series of test steps, and then each suite is a group of cases. Using a combination of suites and cases, you can create a very robust set of automated tests for your app.
The first thing to do in Test Studio is give your suites and cases descriptive names and descriptions. Once you’re ready, you can then add steps to your case by clicking the Record button. This opens your app with a red recording icon to show that Test Studio is recording almost all of the steps you take in your app:
As you perform actions in your app, you’ll notice that they are recorded as steps:
Please note that Test Studio does not record text entry. So, in the above example, it has recorded me clicking the search box in my app, but if I type a search in, this won’t be recorded. If you switch back to the Test Studio tab, you will see that these recorded steps are being automatically added to the selected case:
Bonus Tip No. 2 – Version Indicator
This bonus tip is going to look at the problem of knowing whether you’re seeing the latest version of your app. For example, you may make some changes to the code in your app, which although isn’t instantly noticeable to the end user, is still important. Once you’ve made the changes, you need to make sure that they have successfully published and are working on your app. It’s possible to look at the latest version number that is published in Power Apps Studio but when you’re actually in the app
there’s no way of seeing this information natively.
There are however, a number of things you can do to show in the app when changes have been made or new versions published. The first thing you could do is add a shape to the app. This isn’t suitable for production apps but is a useful way of tracking changes during development. All you do is add a simple shape to your app, such as a circle, and then every time you make changes to the app, you change the colour of the shape (in this case, a circle in the bottom right-hand corner of the app):
If you want, you can also restrict who sees the shape by setting the Visible property to only show if a particular user is logged into the app:
The second option is to add a label to your app that displays the version number. The advantages of this are that you can include major and minor version numbers as well as any other information you wanted to display, and it is also suitable for production apps. The downsides are that you would need to keep a record of your app version externally and manually update this label every time you published a new version.
The third option comes courtesy of Lachlan Wright, and details of this can be found in his blog at the link below:
This method uses an action called Get Versions in the Power Apps for App Maker connector, which can retrieve the latest published version of your app along with the date and time published. This can then be displayed in a label in your app and will update automatically each time you publish a new version.
Please note that this requires the PowerAppsForMakers connector, which may or may not be available to you.
Tip No. 6 – Manual Triggers & Test
Using a manual trigger in a flow that you’re developing allows you to run your flow quickly and test it iteratively. Once you’ve finished testing the flow, you can then replace the manual trigger with the actual trigger that will be used, such as an automated trigger or run the flow on a schedule.
To build your flow with the initial manual trigger, you can choose Create from the Power Automate home screen and then Instant Flow:
You can then give your flow a name (always try to make this as descriptive as possible) and then choose Manually trigger a flow from the list of triggers:
In the manual trigger, you can specify an input from the input types shown below. This allows you to test for inputs that will be added to your flow once it has been tested and is running automatically or on a schedule:
In this example, I’m testing a document approval process, so I want to be able to add a document as part of the manual trigger, so I choose File.
I can then build up the rest of my flow, as shown below:
Note that I have also used Compose actions in the condition stage as placeholders for whether the approval has been approved or rejected. This is for testing purposes and allows me to more easily check that the flow is running as expected when I’m testing it.
When I test the flow, I am prompted to manually upload a file, and this is the document that will be used as the approval document in my test:
I can then test the flow each time I make changes and add further stages etc, and this iterative process makes it much easier to troubleshoot any issues or look for improvements as I design and test my flow. Once everything has been successfully tested, the manual trigger can be replaced with the actual trigger that will be used.
To do this, you simply delete the manual trigger from your flow, but bear in mind the message that appears when you do this:
As the message states, any dynamic data provided by the manual trigger in your flow will be removed when it is removed. In this example, that would mean any data related to the file that is uploaded.
To make the flow automated, I replaced the manual trigger with a SharePoint trigger for when a file is uploaded to a folder:
To make sure my flow runs after making this change, I need to go through it and ensure that any dynamic data steps that were referring to the old manual trigger are replaced with the new trigger.
Tip No. 7 – Flow Checker
When designing flows, you will notice that there is a button in the top right-hand corner of the screen called Flow checker, and if there are issues with your flow, it will have a red dot on it:
When errors exist and you click the Flow checker button, or try and save your flow, it will display details about the errors that have been found:
If you click the error details, you will be taken to the step in your flow where the error exists so you can make the necessary changes:
Once you have resolved all the errors picked up by the Flow checker you will notice that the red dot disappears from the button, and you will be able to save the flow.
Tip No. 8 – Error Handling
No matter how well you design your flows, there will always be times when they fail, and you need to build in ways to deal with failures. You can view the run history of your flows by clicking on the flow name in My flows. In the example below, you can see that the flow has failed a couple of times:
Clicking on one of the failure rows will then give more details about why the flow failed:
Red icons in the actual flow steps also show exactly where the error occurred:
Using this information, you can add in some extra actions to your flow, which will help to deal with the error if it occurs again. In this example, I’m going to add an action after this Move file action, but it will only run if the Move File action fails. The action I’ve added is a Microsoft Teams action to send a message telling me that the flow has failed, but you could use any kind of notification action such as sending an e-mail:
I only want this message to be sent if the Move file action fails. To do this, I need to click on the ellipsis in my notification action and then click Configure run after:
This then allows me to specify when the action will run, and in this case, I change it to only run if the preceding action has failed:
Once this change has been made, you’ll notice an information icon and a red dotted
arrow between the two actions, which shows there is a condition in place:
It is also important to note that you must change the run after properties for the action after the notification action. In this case, I only want the next step of the flow to run if there was no error, so I make sure that it is configured to only run if the notification action is skipped:
Tip No. 9 – Send Notifications
If a tree falls in the forest and no-one is around, does it make a sound? To put it another way, if your flow fails and it doesn’t tell you, does it ever get fixed? The short answer is no, which is why this tip looks at sending notifications to let you, the developer, know if things go wrong in your flows. There are many ways of sending notifications, and we have already mentioned using Outlook and Teams, so this time we’ll be looking at the Notifications connector.
In this example, I have a flow that has three scopes within a condition. Scopes are a type of action in Power Automate that allow you to group actions together. They have been used in this flow to create a Try, Catch, Finally pattern:
In the first scope, I’m going to try and move a file from one location to another, and send a message via Teams if this is successful:
In the second scope, I’m going to catch any errors that occur in the first scope and
notify the flow owner via e-mail and mobile notifications:
The third scope then deletes the file that was uploaded, and this is slightly different
from previous examples in that it runs ‘rain or shine’. In other words, its run after settings have been configured, so it runs regardless of whether the previous steps have been successful or not:
If the first cope fails and the flow owner is notified, the mobile notification will be sent via the Flow mobile app (notice it’s still called the Flow mobile app and not Power Automate). More details about this and how to download it can be found at the link below:
I had a lot of help with the last two tips, so credit must go to the people below, and you should check out their blogs for more useful information:
Tip No. 10 – Parent-Child Flows
Why use parent-child flows? The table below outlines some of the pros and cons of single and parent-child flows:
|SINGLE FLOWS||PARENT-CHILD FLOWS|
|Everything in one flow||Difficult to debug||Reusable functionality||Requires solution|
|Does not require a solution||Complex error handling||Easier to debug||Planning required|
|Improved error handling|
|Easier to import/export|
The most important thing to remember when building parent-child flows is that you must design the flow first. This can be done using a whiteboard, pen and paper or software such as Visio. Once you know what both the parent and child flows will look like, you build the child flows first. Finally, build the parent flow.
As shown in the table above, in order to build parent-child flows, you must use solutions.
In this example, I’m using the sample Northwind Traders solution and have created two child flows along with a parent flow:
The steps in the parent flow are shown below:
The parent flow is being run manually for testing purposes. When it runs, it calls the first child flow, which gets an order number and then this is passed onto the next child flow, which uses the order number to get the order details.
These order details are then formatted as HTML and this HTML is added to the body of an e-mail as the final step.