Using SharePoint’s validateUpdateListItem in Power Automate: A Beginner’s Guide

When working with SharePoint Online and Power Automate (Flow), you might reach a point where the standard “Update item” action isn’t enough. Perhaps you need to update system-managed fields (like Modified or Created By), or you want to update an item without triggering other flows or incrementing version history. Enter the SharePoint REST API’s validateUpdateListItem endpoint – a powerful method to update list items with fine control. In this beginner-friendly guide, we’ll walk through how to use validateUpdateListItem via the Send an HTTP request to SharePoint action in Power Automate. We’ll cover how to set up the HTTP request, the JSON body format (with examples for various column types), and explain the benefits of this approach.

What is `validateUpdateListItem` and Why Use It?

The validateUpdateListItem is a SharePoint REST API method that validates and updates list item fields in one call. It’s often used for “system updates,” meaning changes that don’t trigger flows/alerts and can bypass certain restrictions. For example, a normal item update will increment the item’s version and can trigger any flow listening on item modifications. In contrast, using validateUpdateListItem with the right parameters can perform a silent update (no new version, no flow trigger) [sharepains.comsharepains.com]. This is useful to avoid infinite update loops or to write back a status flag without causing another flow run [sharepains.com].

Benefits of validateUpdateListItem:

Bypass Triggering Flows: Updates done as a “system update” won’t trigger Flow triggers or alerts, preventing feedback loops [sharepains.com].
No Version Bump (Optional): By setting a flag, you can update an item without increasing its version count [robertschouten.com]. This is similar to SharePoint’s UpdateOverwriteVersion in server object model [robertschouten.com]. (We’ll see how to do this with bNewDocumentUpdate parameter.)
Update System Fields: It allows setting fields like Modified, Editor (Modified By), Created, Author (Created By) by passing their internal names and values in the JSON. This is something the standard “Update item” action can’t do directly.
Easier Field Value Format: You often supply values “as if” entered in SharePoint’s UI, rather than constructing complex field objects [sharepains.com]. This makes updating complex field types (people, taxonomy, etc.) easier than some other APIs.

Now, let’s dive into how to call this endpoint from Power Automate.

Setting Up the HTTP Request in Power Automate

To use validateUpdateListItem in Power Automate, we’ll use the Send an HTTP request to SharePoint action. Follow these steps:

Add the HTTP action: In your flow, add a new action and select SharePoint – Send an HTTP request to SharePoint.
Site Address: Choose the SharePoint site URL where your target list or library resides (e.g. https://contoso.sharepoint.com/sites/project-x).
Method: Set the HTTP method to POST (since we are sending data to update the item).
URI: Enter the REST API endpoint for your list item. The format is:
```
_api/web/Lists/GetByTitle('<ListName>')/items(<ItemID>)/validateUpdateListItem
```
Replace <ListName> with the exact list name (or use GetById(listGuid) if preferred) and <ItemID> with the ID of the item you want to update. For example:
_api/web/Lists/GetByTitle('Projects')/items(42)/validateUpdateListItem.
(Note: You can also use GetList(@list)/items(ID)/validateUpdateListItem?@list='<list server relative URL>' if dealing with libraries, but the above format is simplest.)
Headers: Add the following HTTP headers:
- Accept: application/json; odata=nometadata
- Content-Type: application/json; odata=nometadata
  These headers ensure SharePoint returns JSON and that our request body is treated as JSON. (You can also use odata=verbose or minimalmetadata – just be consistent in both accept and content-type.)
- Authorization: (Not explicitly needed – the action uses your connection’s credentials automatically.)
- IF-MATCH and X-HTTP-Method: Not required here – validateUpdateListItem handles concurrency internally without needing an eTag.
Body: This is where we specify what fields to update and their values, in JSON format. We will detail this in the next section. At a high level, the JSON body must include a formValues array of field updates, and optionally the bNewDocumentUpdate flag.

At this point, your HTTP action setup should look similar to the screenshot below.

Figure: Example configuration of the Power Automate HTTP request to SharePoint, pointing to the validateUpdateListItem endpoint (Site Address, POST method, URI with list name and item ID, and JSON body). The body includes a formValues array of field names/values and a bNewDocumentUpdate flag.

Understanding the JSON Body Structure

The body for validateUpdateListItem must be a JSON object with at least a formValues property. This formValues is an array of objects, each with two required properties: "FieldName" and "FieldValue" [sharepains.com]. For example, to update a Title field you could have:

{
  "formValues": [
    {
      "FieldName": "Title",
      "FieldValue": "New Title Value"
    }
  ],
  "bNewDocumentUpdate": false
}

Let’s break down the components:

FieldName: This should be the internal name of the column you want to update. Often, the internal name is the same as the display name if it has no spaces or special characters. If your column’s display name has spaces or special characters, use the internal name (e.g. "Created_x0020_By" for “Created By”, or "Project_x0020_Name" for “Project Name”). You can find internal names in list settings or via developer tools.
FieldValue: The value to set the field to, as a string. The format of this value depends on the field’s type (detailed in the next section). Generally, you provide what you would type into the SharePoint UI for that field. For example, for a Choice field, use one of the choice text options; for a Yes/No, use a numeric representation of True/False, etc. We will cover specific formats for each type.
bNewDocumentUpdate: (Optional) A boolean flag (true/false) that, when true, tells SharePoint to do an “overwrite” update that does not create a new version [robertschouten.com]. Essentially, if bNewDocumentUpdate: true, SharePoint will perform the update without bumping the version number (similar to a system update). Use this if you want a silent update that doesn’t clutter version history. Important: To fully suppress a version increment, you also must include the Editor field in your formValues (see “Person (Editor) Field” below for why) sharepains.com]. If you omit Editor, a new version may still be created even if this flag is true. For normal updates where versioning or triggers aren’t a concern, you can set this to false or omit it (false is default).

