Fix a Power Apps People Picker That Will Not Save to SharePoint

Your Combo box finds the right person. The name and photo look fine. Then the form saves a blank Person column—or Patch returns an unhelpful error.

The usual cause is not the picker. It is the record shape.

A SharePoint Person or Group column expects a SharePoint person record. Office365Users.SearchUserV2() returns an Office 365 Users profile record. They can describe the same human while exposing different field names and types.

The safest fix is to keep the SharePoint-shaped records produced by the generated form. Only build a custom translation when you genuinely need a different directory search.

Start by identifying the failing route

There are three different problems that are often called “the people picker issue”:

1. The picker cannot find the person. This is an Items, search-scope or permission problem.
2. The picker finds the person but will not save. This is usually a data-card Update or Patch record-shape problem.
3. A saved person disappears when editing the item. This is usually a DefaultSelectedItems shape problem.

Do not replace every property at once. Decide which of those three is broken first.

Route A: keep the native SharePoint person shape

Use this route when the generated SharePoint form can search the people your column is meant to allow.

Microsoft documents the Choices function as the normal way to return values for a lookup-shaped column and says the returned table matches the associated record shape. Microsoft's Combo box reference defines Selected, SelectedItems, DefaultSelectedItems and SelectMultiple.

For a list named Requests with a Person column named Approver, the generated pattern is:

Combo box Items

Choices([@Requests].Approver)

DefaultSelectedItems

Parent.Default

Data card Update for a single-person column

cmbApprover.Selected

Data card Update for a multi-person column

cmbApprover.SelectedItems

Set SelectMultiple to match the SharePoint column. Then save the form with:

SubmitForm(frmRequest)

Microsoft recommends an Edit form for simple data updates. This route lets the SharePoint connector preserve the person record shape instead of asking you to recreate it manually.

The limitation you need to know

Microsoft's current Choices documentation says the function is not delegable. That does not mean every people picker immediately fails, but it does mean you should test the real directory/search scope rather than promising it will cover an unlimited tenant.

The SharePoint Person column's own settings also matter, including whether selection is limited to a SharePoint group.

Route B: use Office 365 Users search and translate the result

Use this route when the native picker cannot meet a justified search requirement and you have tested the governance and performance implications.

Microsoft's Office 365 Users connector guidance gives this supported V2 search pattern:

Office365Users.SearchUserV2(
    {
        searchTerm: cmbApprover.SearchText,
        top: 20,
        isSearchTermRequired: true
    }
).value

Use that as the Combo box Items formula. Configure the Person layout, then set display/search fields to the text properties your control exposes, commonly DisplayName, Mail and UserPrincipalName.

Do not call this “delegation-proof”. Microsoft says Combo box search delegation depends on the Items expression being delegable, and the connector has its own query and result boundaries. Test common names, duplicate names, guests and accounts with no Mail value.

Translate one selected user for a SharePoint form

When the data card must return a SharePoint Person record, the following is a commonly used SharePoint connector shape:

With(
    {
        u: cmbApprover.Selected,
        signIn: Lower(
            Coalesce(
                cmbApprover.Selected.Mail,
                cmbApprover.Selected.UserPrincipalName
            )
        )
    },
    If(
        IsBlank(signIn),
        Blank(),
        {
            '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
            Claims: "i:0#.f|membership|" & signIn,
            DisplayName: u.DisplayName,
            Email: signIn,
            Department: Coalesce(u.Department, ""),
            JobTitle: Coalesce(u.JobTitle, ""),
            Picture: ""
        }
    )
)

Set this on the parent data card's Update property—not on the Combo box Items property.

This formula is practical connector guidance, not a promise that every tenant resolves every identity the same way. Microsoft explicitly warns in its Patch documentation that record shapes vary by data source. Compare the fields with a record returned by Choices([@Requests].Approver) in your app and test the target accounts.

Translate multiple selected users

If the SharePoint column allows multiple people, return a table of person records:

ForAll(
    Filter(
        cmbApprovers.SelectedItems,
        !IsBlank(Coalesce(Mail, UserPrincipalName))
    ) As u,
    With(
        {
            signIn: Lower(Coalesce(u.Mail, u.UserPrincipalName))
        },
        {
            '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
            Claims: "i:0#.f|membership|" & signIn,
            DisplayName: u.DisplayName,
            Email: signIn,
            Department: Coalesce(u.Department, ""),
            JobTitle: Coalesce(u.JobTitle, ""),
            Picture: ""
        }
    )
)

Match three things together:

• SharePoint column allows multiple selections;
• Combo box SelectMultiple is true; and
• data card Update returns a table.

A single record sent to a multi-person field—or a table sent to a single-person field—is the wrong shape.

Mail and UserPrincipalName are not interchangeable guarantees

The Office 365 Users connector exposes both Mail and UserPrincipalName. They are often the same. They are not required to be.

