Reproducing and debugging issues that happen in your published app or in your live environments can be complex and time-consuming. It may be that the amount of data in your live system has grown and your data is now not presenting correctly (hint: delegation) in your app? Or performance has slowed down unexpectedly, and you need to understand why? Or a bug was introduced in your latest update? Whatever the reason, having a quick way to find the problem is invaluable. Debugging and understanding the events happening in your published app is our latest feature addition to Monitor.

 

To start debugging the published app, select an app from the app list in Power Apps and then select Monitor from the menu. In the Monitor, select Play published app. This will launch the published app in a new browser tab and connect it to your Monitor debug session. The Monitor starts capturing and displaying the events immediately from your app, including any warnings or errors that have occurred. Note, depending on when your app was last published, you may need to re-publish the app to connect it to the monitor.

 

You can also open Monitor from the Power Apps studio, just like you do today, and then select “Play published app” from the top menu in Monitor. If you open the published app using this method, you’ll have your app connected to the same Monitor session twice. The app being edited in Power Apps Studio and the published app in the web player. Events from both the Power Apps Studio and the published app will be shown in the Monitor if you interact with the app using both options at the same time.

 

Debug Published app setting

If you want to view the source expressions in the monitor for the published app, you need to turn on a new setting to publish the expressions with the app. This is like generating a debug file in traditional development. Some of you may not want to publish your source expressions with your app, and that’s OK. If you don’t turn this on, you will still be able to see the events happening in your app but you won’t be able to map these to specific expressions or formulas.

What else is new?

We’ve added new events and warnings in the Monitor, visual indicators for issues, and also new default fields in the events grid to help you understand the results of the various operations happening in your app.

Result and Result Info

201? 403? 429? Hmmm? Previously, to understand the status of network operations displayed in the event log, you needed to know what the various status codes meant. We are now translating these statuses into the Result and Result Info fields. For example, a 429 will show an “Error” result and “Too many requests” in the result info. Row colors also help to identify any errors and warnings quickly. We’ve started populating these fields for network requests, but we will be extending the Result Info to show other high level event information such as custom Trace messages and warning details soon.

 

Filter, LookUp, First, CountIf, CountRows

If a function can be delegated to a data source but it wasn’t, you will see a warning event in the Monitor. For example,  below we are using the LookUp function on a delegable data source. Lookup can be delegated, but it is using a selection formula that can’t be delegated. Because of this, only the first portion (default 500 rows) of the data source will be retrieved and then the function applied. This may cause unexpected results in the app as the LookUp is working against an incomplete data set, and your app may display incorrect results. It will also impact performance, as the data needs to be first downloaded to the client and processed locally vs the query being run on the server. These warning will help remind you of the delegation limits and possibly the need to switch to delegable alternatives.

 

Navigation and Screen Load events

As you play your published app, Navigation and ScreenLoad events can help you further understand your app performance and what screens are taking the longest time to load.  Depending on how your app is designed, you may also see an InefficientControlReferences performance warning.

Let’s dive into the InefficientControlReferences warning a bit more. To help improve performance, screens are only initialized and loaded in memory as they are needed. However, if you have formulas that reference controls on other screens, this can force the app to load these screens immediately (if they are not already loaded in memory), rather than waiting until the user navigates to that screen. This can cause performance issues by slowing down your screen navigation and you should try and remove these references. Using variables or collections to store the values you are referencing on dependent controls, or passing the values using screen parameters are ways you can work around this issue.

Viewing the details of the InefficientControlReferences event will tell you the cross-screen control dependencies that have caused the additional screen(s) to load. In the example, the employeeManager control on the Dashboard Screen references the managerName control on the employeeManagerScreen. There is also another control referencing the employeeDetailsScreen.

These cross-screen control references caused both the employeeManagerScreen and the employeeDetailsScreen to load when the “Dashboard Screen” was first navigated to and performance would have been impacted.

 

What’s next?

• Providing additional event details in the Result Info for Trace, delegation warnings and collection operations.
• Supporting Model-driven apps with performance telemetry events for page loads, form saves, command execution, network and script timings.
• Debug an end-user app session and view the events and any issues happening for that specific end-user as they are playing the app.

If you have any feedback, we’d love to hear it. You can provide it below, or on our community forum post.