Saving a SharePoint Person Field Without Manually Building the Object

A SharePoint Person column looks simple in the list, but it gets more complicated when the field is edited from Power Apps.

I had a requestor field in SharePoint and initially bound the dropdown to the Office 365 Users connector. It worked for searching, but saving the selected person back into the SharePoint Person field was not as straightforward as I expected.

The First Attempt

My dropdown used Office 365 user search.

Office365Users.SearchUser(
    {
        searchTerm: ddRequestor.SearchText,
        top: 10
    }
)

That gave me a good search experience, but the selected record did not match the structure SharePoint expected for a Person field.

So I had to manually build the update object.

{
    '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
    Claims: "i:0#.f|membership|" & Coalesce(
        Lower(ddRequestor.Selected.Mail),
        Lower(ddRequestor.Selected.UserPrincipalName)
    ),
    DisplayName: ddRequestor.Selected.DisplayName,
    Email: Coalesce(
        Lower(ddRequestor.Selected.Mail),
        Lower(ddRequestor.Selected.UserPrincipalName)
    )
}

Why It Was Painful

The issue was not only syntax. The bigger problem was the mismatch between the Office 365 user object and the SharePoint Person object.

For example:

• Office 365 gives fields like Mail
• SharePoint expects a Person record structure with values like Claims and Email
• sometimes Mail is blank, so UserPrincipalName becomes the fallback

That meant I had to understand both shapes, map them manually, and keep the formula readable enough to support later.

It worked, but it felt heavier than it should have been.

The Better Approach

Later, I found a much simpler solution.

Instead of using the Office 365 connector directly in the dropdown, I changed the Items property to use the SharePoint field choices.

Choices(
    [@gp_visit_requests].'Requestor',
    Self.SearchText
)

This gives me the same practical outcome I needed:

• the dropdown still supports searching
• I can select anyone from the address book
• the selected record is already in a structure SharePoint understands
• the form can use the default update behavior without a custom object

What Changed in the Form

After switching to Choices(...), I no longer needed the manual update formula.

The default form behavior was enough:

ddRequestor.Selected

That made the field much easier to work with.

Why This Version Is Better

This approach is better for a few reasons.

• it is faster to build
• it is easier to read later
• it removes fragile manual mapping logic
• it matches the SharePoint field type more naturally

Most importantly, it is easier to maintain. If someone revisits the app later, the form logic is more obvious and less dependent on connector-specific object shapes.

Note for Future Me

If the target is a SharePoint Person field, start by checking whether Choices(List.PersonColumn, SearchText) already gives the experience you need before reaching for Office 365 search and a custom update record.

The custom object route can work, but in this case it added complexity that SharePoint was already able to handle for me.

Result

The final version is quicker, cleaner, and easier to understand.

What started as a long compatibility problem ended up with a simpler answer: use the SharePoint Person choices directly and let the form save the selected record in its native shape.