Mail can be blank for some accounts. Guests and organisations with different sign-in and SMTP naming can behave differently. The examples use Coalesce(Mail, UserPrincipalName) as a deliberate fallback, but you must validate which value SharePoint resolves in your tenant.

Test at least:

• a normal member whose mail and UPN match;
• a member whose mail and UPN differ, if you have one;
• a guest the column is meant to allow;
• an account with blank Mail; and
• a disabled or departed account already stored on an older item.

Do not lower-case a display name. Only normalise the sign-in string.

Why existing values disappear in Edit mode

When you replace Choices(...) with SearchUserV2(...), you change the Items record shape. Parent.Default still contains a SharePoint person record, while the new items contain Office 365 Users records.

That is why a picker can save a new person but show blank when the item is reopened.

You need a deliberate default-mapping strategy:

1. Read the existing SharePoint person's email/claims value.
2. Resolve the corresponding Office 365 Users record.
3. Return a table of matching records to DefaultSelectedItems.
4. Handle unresolved, guest and departed users without silently replacing them.

Do not use Default; Microsoft marks it deprecated for Combo boxes. Use DefaultSelectedItems.

There is no universal one-line default formula for every guest, group-restricted column and multi-person field. Test both New and Edit forms. If maintaining the mapping costs more than the custom search adds, return to Route A.

A reliable diagnostic order

1. Refresh the list schema

If the SharePoint column was changed between single and multiple selection, refresh or remove/re-add the data source. Power Apps may still hold the older shape.

2. Inspect the parent card

Confirm:

• DataField points to the intended SharePoint internal column;
• Update returns the right shape;
• Required follows the column requirement; and
• the form's Item is the expected list record.

3. Prove the native route

Temporarily restore:

Items = Choices([@Requests].Approver)
DefaultSelectedItems = Parent.Default
Update = cmbApprover.Selected

If this works, the list connection and form can save the column. The fault is in your custom search/translation, not SharePoint generally.

4. Show errors to the user

For a form, handle OnFailure and display frmRequest.Error.

For a custom patch, use IfError:

IfError(
    Patch(
        Requests,
        LookUp(Requests, ID = varRequestId),
        { Approver: varApproverRecord }
    ),
    Notify(
        "The approver was not saved: " & FirstError.Message,
        NotificationType.Error
    )
)

Do not translate every failure into “network error”. Microsoft lists connectivity, permissions and data conflicts as different Patch failure causes.

5. Test permissions as a normal user

The maker's connections and list rights can hide an access problem. Test with a user who has the intended app, connector and SharePoint permissions—without maker privileges.

If the whole form behaves differently when editing records, use our guide to Power Apps forms not loading the correct SharePoint item.

Common anti-patterns

Using User().Email for the selected person

User().Email describes the current app user, not the person chosen in the Combo box. It can silently save the runner instead of the selection.

Assuming every account has Mail

Use a deliberate fallback and test it. A blank email must not become a malformed claims string.

Switching Items but leaving Update and defaults untouched

Those three properties form one contract. Changing only search is the fastest way to create a picker that looks right and stores nothing.

Putting a Combo box inside a scrolling gallery

Microsoft documents that selections are not maintained when a Combo box is used inside a scrolling gallery, with no current workaround. Move the editor outside the gallery or redesign the interaction.

Testing only a new record

New, Edit and View states exercise different defaults and existing identities. Test all of them, including old values that no longer resolve cleanly.

Release checklist

• SharePoint single/multiple setting matches SelectMultiple and Update.
• Native Choices route was tested before custom translation.
• DefaultSelectedItems works for existing records.
• Blank Mail, different UPN and guest cases were considered.
• Errors are visible through form failure or IfError.
• Normal-user permissions were tested.
• New, Edit and View states passed.
• Saved list values—not only the on-screen control—were checked.

For current, practical Power Apps patterns with the tenant-test boundary left intact, join the Power Apps Builders Space.

Frequently asked questions

Why does my Power Apps people picker find a user but save a blank SharePoint field?

The Combo box often returns an Office 365 Users profile while the SharePoint Person column expects a SharePoint-shaped person record. Keep the native Choices shape or translate the selected profile in the data card's Update property.

Should I use Choices or Office365Users.SearchUserV2?

Start with Choices because it returns the associated record shape and works naturally with generated forms. Use SearchUserV2 only when its broader custom search is needed and you are prepared to map saves and existing defaults.

What should DefaultSelectedItems be for a generated SharePoint form?

With the native Choices route, use Parent.Default. If you change Items to Office 365 Users records, you must map the stored SharePoint person back to that new shape and return a table.

Is SearchUserV2 completely delegation-safe?

No blanket guarantee is appropriate. Microsoft says Combo box search delegation depends on the Items expression, and connector queries have their own boundaries. Test the real directory and search terms.

How do I save multiple people?

The SharePoint column must allow multiple people, the Combo box must have SelectMultiple = true, and the data card Update must return a table of correctly shaped person records.