Update() allows you to select and update a record (or records) with any values you want, either from your form or otherwise. But, if you don’t provide a value for a column, it will be blanked out. Not the greatest.

Patch() does a bit better than Update in that it will allow you to selectively update a single column and leaves all other values intact. However, you have to map every column you want to update, so if you have a record with lots of fields, you would have to set values for them all in your Patch() statement. Annoying.

So what I really wanted to accomplish was to set default values for my databound controls that may to the Approved and ApprovedBy fields, then use SubmitForm() to sweep up all the values and update the record.

Here’s the approach that worked, and properly passes the Current User through to the Person and Group field:

Set the OnVisible property of my Screen to set a Context Variable with a representation of the current User.

Add a DataCard for the Person field to my EditForm.

Set the Update property of the DataCard to the name of the Context Variable. This becomes the value passed by the SubmitForm() method to the column in my datasource.

Set the OnSubmit() property of my Save button to SubmitForm(FormName)

Set the Visible property on the DataCard to False so it is not shown on the form.

Let’s break this down first by looking at how the Person record is represented. PowerApps uses JSON style notation for objects. In this case, there is a special object for a SharePoint User object, as seen below:

If you’ve used SharePoint on-premise, then the formatting of the claims username may appear odd, but it works for Office365. If you are connecting to an On-Premise SharePoint data source using a Gateway, then this format may need to change for Windows Accounts.

From what I could tell, the Email property is the most important – even if the other properties (Department, DisplayName, JobTitle, Picture) are not populated, SharePoint will identify the correct user.

Be sure to use the SPListExpandedUser data type. There is also SPListExpandedReference (used for Choice fields) but it will fail when using a Person field.

You’ll get an error saying ‘A value must be provided for item’ if anything is incorrect.

So by setting a ContextVariable when the screen loads, I can then pass that object as the properly formatted value during the SubmitForm() call.

Once the variable is set, we then use it on the data card as the Update value

Things like this definitely make PowerApps a tool that requires some technical skills to achieve various business requirements. But as the product matures, I am hopeful that shortcuts will be implemented to make these common scenarios less cumbersome to address.