Default Lookup field to logged in user

"Why of course I'd like to have this user lookup field default to the currently logged in user.  That's easy right?"  - New PowerApps Developer

Oh so easy...

You have probably already guessed that the answer is no.

There are several technical reasons based on what is populating that User Lookup field and the type of value used.  In the case of it being SharePoint (which seems likely), then the first problem is that the list isn't stored identically to the network login value you retrieve at the start of your App.

That means that the value retrieved inside of PowerApps by one of these commands:

• User().FullName
• User().EmailAddress

return single values (vs. records or tables of records).  While this doesn't seem like a problem initially, you will quickly realize that the DataCard "drop down" selector doesn't let you filter using a single value (e.g. filter by "User Name").  

It certainly seems like this should work, but what you really need is to match a full record or potentially a table of records and not a single field.

So how do you get the pointer to the record or a whole table of records when all you have is the currently logged in user's information listed above (e.g. User().FullName and User().EmailAddress)?

Solution

You have to issue a call directly to a SharePoint Connector to get this (at least it appears to be the way to get this done currently).  Also, as I mentioned above, if your Lookup allows only a single user to be selected then it requires a single record input.  If it allows multiselect, then an entire table of records.  

NOTE: Even though, in both cases it really only returns a single user record, it makes a difference per returning a variable that can only contain a single record or a table with only a single record in it.  (...I know...)

Single User Selection

On your user lookup field, copy/paste the following code into the DefaultSelectedItems field (not the Default field).

• If(Form1.Mode = New, {'@odata.type':"#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser", Claims:Concatenate("i:0#.f|membership|",User().Email),DisplayName:User().FullName,Email:User().Email},First(ThisItem.User))

NOTE: This is first testing to see if the user is creating a "New" form entry and only resetting the field in that case.  We are assuming if they changed it to something else later then they'd like to preserve that value.

Now make the following changes:

1. Change Form1 to reflect the name of your form
2. Change User to reflect the name of your own field (e.g. when you type ThisItem. it will offer you a selection of valid fields to choose from)

Drop the code here

Multi-User Selection

The main difference here is that you have to return a table vs. a record.  So the command looks similar.  

On your user lookup field, copy/paste the following code into the DefaultSelectedItems field (not the Default field).

• If(Form1.Mode = New, {'@odata.type':"#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser", Claims:Concatenate("i:0#.f|membership|",User().Email),DisplayName:User().FullName,Email:User().Email},ThisItem.User)

Now make the following changes:

1. Change Form1 to reflect the name of your form
2. Change User to reflect the name of your own field (e.g. when you type ThisItem. it will offer you a selection of valid fields to choose from)

The only difference between these two commands is that one is pulling the first record from the table returned (e.g. First(ThisItem.User))) vs. pulling an entire table of records (ThisItem.User).  

Final Thoughts

You are going to spend A LOT of time sorting through if a particular control or SharePoint resource expects a TABLE OF RECORDS vs. A SINGLE RECORD vs. A SINGLE VALUE.  If anything is going to cause you to beat your head against the wall it is the lack of clarity around this issue.

While it is not essential to understand this issue when starting in PowerApps, it is the lurking problem that every developer/creator will eventually run into when using this tool.