Debug Power Apps better with Monitor

Quite a while ago in 2018 I wrote about how to debug Power Apps. Then we still had to go through development steps just to understand what was happening in your app.

Available tools

Together with the Power Apps test tools it is becoming easier and better to debug your apps.

In this post I will go through the told to debug Power Apps. note that this feature is still in Preview, therefore you should be careful using this. But there is not a real reason why you can’t use this in your development environment.

Enabling the Debug Power Apps feature

To enable Debugging in Power Apps outside Power Apps studio you will need to enable the Debug published app experimental feature as shown below.

If you don’t need to debug apps outside studio then you can leave this feature disabled.

Monitor your Power apps

Then click on the open monitor and you will get the following blank screen opened in a new tab.

You can now wait forever but nothing will happen until you run your app.

Example app

I created an example app that lists the number 1 to 10 in a gallery.

I also have a timer control that shuffles the numbers using the Shuffle function every second. I will use this app to generate some actions that I can debug.

As soon as I run the app and my timer starts, the Power Apps monitor will pick up the code running in my timer. time to debug power apps.

The Monitor UI

Now that we are ready to debug Power Apps and I click on any of the lines in the monitor the screen it will split into 2 sections.

The Left hand side will show the following information about each line.

• The Time
• Category
• Operation
• Datasource
• Control
• Property,
• Response size
• Data

The right hand side will give further details.

And the Formula used.

And sometimes details on a request and its response.

Verbose debugging

If that is all not enough yet, you can also enable verbose debugging by selecting the verbose option just below the purple bar.

This verbose option will include the Telemetry lines showing details on http requests being sent.

Calling flows from Power Apps

This is where we can see the Request and the response.

My request is showing what was sent to Flow.

{
  "url": "https://uk-001.azure-apim.net/apim/logicflows/541d13027a264e208ef13196c187948e-4da32f4be74db047/triggers/manual/run?api-version=2015-02-01-preview",
  "method": "POST",
  "headers": {
    "x-ms-user-agent": "PowerApps/3.20054.18 (Web AuthoringTool; AppName=<NonCloudApp>)",
    "x-ms-client-session-id": "7969eab7-a666-4936-8001-055b3d9116a0",
    "x-ms-client-request-id": "00f351ef-f6b5-47fe-9ce9-99c1a318e1d7",
    "Accept-Language": "en-US",
    "Accept": "*/*",
    "Cache-Control": "no-cache, no-store",
    "x-ms-request-method": "POST",
    "x-ms-request-url": "/apim/logicflows/541d13027a264e208ef13196c187948e-4da32f4be74db047/triggers/manual/run?api-version=2015-02-01-preview"
  },
  "body": ""
}

And the response is

{
  "duration": 421.51,
  "size": 404,
  "status": 502,
  "headers": {
    "Cache-Control": "no-cache",
    "Content-Length": 404,
    "Content-Type": "application/json",
    "Date": "Thu, 04 Jun 2020 16:08:09 GMT",
    "expires": -1,
    "pragma": "no-cache",
    "strict-transport-security": "max-age=31536000; includeSubDomains",
    "timing-allow-origin": "*",
    "x-ms-apihub-cached-response": true,
    "x-ms-client-tracking-id": "08586103199957470005347125871CU14",
    "x-ms-correlation-id": "5497c446-3919-4579-a4e7-89ebe982bf31",
    "x-ms-execution-location": "uksouth",
    "x-ms-failure-cause": "trigger",
    "x-ms-ratelimit-burst-remaining-workflow-writes": 6427,
    "x-ms-ratelimit-remaining-workflow-download-contentsize": 460174336,
    "x-ms-ratelimit-time-remaining-directapirequests": 42856814,
    "x-ms-request-id": "uksouth:5497c446-3919-4579-a4e7-89ebe982bf31",
    "x-ms-tracking-id": "5497c446-3919-4579-a4e7-89ebe982bf31",
    "x-ms-trigger-history-name": "08586103199957470005347125871CU14",
    "x-ms-workflow-id": "56e87932a910438bb9b03e2f6a45c0e6",
    "x-ms-workflow-name": "541d1302-7a26-4e20-8ef1-3196c187948e",
    "x-ms-workflow-run-id": "08586103199957470005347125871CU14",
    "x-ms-workflow-system-id": "/locations/uksouth/scaleunits/prod-25/workflows/56e87932a910438bb9b03e2f6a45c0e6",
    "x-ms-workflow-version": "08586115540418771010",
    "x-ms-client-request-id": "dff23d9b-5a1e-4818-8b14-253d08a3f8cd"
  },
  "body": {
    "error": {
      "code": 502,
      "source": "uk-001.azure-apim.net",
      "clientRequestId": "dff23d9b-5a1e-4818-8b14-253d08a3f8cd",
      "message": "BadGateway",
      "innerError": {
        "error": {
          "code": "NoResponse",
          "message": "The server did not received a response from an upstream server. Request tracking id '08586103199957470005347125871CU14'."
        }
      }
    }
  }
}

Ok, now we have something to get started with.

Then after I fixed my flow issue I found a flow call that returned the 200 code rather than the 502 code that I initially received.

Being able to get under the hood of the no code platform can be so important to speed up development.

Add your own tracing

Ok, now you’ve got your code reporting all sorts of debug to your monitor tools. But what if you want more specific information in your logs that isn’t reported by any of your code.

e.g. you want to know who is logged in.

So I added a button to report the user’s name

And my report comes back.

Let’s zoom in on that a bit

You can see the severity and the Name property that I created and the Message.

Trace function

What can we do with the trace function?

Looking at the syntax description:

Trace(message, trace_severity, custom_record )

• Message – Required. The information to be traced. In tests, this creates a record in the Traces table in the TestCaseResult record.
• Trace_severity – Optional. The severity level of the Trace recorded in Application Insights. Options are TraceSeverity.Information, TraceSeverity.Warning or TraceSeverity.Error.
• custom_record – Optional. A record containing custom data that will be recorded in Application Insights.

The message parameter is quite easy. This will appear in your monitoring tool. The trace severity is harder. Earlier I guessed that Error would have been an option. What other severity levels are there?

Currently you can use:

• Information
• Warning
• Error

Other than in the details of a line in the monitoring tool you can’t see this anywhere yet.

Get Help

So what happens if you developed a Power app and you need some help? You can now send an invite to a colleague to help you debug your app.

Just click on the Invite button and supply the details of the colleague and they can help you debug your app.

That is as easy as it can get.

Your experiences

Have you tried the debugger yet? Have you found any unclear error message? Do you need any help then please leave a comment below.