Putting it together, a basic example might look like:

{
  "formValues": [
    { "FieldName": "Title", "FieldValue": "Updated Title" },
    { "FieldName": "Status", "FieldValue": "Completed" }
  ],
  "bNewDocumentUpdate": true
}

This would update a Title column and a Status choice column on the item, and do so as a system update (no new version, assuming Editor is also included or not needed to change).

Next, we’ll explore how to format the FieldValue for various SharePoint column types. This is crucial – each field type expects the value in a specific format.

Updating Different Column Types with `validateUpdateListItem`

Each SharePoint field (column) type may require a slightly different FieldValue format in the JSON. Below, we’ll go through common field types listed in the question and show how to update them via validateUpdateListItem. For each, we assume you have a column of that type on your list, and we’ll describe what the JSON needs to look like.

Yes/No (Boolean) Columns

Column type: Yes/No in SharePoint corresponds to a boolean (True/False) value. In list forms, it appears as a checkbox or toggle (checked = Yes/True, unchecked = No/False).

FieldName: Use the internal name of the Yes/No field. For example, if the column is called "Approved", the internal name might be "Approved" (unless it was renamed).

FieldValue format: Use "1" for Yes/True or "0" for No/False. These should be provided as strings (since the API expects string input). For example:

{ "FieldName": "Approved", "FieldValue": "1" }

This would set the Approved column to “Yes”. Conversely, "FieldValue": "0" sets it to “No”. Do not use literal true/false or "Yes"/"No" strings – the API expects numeric string representation (1/0) for booleans [gist.github.com].

Common pitfall: If you use "true"/"false" or other variations, SharePoint may not understand it and your request could fail or produce no change. Always stick to "1" or "0" for Yes/No fields.

Date and Time Columns

Column type: This can be a Date column (Date only) or DateTime column (Date with Time). SharePoint stores dates in a specific format and will parse the string you send according to regional settings if not in ISO format.

FieldName: Use the internal name of the date field (e.g. StartDate, Deadline, etc.).

FieldValue format: It’s best to use an unambiguous date/time format. The recommended approach is to use a ISO 8601-like format, e.g. "YYYY-MM-DD HH:MM:SS". A full ISO timestamp with “T” and “Z” (UTC designator) can sometimes be accepted, but often SharePoint expects a specific pattern without the “T”. For example, "2025-06-19 13:30:00" represents 13:30 on 19 June 2025. This format is generally independent of locale [stackoverflow.com] and avoids errors. If your column is date-only, you can provide just the date portion ("YYYY-MM-DD"). If it’s date-time and your SharePoint site is set to a 12-hour format, you might need to include AM/PM (e.g. "2025-06-19 01:30:00 PM"). In 24-hour format locales, "2025-06-19 13:30:00" works universally.

For example:

{ "FieldName": "StartDate", "FieldValue": "2025-06-19 09:00:00" }

This sets the StartDate to June 19, 2025 9:00 AM.

In one real example, a SharePoint flow updated a date field by sending "2024-01-05 12:30.44" [sharepains.com] (which was the value as shown in the SharePoint UI for that date/time). While that worked, it’s safer to stick to the standard YYYY-MM-DD HH:MM:SS format to avoid any confusion with regional date formats.

Common pitfalls:

Regional settings can affect parsing. If you use a format like "MM/dd/yyyy" vs "yyyy-MM-dd", some sites might expect one or the other. By using the ISO-style year-first format, you reduce ambiguity.
Ensure the time portion is included if the field expects time; if your value doesn’t include time and the field does, it might default to 12:00 AM or throw an error depending on context.
If you include a “Z” (UTC) or timezone offset, SharePoint might still interpret the time relative to the site timezone or reject it. Thus, using the site’s local format (or a neutral format as above) is often easier.

Currency Columns

Column type: Currency columns store a monetary value. Under the hood, SharePoint treats currency as a number (with fixed decimal places) plus it knows the currency locale (e.g. USD, EUR) configured in the column settings.

FieldName: Use the internal name (e.g. Budget, Cost). If the column name has spaces like "Project Cost", internal might be Project_x0020_Cost.

