Canvas App Troubleshooting – Part 1
Overview
In this blog series, we’ll discuss some strategies our support team use when troubleshooting issues in canvas apps. We’ll focus on strategies that any app maker can use to diagnose and fix issues in their apps. To illustrate, let’s start with a scenario.
Scenario: A Filter() statement that returns no items
Let’s say you have a gallery, and the Items property for the gallery is something like this:
Filter(MySharePointList, ContactEmail=cmbContacts.Selected.Email)
Where MySharePointList is a SharePoint list containing Departments in your company, and cmbContacts is a Combo box of possible department contacts, populated from an Excel spreadsheet.
Problem: the gallery isn’t showing any records. What could be causing this?
Break the formula into component parts
In the Filter() statement, we have three elements:
- The SharePoint list “MySharePointList”
- The column on that list “ContactEmail”
- The selected record cmbContacts.Selected.Email
Let’s interrogate each of these elements
Does the datasource have any rows that Power Apps can see?
This should be an easy test. In our example, we can simply set the gallery’s Items property to MySharePointList (no filter). If the unfiltered datasource populates some items in the gallery, then we know that there are rows present.
Looking good!
What data does the ContactEmail column contain?
It’s important to validate that the ContactEmail has some data in it, and what kind of data is in the column. You can actually see this data in the previous screenshot, but sometimes it helps to go right to the datasource (SharePoint) and see what’s present.
Now we know that this ContactEmail column has three possible values: [email protected], [email protected], or [email protected].
What is the value of cmbContacts.Selected.Email?
To check this, create a label and set its text property to cmbContacts.Selected.Email, so we can validate if that Email value looks correct.
Uh oh! That doesn’t look right. We have differing values for cmbContacts.Selected.Email and ContactEmail:
This seems to be our problem. If we investigate further, we’ll find that, while the SharePoint list has recorded the email address of these users, the Excel spreadsheet I used to populate my Combo box actually has the users’ UPNs, and those are not the same!
Taking it one step further
Here I want to introduce one of the sharpest tools in our toolbelt: Power Apps Monitor. There are resources available on Monitor, so I won’t go into every detail of using it.
Here I want to introduce one of the sharpest tools in our toolbelt: Power Apps Monitor. There are resources available on Monitor, so I won’t go into every detail of using it.
Debugging canvas apps with Monitor
Collaborative troubleshooting using Monitor
Advanced monitoring concepts
In our case, we want to capture a monitor trace while our gallery is loading, and try selecting some different filters via the Combo Box.
Once we have that captured, look for rows in the Monitor trace where the Control column matches our gallery’s name, and the Property column says “Items”. In my case, that would be the rows highlighted:
You will see that in my case these rows are coming in pairs. By clicking on a row with Operation “getRows”, I can see much more detail about the request to get this data from SharePoint.
I want to draw attention to the highlighted section on the right. This is the actual HTTP request the Power App is making to fetch relevant records from SharePoint. It looks a bit messy, but if we run it through a URL decoder a few times, we can get a legible result (I’ll be removing the SharePoint domain and replacing it with <MyDomain>):
https://unitedstates-002.azure-apim.net/apim/sharepointonline/<connectionId>/datasets/https://<MyDomain>.sharepoint.com/sites/TomJ/tables/949a20cb-5647-436f-a696-f609ea26a8f0/items?$filter=ContactEmail eq '[email protected]'&$top=100
This entire URL is packed with interesting information, but the part after “datasets/” is what concerns us right now.
https://<MyDomain>.sharepoint.com/sites/TomJ/tables/949a20cb-5647-436f-a696-f609ea26a8f0/items?$filter=ContactEmail eq '[email protected]'&$top=100
Here, you can see exactly the filter that is going to be applied when we query SharePoint: ContactEmail eq '[email protected]'. All it would take is a quick glance at SharePoint to confirm that there aren’t any items that will fulfill this condition. With a little knowledge of the SharePoint REST API, I can even turn this into an API query I can run in my browser:
https://<MyDomain>.sharepoint.com/sites/TomJ/_api/web/lists(guid'949a20cb-5647-436f-a696-f609ea26a8f0')/items?$filter=ContactEmail%20eq%20%[email protected]%27
And compare it to what the filter should be:
https://<MyDomain>.sharepoint.com/sites/TomJ/_api/web/lists(guid'949a20cb-5647-436f-a696-f609ea26a8f0')/items?$filter=ContactEmail%20eq%20%[email protected]%27
Takeaways
This scenario is inspired by a real case that came to our support team recently. The customer found themselves in a scenario I’m sure many are familiar with – supporting an app that was authored by someone else, with little documentation on how the app works. Of course, it would be easier if the app had come with documentation or robust inline comments, but often that is not the case.
The solution to this issue was ensuring that both sides of the Filter() expression were using the Email address, rather than one using Email and the other using UPN. In the course of troubleshooting, there were other possible causes we had considered, including:
- Maybe there were genuinely no records in the SharePoint list for the selected Contact
- Such records existed, but the logged-in user didn’t have access to them
- Perhaps ContactEmail and cmbContacts.Selected.Email were formatted differently and there are no exact matches
If the equality of ContactEmail and cmbContacts.Selected.Email were not the problem, then we would be in the realm of “issues that may not have a simple explanation”. If you find yourself reaching that point, it would definitely make sense to reach out to us at the Support team!
