Thursday, February 28, 2019

PowerApps user filtering gotcha against SharePoint


PowerApps has for a long time supported filtering SharePoint data based on a person – the typically scenario in a PowerApps being that you want to fetch data rows based on the logged in user in PowerApps.

If you look at the post they have a sample along the lines of:


Issues is a SharePoint list and AssignedTo is people field, containing the person an issue is assigned to.

The issue with this sample is that User.Email() actually returns thee user principle name (UPN), and not the e-mail address, and the value is also always in lower case. For most users this does not represent a problem, but for some it might. If your e-mail address is, the UPN could be, thus the filtering would fail as it’s case sensitive.

The solution is to filter on the Claims property for a person field in SharePoint instead of Email.

What I typically do is that in the application OnStart event I set a global variable where I prefix the UPN with the default claims prefix.


The filter command then turns into:


Happy PowerApp’ing!

Monday, February 11, 2019

Locate pages where a particular web part is being using on modern SharePoint sites

close up photography of LED bulb on sand

This post was inspired by, but I’ve simplified things a bit as some of the steps are not needed. I also opted to use PnP PowerShell.

There is no defined API to find usages of specific SharePoint Framework web parts on modern pages. But fortunately for us the id of each web part is included in the searchable content for modern pages (no need to map up a particular refinable string for this as per the inspired post).

Note: Only pages you have access to will be listed – if you need all pages you can elevate search permissions using app-only permissions, which is (dangerous) different story.

Tuesday, February 5, 2019

Eh??? Ok? Beware of casing when using automatically created managed properties in search


I’m not sure this is intentional or not, but something you really need to pay attention to if you develop search based solutions in SharePoint Online (afaik it does not impact search for on-premises).

Up until recently(?) all managed property names were case insensitive. The change now is that automatically created managed properties based on site columns ( – those ending in OWS<something>, are now case sensitive. The others work as before.

If you for example create a site column of type number named MyFoo, the automatically created managed property for this column will be MyFooOWSNMBR. Previously you could retrieve the value of this property, or query it by entering any casing of the name.

This meant that MyFooOWSNMBR:10 and myfooowsnmbr:10 were equal queries. But not any more.

If you use any casing but the one listed in the search schema it will be treated as an unknown managed property yielding no results or values on retrieval.

Which means if you are like me and typically type all managed property names in lowercase you have work to do to fix it all up.

This information was found at