FieldValue format: Provide the numeric value (as a string) without any currency symbols. For example, to set a currency field to $1,234.50, you would use "1234.50". The currency symbol is determined by the column’s locale settings, not by the input value. If your number is whole, you can just send "100" (which would be $100.00 if the currency is USD, for instance). For example:

{ "FieldName": "ProjectCost", "FieldValue": "1234.5" }

This sets the ProjectCost to 1234.50 in whatever currency the column is configured (the UI will format it accordingly). You can include two decimal places explicitly (e.g. "1234.50") but SharePoint will handle the rounding based on the column’s configured decimal precision.

Common pitfalls:

Do not include currency symbols like $ or £ in the FieldValue – use only numbers and decimal point. Including symbols or commas (thousand separators) will likely cause a format error. For instance, use "10000" not "10,000" and not "$10000".
The value should be in the currency’s minor unit. For example, for USD 1.00 use "1.00" (if 2 decimal places are used) or just "1" and SharePoint will format to $1.00.
If your currency column uses 4 decimal places (for certain currencies), ensure you provide the appropriate precision in the string.

Lookup Columns

Column type: Lookup columns reference an item from another list. A single-value lookup stores one referenced item; a multi-value lookup can store multiple.

FieldName: Use the internal name of the lookup field. (E.g. if the column is “Category” that looks up to a Categories list, FieldName might be Category.)

FieldValue format (Single-value Lookup): Provide the ID of the target item (in the lookup target list) as a string. For example, if you want to set the lookup to point to the item with ID 7 in the source list, use "7". The associated text (like the Title of the looked-up item) is not needed here – SharePoint will resolve it from the ID. Example:

{ "FieldName": "Category", "FieldValue": "7" }

This would set the Category lookup to the item with ID 7 in the source list.

FieldValue format (Multi-value Lookup): Provide all the target item IDs in a single string, separated by the special delimiter ;#. The pattern is each ID followed by ;#, concatenated. For example, to set a multi-lookup field to items with IDs 2, 3, and 4, you would send:

{ "FieldName": "Categories", "FieldValue": "2;#;#3;#;#4;#" }

Breaking that down: "2;#;#3;#;#4;#" – here each ID is followed by ;#, and the IDs are separated by an extra ;#. This format may look odd, but it’s how SharePoint expects multi-lookup values [robertschouten.compnp.github.io]. Essentially, for each ID, you append ;# after it, and then join them all into one string. In the above, it results in 2;#;#3;#;#4;#. (If you had IDs 2, 3, 4, 5, it would be "2;#;#3;#;#4;#;#5;#" and so on.)

Alternate format: Some sources indicate you can also supply the IDs separated by just ;# without doubles (e.g. "2;#3;#4"), but the reliable approach per documentation is the doubled delimiter format with trailing ;#. If in doubt, use the format as illustrated.

Common pitfalls:

Don’t use titles or text: Only IDs should be used in the FieldValue. If you try to put the lookup target’s text value, it will not find the item.
Ensure the ID strings are integers (no leading zeros or any other characters).
The ;# delimiter must be exact. Missing or extra delimiters will cause the update to fail or the field to not update correctly.
For multi-lookup, constructing the string can be tricky in Power Automate expressions. You might build an array of IDs and then join them with the pattern, or simply hardcode if static. (For a dynamic list of IDs, you could use an expression to join like join(body('Select')?['ID'], ';#;#') & ';#' to generate the string.)

Choice Columns (Single and Multi-choice)

Column type: Choice columns allow one or multiple selections from a predefined set of options. A single-choice column stores one value; a multi-choice stores one or more.

FieldName: Use the internal name of the choice field (e.g. Status, PriorityLevel, etc.).

FieldValue format (Single-choice): Use the exact text of the choice option you want to set. It must match one of the allowed choice values defined in the column settings. The comparison is case-insensitive to the actual choice text, but it’s good practice to match the case exactly. Example:

{ "FieldName": "Status", "FieldValue": "Completed" }

If “Completed” is one of the choices for the Status column, this will set it to that value [sharepains.com] (in the earlier example JSON, "DocumentType": "Letter" was used as a choice value [sharepains.com]).

FieldValue format (Multi-choice): Provide the chosen options as a single string, separated by ;#. For example, if a Tags field (multi-choice) allows values like "Red", "Blue", "Green", and you want to select Red and Green, you would use:

{ "FieldName": "Tags", "FieldValue": "Red;#Green" }

Each choice is separated by ;#. Unlike multi-lookup, you do not need an extra delimiter at the beginning or end for multi-choice. Just join the choices with ;# in between [gist.github.com]. If you have three choices, e.g. "Red", "Green", "Blue", you might send "Red;#Green;#Blue".

Common pitfalls:

The choice text must match exactly a valid option. If it doesn’t, SharePoint will throw an error (e.g. “Invalid data for field…”). Make sure there are no extra spaces or typos.
For multi-choice, do not include an extra ;# at the very end (some older documentation showed a trailing ;#, but it’s typically not required for multi-choice). For example, use "Option A;#Option B", not "Option A;#Option B;#".
Choice fields (especially multi) might have commas in their values. Don’t confuse the comma with the delimiter; only ;# works as a delimiter in this context. If an option itself contains “;#” (highly unlikely since SharePoint wouldn’t allow that in a choice text), it would be problematic. But normal words are fine.

