PowerApps gives you the opportunity to extend your SharePoint lists so that it can give just that much better experience for your users. However, there are still some things that need a little bit extra attention, such as lookup and people fields.

In this blog, I will explain how you can use these field types within PowerApps.

A lookup field uses a basic combination of two attributes to render it correctly:

  • Id, which is the item ID of the source item
  • Value, which is the text value of the source item

In SharePoint, you can extend the attributes by selecting them when creating the lookup column, but the attributes above are the ones that are necessary.

We can confirm this by referencing a lookup column (which is the DataCardValue3 control) in a PowerApp to a new label:

Because the field expects a combination of both ID and Value, we cannot just only use the Value attribute when doing something with the outcome of that control within PowerApps. For example: setting the Default value of that control.

In this example I want the default Room (which is a lookup column) of my Room planner to be the ‘Bill Gates Room’. By just entering a Default value of ‘Bill Gates Room’, PowerApps will give me an error that an Text value is entered, but it expects a Record value:

So, how can we handle this fieldtype correctly? As stated in the error message above, the control expects a Record value. The correct Record value of a lookup field is as follows:

{
  '@odata.type' : "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference",
  Id: <ID>,
  Value: <VALUE>
}

For this to make it work, we need the Id and the Value of the items. To get the Id, we can look into our source list:

We can now combine both Id and Value into the correct Record syntax and set our Default value:

Patching lookup fields

When using a Form, you will have no issues saving the data back to SharePoint. If you want to use the Patch() function to save the data back to SharePoint, you need to use the same Record syntax as we used in the Default value. For the Id and Value, you can use the properties from the lookup control:

A people field also consists of a combination of attributes to render into a Record value, as we can see when referencing a people field to a new label:

The only one that is really necessary rendering the field is the Claims attribute, but if you only use this attribute you will see an empty control in your PowerApp, which isn’t quite user friendly. So it’s recommended to also use the DisplayName attribute.

The expected Record value is as follows:

{
    '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
    Claims: "i:0#.f|membership|<EMAIL-ADDRESS>",
    DisplayName: <DISPLAYNAME>
}

A common scenario is to pre-fill the control with the current user, which can be achieved by using the User() function. If we use that and put the correct Record syntax into the Default property of our control, the current user will be filled in:

Another way to achieve this is to use the Office365Users connector. Simply add the Office365Users connection as a new data source and put the Office365Users.MyProfile() as Default property of our control:

Patching people fields

Just like the lookup field, you can use this for your Patch() function as well, but you can only use the first Record syntax I showed (and not the Office365Users data source) because the Patch() function expects the following properties:

  • Claims
  • Department
  • DisplayName
  • Email
  • JobTitle
  • Picture

All of these properties can be pulled from the control itself:

  • Always set the Default property on the Card itself, not on the control (e.g. DataCardValue2)! In some cases it might not cause anything weird, but I have seen some cases that the control doesn’t accept the altered Default property where the Card always accepts it.
  • Make sure you only change the Default property in your New form. If you set the Default property of your Edit form to something that is different from the value that is actually stored into SharePoint, your value will be overwritten after your edit. The correct Default property of your Edit form is ThisItem.<FIELDNAME>
Previous articleRDS HTML5 webclient update 1.0.1 – fixing the AltGr issues
Next articleAzure / Office 365 – 2 wekelijks overzicht – deel 49
avatar
My name is Rik de Koning and I work as a Functional Consultant for Portiva, which is one of the larger Office 365 implementation partners in The Netherlands. I started my career in 2011 as a SharePoint support engineer and in 2013, I went to become a SharePoint consultant where I did various projects on SharePoint Server 2010 and SharePoint Server 2013. In the last couple of years I started focusing more and more on Office 365, especially on SharePoint Online, PowerApps and Microsoft Flow. I like being challenged and for PowerApps and Flow being quite new, there are always some challenges when implementing these services. When I’m not working, I like spend some time with my family (girlfriend and son), hang out with friends, do some sports (like fitness, running, kitesurfing and snowboarding) playing videogames and just relax a little. If you have any questions, please do not hesitate to contact me!

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.