Whether it’s a Canvas Power App or any other technology, we always have challenges when it comes to reproducing and debugging an application in a Production Environment. There could be any reason such as:
- the amount of data has grown rapidly in our Production system
- performance has slowed down unexpectedly and we don’t know why
- the data is now not presenting correctly in our app like may be due to delegation in our Canvas App formula
- our latest deployed of newer version or bug fix has caused another issue
Whatever the reason might be, ultimately we need to find the issue and fix it as soon as possible and if we have some tool to do that then it’s a bliss.
Well, Microsoft has added some exciting features in the Power Apps Monitor to debug and understand the events that are happening in our published app.
Start the Monitor for a Published App
It’s pretty simple to start the Monitor for an App.
Select an App you want to monitor (debug) and then select Monitor from the menu. Then, 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.
Depending on when the app was last published, you may need to re-publish the app to connect it to the monitor.
Now, if you open the monitor from published app using Power Apps Studio, 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. Now, the 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, which might lead to some confusion.
What is ‘Debug Published app’ setting?
To view the source expressions in the monitor for the published app, we need to turn on a new setting to publish the expressions with the app. This is like generating a debug file in traditional development.
If we don’t turn this on, we will still be able to see the events happening in our app but we won’t be able to map these to specific expressions or formulas.
Some of the New Enhancements
Result and Result Info columns
Originally, the status field of the event contains the code like 200, 400, 404 and so on. Well now, the ‘Result’ and ‘Result Info’ fields translate the status information. For instance, a 429 will show an “Error” result and “Too many requests” in the result info.
Microsoft have started populating these fields for network requests, but they will be extending the Result Info to show other high level event information such as custom Trace messages and warning details soon.
Delegate Warnings for a Formula
Well, if a function can be delegated to a data source but it wasn’t, we will see a warning event in the Monitor.
For instance, lookup can be delegated on a data source, but what if 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
Navigation and ScreenLoad events can help us further understand our app performance and what screens are taking the longest time to load. Depending on how our app is designed, we may also see an InefficientControlReferences performance warning.
Let’s check out the InefficientControlReferences warning with an example.
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.
By viewing the details of the InefficientControlReferences event, we will know the cross-screen control dependencies that have caused the additional screen(s) to load. In the example, the L01_Welcome control on the Screen references the “Image1” control on the L03_Basics screen.
Upcoming Enhancements
Well, here are some of the further enhancement that Microsoft team is planning to add into the Monitor:
- 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.
Well, I am confident that every Power App developer and user, would like to try out this feature. It will be a huge help to the support team to debug, identify and resolve any production issue by reducing their turn around time.
Till next time, Cheers 😉