Person or Group Columns (Single and Multiple)

Column type: Person/Group columns allow selection of a user or group from the SharePoint people picker. Internally, these are a special kind of lookup to the hidden User Information List. We must provide a claims-based identifier for the user or users.

FieldName: Use the internal name of the person field (e.g. AssignedTo, Owner). For the out-of-box Created By (Author) and Modified By (Editor) fields, the internal names are Author and Editor respectively.

FieldValue format (Single-person): Provide a JSON string that represents an array of one object with the user’s claim. That sounds complex, but effectively it’s:

"[{'Key':'i:0#.f|membership|user@domain.com'}]"

Yes, the FieldValue itself is a string containing JSON. Let’s break it down:

The value starts with [ and ends with ] – this denotes an array.
Inside, for each user, we have an object {'Key':'<claims-identifier>'}.
For SharePoint Online (Azure AD), the claim identifier format is typically i:0#.f|membership|user@domain.com. So if the user’s login/email is alice@contoso.com, the Key becomes "i:0#.f|membership|alice@contoso.com".

So for example, to set a Manager field (single-person) to Alice’s account:

{
  "FieldName": "Manager",
  "FieldValue": "[{'Key':'i:0#.f|membership|alice@contoso.com'}]"
}

This string is exactly what SharePoint needs to resolve the user. It’s essentially the same data you’d get if you were using the SharePoint people picker and selecting that user.

