Send HTTP Request Patch action not setting only the column configured in it

[Anonymous]

I have an HTTP Send request Patch action to set a text column in SharePoint Online list with the value of a variable. (See image below)

Which works, but it also sets the value of another text column in SharePoint to the same thing.

There are no other HTTP Send request Patch actions in the flow that would set the column DivisionManager

How can I get it to set just the column that is noted in the action?

Any and all help would be greatly appretiated.

Thanks

[wskinnermctc]

I'm just taking a couple of guesses that you might be able to check.

SharePoint Columns are Linked by Calculated or Lookup:

• (DivisionManager is calculated to equal ManagerText)
• Go to the list settings and see the column types.

SharePoint Column is default to equal the other column:

• Check to see if there is a default value for the DivisionManager column which may be automatically pulling in the ManagerText column when a new item is created.
• Go to the list settings and then into the column settings and see if there is a default value.

Refresh the browser screen:

• Sometimes when power automate posts things to a list it can appear that values are in different columns when really it is just the view of the browser trying to catch up.
• Click refresh to make sure all the values are in the columns.

Why use the PATCH method and then step on it with the X-HTTP-Method: MERGE?

• The X-HTTP-Method will make the request a MERGE and not a PATCH.
• So just put MERGE in the initial method and take the X-HTTP-Method out of the header.

Add a new column to the list and test again to see if you get same results for the test column being filled like the DivisionManager column.

• Can show if it is an individual column issue or all columns issue

Add the DivisionManager field to your http request and test it by filling with another text to see if it is still writing the ManagerText or if it accepts your new test text.

[Anonymous]

Hello  @wskinnermctc 

Thank you for look at this. I really appreciate it

See image below for the column settings

Refresh the browser screen: Done, no change

Why use the PATCH method and then step on it with the X-HTTP-Method: MERGE?

• The X-HTTP-Method will make the request a MERGE and not a PATCH.
• So just put MERGE in the initial method and take the X-HTTP-Method out of the header.

Do you mean like so:

Or did you mean 

Why use the PATCH method and then step on it with the X-HTTP-Method: MERGE?

• The X-HTTP-Method will make the request a MERGE and not a PATCH.
• So just put PATCH in the initial method and take the X-HTTP-Method out of the header.?

I have also created another text field and it did not populate, so I deleted the ManagerText and Division Manager columns and created 2 new ones in thier place called Line Manager Approval and Division Manager Approval

I set the Http request to

 And it failed with the result 

Invalid JSON. A colon character ':' is expected after the property name 'Line', but none was found.
clientRequestId: d83f7f9f-36a0-4cfc-b1ff-75df1a9af82a
serviceRequestId: 10758fa0-6055-3000-2ec0-47e3caa00cf3

I swapped out the spaces

[Anonymous]

Thanks @wskinnermctc 

tried what you suggested, there are no defaults, calcs or lookups on either. I did create a test column also a single line of text but it didn't populate.

I deleted the columns and created 2 new text columns in their place;

I updated the HTTP Request to below

I got an error;

replaced the spaces with %20 but I get the same error.

Not sure what this issue is now.

[wskinnermctc · Accepted solution]

Ok, a couple of things to look at here because you made new columns. The name of the column when using http requests has to match the internal/entitypropertyname of the column. These names are kind of encoded, but they use SharePoint's special encoding, not the usual encodeUrl.

You can see the name that will be used in the browser address bar when looking at the column settings. I made the same columns in a list and highlighted what is in the address bar.

New SharePoint Column Names

Also, you can send an HTTP request to the list using the endpoint "/fields" and it will get all columns/fields for the list and the properties of each. I'm putting an example below, and I specifically selected some properties to trim up the output. But you could just end it with /fields and get every property for each column/field.

_api/lists/getByTitle('@{variables('ListName')}')/fields?$select=
DefaultFormula,
DefaultValue,
Description,
EntityPropertyName,
Id,
InternalName,
Required,
StaticName,
Title,
FieldTypeKind,
TypeAsString

Below is an example of the get fields http GET request.

HTTP GET Fields selected properties

Below is the output when running the http GET fields. 

HTTP GET Fields Output Results

So even though I named the columns "Line Manager Approval" and "Division Manager - Approval_Test" the names to use in the http request will be "Line_x0020_Manager_x0020_Approva" and "Division_x0020_Manager_x0020_x0" even though they seem incomplete. 

Here is an example of the Patch when using the new column names. 

Patch Step with New Columns

And the Outputs of the step look like this:

Patch New Columns Output

All of the above will help you get more specific info on what to put in the name of the field for the PATCH request, but it doesn't explain why you are getting duplicate results for those columns. 

Could you run the HTTP GET request for the fields and then find the two columns in the output and see if there is anything that might be causing them to be the same. You could run the GET request without the selected properties and then then screen shot the results for each of the columns ManagerText and DivisionManager. Maybe we can see something within those column properties that is causing this issue?

[Anonymous]

Hello @wskinnermctc 

Thank you that worked perfectly. I didn't realize the encoding was different (or I didn't pay attention).

Thank you so much for your help

Cheers!

DWTKBrook

[wskinnermctc]

Glad you have it working. I had just made something hopefully it could help you in the future.

1. Put quotes "" around your field names since that can help the step recognize text.
   • "ManagerText": "Derek" instead of ManagerText: "Derek"
   • "DivisionManager": "VP Sally" instead of DivisionManager: "VP Sally"
2. Spell the values in the "Accept" header correctly since you had application spelled as apllication
   • application/json;odata=verbose
   • (This header isn't even required for a POST or PATCH since it is instructing the response that is returned, not instructing the action patch/merge being done.)
   • It is saying "I'll Accept responses from my HTTP request as format application/json and I want ALL response data so my odata is verbose.")
3. The header X-HTTP-METHOD only works for requests that have an initial POST selected Method and then changes it into whatever the X-HTTP-METHOD value is.
   • A request as POST with a header X-HTTP-METHOD of MERGE turns the http request into a MERGE
   • A request as POST with a header X-HTTP-METHOD of PATCH turns the http request into a PATCH
   • A request as PATCH with a header X-HTTP-METHOD of MERGE does nothing since a PATCH doesn't recognize a header X-HTTP-METHOD it is basically ignored. Remains a PATCH request.

Below I'm showing a step that would be considered a MERGE request:

HTTP Request POST with X-HTTP-METHOD MERGE

Below I'm showing a step that would be considered a PATCH request:

HTTP Request PATCH

Below is showing that a PATCH action is the same as a POST action that has X-HTTP-METHOD PATCH

HTTP Request PATCH is same as POST with X-HTTP-METHOD PATCH

Below explains how the X-HTTP-METHOD functions in a request

Microsoft Learn - Header Fields - X-HTTP-METHOD 

Below explains what the Accept header is used for in a request

Microsoft Learn - Basic Operations REST Endpoints - Reading Data 

For sharepoint - the PATCH and MERGE methods are going to produce the same results. 

Learn Microsoft - Protocols - PATCH/MERGE 

The only difference between an HTTP request that uses MERGE or PATCH and PUT is client intent.

Since MERGE is not one of the verbs that is defined in the HTTP specification [RFC2616], using the MERGE verb might not flow through network intermediaries as seamlessly as methods that are defined in the HTTP specification. The HTTP PATCH verb is preferred over HTTP MERGE when working with data services that support the OData 3.0 protocol. 

I guess we never really figured out why you were getting duplicate postings in the fields, but hopefully some of this content helps with making other HTTP requests.