How to Update a SharePoint People Picker Field with Power Automate

You usually do not need a SharePoint REST request to update a People or Group column. Start with the SharePoint connector's Update item action. Use REST only when the connector cannot express the value you need, such as a difficult multi-person or clearing scenario in your tenant.

This guide covers both routes and explains what to test before you put the flow into production.

Fact-checked against current Microsoft documentation on 24 August 2026. Power Automate designers and connector field shapes can change, so test the final mapping in a non-production list.

Before you build the flow

You need:

permission to edit the target SharePoint list;
a People or Group column that allows the type of value you intend to store;
a reliable user identifier, normally an email address or user principal name;
sample users who are already known to the target SharePoint site.

Check the column settings in SharePoint. A column configured for one person cannot accept an array. A column configured for multiple selections needs a collection of people.

Route 1: use Update item for a single-person column

This is the simplest and most maintainable method.

Add the trigger that starts your flow.
Add any action needed to obtain the person's email address.
Add SharePoint > Update item.
Select the site, list and item ID.
In the People field, insert the email or person value exposed by the earlier action.
Supply any other required list fields.
Save and test with a user who can access the site.

If Power Automate offers several properties for the same person, prefer the email or claims value that matches what the SharePoint field accepts in your tenant. Do not type a display name and assume it is unique.

Microsoft uses the same native Update item pattern in its SharePoint approval examples. That is why REST should be a fallback, not the starting point.

Getting a manager before updating the field

If the target value is the requester's manager:

Add Office 365 Users > Get manager (V2).
Pass the requester's user principal name or email.
Add a condition for cases where no manager is returned.
In the Yes branch, pass the manager's email to the SharePoint People field.
In the No branch, leave the existing value alone or clear it using a method you have tested.

Not every account has a manager. Service accounts, external guests and incomplete directory profiles are common exceptions. Configure the action's failure handling rather than assuming every lookup will succeed.

Updating a multi-person column

The native connector can expose a multi-person field differently depending on the trigger and designer. If it accepts the array you already have, use that route and test it first.

When the input comes from another SharePoint multi-person column, map the complete person collection rather than joining the email addresses into one text string. When the input comes from another system, build a clean array and reject blank or invalid identities before updating SharePoint.

If the designer only exposes a single input or repeatedly rejects a valid collection, use the REST fallback below.

Route 2: use Send an HTTP request to SharePoint

The SharePoint connector includes Send an HTTP request to SharePoint for REST operations that the standard actions do not support well. Microsoft describes this as a developer-focused action and recommends using the normal connector actions when they meet the requirement.

1. Resolve each person in the target site

SharePoint person fields ultimately reference users known to the site. You can query a site user by email with:

_api/web/siteusers/getbyemail('person@contoso.com')

Use GET and request JSON. Read the returned SharePoint user ID only after checking that the request succeeded.

If the user is not known to the site, the lookup can fail. You may need an approved provisioning step before updating the list item. Do not silently substitute another user.

2. Find the column's internal name

REST payloads use the internal field name, which may differ from the label shown in the list. Check the list settings or inspect the field through the SharePoint API. Do not infer it from the display name after a column has been renamed.

For person columns, the REST property commonly uses the internal name followed by Id, for example ApproverId. Multi-value fields use a collection of IDs. The precise payload shape depends on the REST metadata mode and field configuration, so copy a working response from your tenant and test against a disposable item before using production data.

3. Update the list item

Use the list item endpoint with an update request. Microsoft's REST guidance documents POST with MERGE semantics and an If-Match header for list-item updates. An ETag protects you from overwriting somebody else's newer change. Using * bypasses that protection, so only do it when overwriting concurrent edits is acceptable.

The request body should contain only the fields you intend to change. Avoid copying old internet examples that force odata=verbose, hard-code a list entity type or use magic values such as -1 and [0] without validating them against your tenant.

How to clear a People field safely

Clearing is where many old examples become dangerous. There is no reason to treat -1 for a single person or [0] for multiple people as a universal rule.

Use this order:

Try clearing the field through Update item in a test list.
Inspect the action inputs and the resulting list item.
If REST is required, test the null or empty-collection representation that matches the field and REST metadata mode in your tenant.
Add a condition so a failed directory lookup does not accidentally erase a valid assignee.

Common failures

The user could not be found

Confirm the email is correct, the account has not been deleted and the user is known to the target site. Guest identities can use unexpected sign-in names, so email alone is not always enough for diagnosis.

A multi-person value is treated as text

Do not join the people into a comma-separated string. Pass a collection in the shape expected by the connector or REST endpoint.

Update item clears unrelated columns

Supply required fields and review every mapped input. If the action presents values from the current item, preserve the ones that must remain unchanged.

The REST request returns 400

Check the internal field name, request body, content type and value shape. Run a GET for the item and field metadata rather than guessing.

The flow overwrites a newer edit

Use the item's real ETag with If-Match and decide how the flow should handle a conflict. If-Match: * trades safety for convenience.

Which method should you choose?

Requirement	Start with
Set one person from an email address	Update item
Copy one SharePoint person field to another	Update item
Set a manager returned by Office 365 Users	Update item
Set several people from a clean person array	Update item, then test
Connector cannot represent the multi-person value	SharePoint REST
Need explicit concurrency control	SharePoint REST with ETag

The maintainable answer is the least complex route that passes your tenant test. REST is useful, but it is not proof that the native connector has failed until you have actually tested the native action.

Microsoft sources

Build and troubleshoot flows with other makers

If this is part of a real business process, bring the flow, the column configuration and a failed run to the Power Automate Builders Space. The link is attributed to this article so we can measure whether the recommendation is useful.