If you are on SharePoint on-premises (or older auth), the claim might look different (e.g. i:0#.w|domain\\username), but for SharePoint Online, the |membership|user@tenant format is correct [gist.github.com].

FieldValue format (Multi-person): Similar approach, but include multiple objects in the JSON array. For example, to set a Approvers multi-person field to Alice and Bob:

{
  "FieldName": "Approvers",
  "FieldValue": "[{'Key':'i:0#.f|membership|alice@contoso.com'},{'Key':'i:0#.f|membership|bob@contoso.com'}]"
}

Notice the FieldValue string contains two objects in the array, separated by a comma. No extra commas at the ends, and the entire thing is a string in JSON context. The Power Automate action will pass this string as is. SharePoint will parse it and assign those two users.

Special note – Editor/Author: If you want to do a system update without changing Modified By, you would include the Editor field and set it to the current modified-by’s claim, effectively re-setting it to the same value [sharepains.com]. For example, if you’re doing bNewDocumentUpdate: true, be sure to add:

{ "FieldName": "Editor", "FieldValue": "[{'Key':'i:0#.f|membership|john.doe@tenant.com'}]" }

(using whatever the current editor’s login is). Similarly, to set Created By, use Author field with the claim JSON. This is how some flows maintain Author/Editor so those don’t change on an update [learn.microsoft.comlearn.microsoft.com]. You typically need high permission (like site owner or at least item-level permissions that allow editing those fields) to update Author/Editor.

Common pitfalls:

JSON string formatting: Because the FieldValue itself contains quotes and braces, be careful to escape them properly if constructing in Power Automate. The examples above use single quotes inside the string for simplicity. You can also use double quotes inside and escape them. For instance: "[{\"Key\":\"i:0#.f|membership|alice@contoso.com\"}]" is the fully escaped version. If typing in the HTTP action as raw JSON, using single quotes for the internal JSON is a convenient workaround (SharePoint is fine with single or double quotes for the Key string).
Ensure the user exists in the site’s User Information List (i.e., they have been granted access or added to the site). If the email or login is not recognized, the API may return an error or “Multiple entries matched” error. Using the exact claim ensures uniqueness [learn.microsoft.comlearn.microsoft.com].
For group values, use a similar approach – the claim for a SharePoint group might be something like c:0o.c|federateddirectoryclaimprovider|<groupid> (for O365 groups) or sharepointgroup:Group Name in older formats. However, updating SharePoint groups via this method is less common; usually it’s user accounts.
If you only put the email without the claims prefix, e.g. '[{"Key":"alice@contoso.com"}]', SharePoint will try to resolve it, but it could fail or pick the wrong user if there are multiple claim providers. The safe route is always include the full claim as shown.

Hyperlink or Picture Columns

Column type: “Hyperlink or Picture” columns in SharePoint contain a URL and an optional description. In SharePoint list views, a hyperlink field might display as a clickable link (with description text), and a picture field displays an image.

FieldName: Use the internal name of the hyperlink field (e.g. Website, ImageLink, etc.).

FieldValue format: Provide the URL, followed by a comma and a space, then the description. The format is:

<URL>, <Description>

If you leave the description blank, SharePoint will use the URL as the display text. For example:

{ "FieldName": "Website", "FieldValue": "https://www.bing.com, Bing" }

This sets the Website column to the URL https://www.bing.com with the friendly description “Bing” [robertschouten.com]. In the list, it will show as a hyperlink “Bing” linking to the Bing website. If you wanted to not have a description, you could just provide "https://www.bing.com," with a trailing comma (or possibly just the URL alone). Including the comma is a clear way to indicate an empty description.

For a Picture column (which is essentially the same type under the hood), you would also use the same format: the image URL, then comma, then description/alternate text.

Common pitfalls:

Don’t forget the comma. The comma separates the URL and the description. If you omit it, SharePoint might try to treat the whole string as the URL (and fail if it’s not a valid URL format or just ignore the description).
If your URL or description contains a comma ,, that could confuse the parser. Generally, URLs don’t contain commas, but descriptions might. If your description has a comma, unfortunately this format becomes ambiguous. It’s safest to avoid commas in the description or you would need to experiment (it might not be possible to escape the comma in this context).
Ensure the URL is absolute (e.g. starts with http:// or https:// or mailto: etc., or is a server-relative link like /sites/xyz/doclib/file.docx). A relative URL might not resolve correctly.
For images, if you provide a link to an image file, SharePoint will just store that URL. The actual image is not uploaded by this action (you’d need a separate step if you want to upload an image and then reference it).

Managed Metadata (Taxonomy) Columns – Single and Multi-value

Column type: Managed Metadata columns (also known as taxonomy or term columns) allow you to tag items with terms from a term store. They can be single-value or allow multiple terms. These are one of the trickier field types to update via REST traditionally, but validateUpdateListItem makes it simpler by using a special string format.

FieldName: Use the internal name of the term field. If your column is "Department" (and connected to a term set of departments), the internal name might also be Department (unless changed).

FieldValue format (Single-value Metadata): The format is:

Label|GUID

followed by a trailing semicolon ;. Here:

Label is the term’s label (the text as seen by users).
GUID is the unique identifier of the term (the Term ID in the term store).

You should combine them with a pipe character | and then end with ;. For example, suppose you have a term “Finance” with GUID 12345678-90ab-cdef-1234-567890abcdef. To set the metadata field to “Finance”, you would use:

{ "FieldName": "Department", "FieldValue": "Finance|12345678-90ab-cdef-1234-567890abcdef;" }

The trailing semicolon is required even for a single value [gist.github.comrobertschouten.com]. It denotes the end of the term entry.

What about that mysterious -1 we sometimes see in examples? In some documentation, you might see formats like "Label|-1|GUID;". The -1 represents the WssId (a SharePoint internal ID for the term in the site collection’s hidden list) or a LCID. When -1 is used, it typically means “let SharePoint figure out the WssId”. In our context, you can actually omit the -1| portion – SharePoint will handle it if you just provide Label and GUID. However, some references include it. For simplicity, we’ll continue without it in our examples, as it usually works with just Label|GUID. If you find it not working, you can try including -1| right before the GUID. For instance: "Finance|-1|1234-...;" – both approaches are known to work [gist.github.com].

FieldValue format (Multi-value Metadata): For multiple terms, you concatenate each term in the string, separated by semicolons, and each term entry ends with a semicolon. For example, if you have a multi-value metadata field (let’s call it Tags) and you want to set two terms: “HR” (GUID aaaa...) and “Payroll” (GUID bbbb...), you would send:

{
  "FieldName": "Tags",
  "FieldValue": "HR|aaaaaaaa-1111-2222-3333-bbbbbbbbbbbb;Payroll|bbbbbbbb-2222-3333-4444-cccccccccccc;"
}

So it’s Label1|GUID1;Label2|GUID2; – each term separated by ; and each has its trailing semicolon [gist.github.com]. Essentially, for N terms, you’ll have N semicolons in the string (one after each term’s GUID).

SharePoint will parse that and assign the two terms to the field. If any term is not found (e.g. typo in label or wrong GUID), that specific term might fail validation.

Common pitfalls:

The GUID must be the Term’s ID, not the Term Set ID or anything else. If you select a term in the SharePoint UI and use the developer tools or a query, you can obtain its GUID. Alternatively, if you only know the term label and it’s unique, SharePoint might resolve by label, but it’s not guaranteed or advisable. Including the GUID is the surest way.
Label is case-insensitive as far as matching the term, but it’s good to use the exact capitalization as the term. If the label has a “|” or “;” character in it (rare, but possible), that could break the format – hopefully your term labels don’t include those characters.
The format with -1|GUID or just GUID – both have been used in examples. Using -1 as the second token is essentially telling SharePoint “I don’t have a valid WssId, please look up the term by GUID and assign it”. SharePoint will then replace -1 with the correct WssId internally. Most of the time, you can skip the -1| and just do Label|GUID;. If you have issues, try the -1| in the middle. For example, the gist of field formats shows an example: "Department 2|-1|220a3627-4cd3-453d-ac54-34e71483bb8a;" [gist.github.com] – here Department 2 is the label, followed by -1| then the GUID, then semicolon. The -1 is not an ID of the term; it’s just a placeholder indicating no ID (so SharePoint should create/lookup one).
For multi-value, ensure the string is one continuous string. In some documentation, they show it on multiple lines for readability, but it actually should be one line. There should be no extra semicolon at the very end beyond each term’s terminator (though a trailing semicolon at the very end is fine and typically present).

Other Field Types (Quick Notes)

The question didn’t explicitly ask for others, but for completeness, a few other common types:

Text (Single line) and Note (Multiline text): These are straightforward – just put the text in FieldValue. E.g. "Description": "This is a sample text.". Multiline text can include line breaks \n if needed.
Number: Similar to currency but without currency symbol. Just provide the number as a string (or number). E.g. "FieldValue": "42.5" for a number column.
Yes/No (already covered) – use "1"/"0".
Calculated: You generally cannot set a calculated column (it’s computed).
GUID: Provide a GUID string if needed (rare). E.g. "FieldValue": "3cf2375d-5c8e-4efc-95a3-73a8b4e82102" for a GUID field.
Attachments: You can’t directly add attachments via this; you would use a different API to attach files. But you can set the Attachments field to 0 or 1 possibly (though it’s read-only indicating if attachments exist).

Now that we’ve seen all the formats, let’s piece it all together with how to incorporate this into the Power Automate flow and consider when to use this method.

Using the HTTP Action in a Flow – End-to-End Example

To illustrate, let’s say we have a SharePoint Online list called Projects with the following columns we want to update via validateUpdateListItem:

Title (Single line text)
Approved (Yes/No)
Start Date (Date)
Budget (Currency)
Category (Lookup to a Categories list)
Status (Choice)
Tags (Choice multi-select)
Project Manager (Person)
Related Teams (Person multi-select)
Website (Hyperlink)
Department (Managed Metadata single-select)

We want to update item ID 42 in this list.

Our HTTP request action would be configured as:

Method: POST
URI: _api/web/Lists/GetByTitle('Projects')/items(42)/validateUpdateListItem
Headers: (Accept and Content-Type as discussed)
Body: something like below (formatted for readability):

{
  "formValues": [
    { "FieldName": "Title", "FieldValue": "Project Apollo" },
    { "FieldName": "Approved", "FieldValue": "1" },
    { "FieldName": "StartDate", "FieldValue": "2025-07-01 00:00:00" },
    { "FieldName": "Budget", "FieldValue": "250000" },
    { "FieldName": "Category", "FieldValue": "3" },
    { "FieldName": "Status", "FieldValue": "Active" },
    { "FieldName": "Tags", "FieldValue": "High Priority;#Internal" },
    { "FieldName": "ProjectManager", "FieldValue": "[{'Key':'i:0#.f|membership|alice@contoso.com'}]" },
    { "FieldName": "RelatedTeams", "FieldValue": "[{'Key':'i:0#.f|membership|teamlead@contoso.com'},{'Key':'i:0#.f|membership|engineer@contoso.com'}]" },
    { "FieldName": "Website", "FieldValue": "https://contoso.com/projects/apollo, Apollo Internal Site" },
    { "FieldName": "Department", "FieldValue": "Research|d85a5c3f-447a-4d5c-9df4-4baf12345678;" },
    { "FieldName": "Editor", "FieldValue": "[{'Key':'i:0#.f|membership|<your login here>'}]" }
  ],
  "bNewDocumentUpdate": true
}

A few things to note in this example body:

We included Editor with the current user’s claim and set bNewDocumentUpdate: true. This means the update will not create a new version [sharepains.com] and by setting Editor to the same value, SharePoint will treat it as if the last modified by didn’t change, preventing a version bump [sharepains.com]. Essentially this achieves a system update (silent update).
We set Approved to "1" (Yes), StartDate in a standard format, Budget as a number, Category as an ID, Status/Tags with appropriate strings, and the complex fields with their required JSON strings.
If any value is invalid (say we put an incorrect GUID or a choice that doesn’t exist), validateUpdateListItem will return a response indicating which field failed and why. A successful response will return a JSON payload listing each field updated and ErrorMessage:null for each [robertschouten.comrobertschouten.com]. In Power Automate, you can capture the output and parse it if needed.

Comparing `validateUpdateListItem` with the Standard "Update item" Action

In conclusion, why go through the trouble of using validateUpdateListItem instead of the simpler built-in Update item action? Here’s a quick comparison:

Standard Update item:
- Pros: Very easy to use for basic updates. You just fill in the fields in the action and it updates them. No need to know internal names or REST endpoints.
- Cons: It cannot modify system fields like Modified or Modified By. It always counts as a user update (incrementing version and triggering flows). It doesn’t easily handle certain complex field types (for example, multi-select person or taxonomy) unless you supply data in the exact format anyway (and some fields like Managed Metadata can’t be set via Update item in Power Automate at all). Also, you cannot do “no version” updates with it – every call is a normal edit.
validateUpdateListItem via HTTP:
- Pros: Enables system updates – you can update an item without changing Modified By/date and without creating a new version (when used with bNewDocumentUpdate:true and setting Editor) [robertschouten.comsharepains.com]. This is perfect for scenarios like updating a status flag in the same flow that was triggered by an update (avoiding infinite loops). It also allows setting values that are otherwise read-only (like you could copy an old Modified date into the Modified field to essentially undo a timestamp change). It supports updating fields that Power Automate’s UI doesn’t support well (people fields require just an email in UI, but you might want to set multiple people, etc., which the HTTP method handles by the formats we used). Basically, it gives you full flexibility of SharePoint’s API.
- Cons: It’s more complex to set up. You have to form the JSON correctly, know internal field names, and handle the claims/ID formats. A mistake in the format can cause the update to fail. Debugging might require looking at the HTTP response. It’s also an “HTTP request”, which some business users shy away from, but it’s not too difficult once you have examples.

When to prefer validateUpdateListItem:

When you need to perform silent updates that shouldn’t retrigger your flow or bump version history (e.g., writing back a “Processed” flag on the item that triggered the flow) [sharepains.comtomriha.com].
When you need to update fields like Managed Metadata, Multi-person, or Hyperlink in one go – especially if the standard action doesn’t support them easily.
When you need to update Modified By/Modified (system columns) or do special things like “system update” for record-keeping reasons (perhaps to avoid showing a service account as the last editor). For instance, some solutions capture the original Modified date and user, then use this method to reapply them after making changes, so it’s as if nothing changed those fields [sharepoint.stackexchange.com].
If you want a single action to update many fields at once (the HTTP request can set multiple fields in one call, whereas you might otherwise use multiple actions or a single Update item action which may be fine but can’t do some of the above points).

When to use the normal Update item: If your update is straightforward (e.g., just updating a text or choice field) and you don’t need the special capabilities, the standard action is simpler and less error-prone. Use validateUpdateListItem only when you have a specific need that it addresses (or if you’re comfortable with it and prefer its flexibility).

Finally, always test your flow with sample data. If a field fails to update, inspect the HTTP response. The validateUpdateListItem returns a detailed result per field with an error message if something went wrong [robertschouten.com]. This can help you debug (for example, an invalid choice value or a wrong term GUID will produce an error message in the response for that field). You can see those by capturing the output of the HTTP action (it’s a JSON with a "value" array of results).

Conclusion: Using the SharePoint REST API’s validateUpdateListItem in Power Automate opens up advanced scenarios like system updates and updating complex field types. It requires a bit more JSON crafting, but with the examples provided above, you can update Yes/No, Date, Currency, Lookup, Choice, Person, Hyperlink, and Managed Metadata fields with ease. This approach is especially powerful for SharePoint Online where keeping flows efficient and avoiding unnecessary versioning is important. Once you get the hang of it, validateUpdateListItem can be a reliable tool in your Power Automate arsenal for SharePoint integration.

References

Pieter Veenstra – System Updates in SharePoint from Power Automate using the ValidateUpdateListItem endpoint (SharePains blog, 2024) – Explanation of using validateUpdateListItem for silent updates, importance of Editor field, and example JSON - sharepains.comsharepains.com.
Robert Schouten – Update file metadata with REST API using ValidateUpdateListItem method (2018) – Overview of the endpoint’s benefits and formats for taxonomy, person, hyperlink fields - robertschouten.comrobertschouten.com.
Phillip Harding (GitHub Gist) – SharePoint REST API Add/ValidateUpdateListItems – A cheat-sheet of FieldName/FieldValue formats for various field types (Yes/No, Choice, Lookup, User, etc.) - gist.github.comgist.github.com.
CLI for Microsoft 365 – spo file add documentation – Examples of updating metadata (person, date, URL, choice, yes/no, lookup, currency) via validateUpdateListItem under the hood - pnp.github.iopnp.github.io.
Stack Overflow – Update 'date' column using 'ValidateUpdateListItem' endpoint – Discussion on date format issues and recommendation of a locale-independent format (YYYY-MM-DD hh:mm:ss) for date/time values - stackoverflow.com.
SharePoint StackExchange – Various Q&A on using ValidateUpdateListItem for updating Author/Editor without changing Modified datesharepoint.stackexchange.com and handling person field claimslearn.microsoft.comlearn.microsoft.com. These reinforce how to format special fields in the JSON.

Citations

System Updates in SharePoint from Power Automate using the ValidateUpdateListItem endpoint

https://sharepains.com/2024/01/05/system-update-sharepoint-power-automate/

System Updates in SharePoint from Power Automate using the ValidateUpdateListItem endpoint

https://sharepains.com/2024/01/05/system-update-sharepoint-power-automate/

System Updates in SharePoint from Power Automate using the ValidateUpdateListItem endpoint

https://sharepains.com/2024/01/05/system-update-sharepoint-power-automate/

Update file metadata with REST API using ValidateUpdateListItem method – ROBERT SCHOUTEN

https://robertschouten.com/2018/04/30/update-file-metadata-with-rest-api-using-validateupdatelistitem-method/

System Updates in SharePoint from Power Automate using the ValidateUpdateListItem endpoint

https://sharepains.com/2024/01/05/system-update-sharepoint-power-automate/

System Updates in SharePoint from Power Automate using the ValidateUpdateListItem endpoint

https://sharepains.com/2024/01/05/system-update-sharepoint-power-automate/

System Updates in SharePoint from Power Automate using the ValidateUpdateListItem endpoint

https://sharepains.com/2024/01/05/system-update-sharepoint-power-automate/

SharePoint REST API Add/ValidateUpdateListItems · GitHub

https://gist.github.com/phillipharding/30714d4ee245bfc0cba5699b6bb4193e

sharepoint - Update 'date' column using 'ValidateUpdateListItem' endpoint - Stack Overflow

https://stackoverflow.com/questions/71842491/update-date-column-using-validateupdatelistitem-endpoint

System Updates in SharePoint from Power Automate using the ValidateUpdateListItem endpoint

https://sharepains.com/2024/01/05/system-update-sharepoint-power-automate/

Update file metadata with REST API using ValidateUpdateListItem method – ROBERT SCHOUTEN

https://robertschouten.com/2018/04/30/update-file-metadata-with-rest-api-using-validateupdatelistitem-method/

spo file add - CLI for Microsoft 365

https://pnp.github.io/cli-microsoft365/cmd/spo/file/file-add/

System Updates in SharePoint from Power Automate using the ValidateUpdateListItem endpoint

https://sharepains.com/2024/01/05/system-update-sharepoint-power-automate/

SharePoint REST API Add/ValidateUpdateListItems · GitHub

https://gist.github.com/phillipharding/30714d4ee245bfc0cba5699b6bb4193e

SharePoint REST API Add/ValidateUpdateListItems · GitHub

https://gist.github.com/phillipharding/30714d4ee245bfc0cba5699b6bb4193e

Sharepoint REST ValidateUpdateListItem return error response. - Microsoft Q&A

https://learn.microsoft.com/en-us/answers/questions/1018412/sharepoint-rest-validateupdatelistitem-return-erro

Sharepoint REST ValidateUpdateListItem return error response. - Microsoft Q&A

https://learn.microsoft.com/en-us/answers/questions/1018412/sharepoint-rest-validateupdatelistitem-return-erro

Sharepoint REST ValidateUpdateListItem return error response. - Microsoft Q&A

https://learn.microsoft.com/en-us/answers/questions/1018412/sharepoint-rest-validateupdatelistitem-return-erro

Sharepoint REST ValidateUpdateListItem return error response. - Microsoft Q&A

https://learn.microsoft.com/en-us/answers/questions/1018412/sharepoint-rest-validateupdatelistitem-return-erro

Update file metadata with REST API using ValidateUpdateListItem method – ROBERT SCHOUTEN

https://robertschouten.com/2018/04/30/update-file-metadata-with-rest-api-using-validateupdatelistitem-method/

SharePoint REST API Add/ValidateUpdateListItems · GitHub

https://gist.github.com/phillipharding/30714d4ee245bfc0cba5699b6bb4193e

Update file metadata with REST API using ValidateUpdateListItem method – ROBERT SCHOUTEN

https://robertschouten.com/2018/04/30/update-file-metadata-with-rest-api-using-validateupdatelistitem-method/

SharePoint REST API Add/ValidateUpdateListItems · GitHub

https://gist.github.com/phillipharding/30714d4ee245bfc0cba5699b6bb4193e

SharePoint REST API Add/ValidateUpdateListItems · GitHub

https://gist.github.com/phillipharding/30714d4ee245bfc0cba5699b6bb4193e

Update file metadata with REST API using ValidateUpdateListItem method – ROBERT SCHOUTEN

https://robertschouten.com/2018/04/30/update-file-metadata-with-rest-api-using-validateupdatelistitem-method/

Update file metadata with REST API using ValidateUpdateListItem method – ROBERT SCHOUTEN

https://robertschouten.com/2018/04/30/update-file-metadata-with-rest-api-using-validateupdatelistitem-method/

Update SharePoint column without new item version in Power Automate

https://tomriha.com/update-sharepoint-column-without-new-item-version-in-power-automate/

Can i update a list item without affecting the Modified By and ...

https://sharepoint.stackexchange.com/questions/314160/can-i-update-a-list-item-without-affecting-the-modified-by-and-modified-date

Update file metadata with REST API using ValidateUpdateListItem method – ROBERT SCHOUTEN

https://robertschouten.com/2018/04/30/update-file-metadata-with-rest-api-using-validateupdatelistitem-method/

SharePoint REST API Add/ValidateUpdateListItems · GitHub

https://gist.github.com/phillipharding/30714d4ee245bfc0cba5699b6bb4193e

SharePoint REST API Add/ValidateUpdateListItems · GitHub

https://gist.github.com/phillipharding/30714d4ee245bfc0cba5699b6bb4193e

spo file add - CLI for Microsoft 365

https://pnp.github.io/cli-microsoft365/cmd/spo/file/file-add/

All Sources

Search This Blog

That O365 Guru from Cape Town (#NadirKamdar)