Why?
The Managed Metadata columns are now supported in Microsoft Flow so in general you would not have to resort to his “old school” method. But unfortunately there are no out-of-the-box Microsoft Flow actions (yet) to do this through the ease-to-use steps and dynamic content.
What?
This post will be a deep dive for updating Managed Metadata with a single value select setting using the Send an HTTP request to SharePoint action of Microsoft Flow. Much was already explained in the previous post: https://knowhere365.space/sharepoint-document-set-update-through-microsoft-flow/ so make sure that you read the context there.
How?
So you already have a site with a library in which you have added your Document set content type and there are some Document sets created in this library. In my example I want to update the Document Set immediately after creation (you cannot create a document set and update properties of it within the same HTTP call) but because one of the columns I want to update is a Managed Metadata column, we need to prepare some things.
1) I named my Managed Metadata column MM_BacklogItemStatus and this column does not allow multiple values. This single value select managed metadata column is pretty simple to update when you realize that a term in the term store is a collection of data. Just by adding the name of your column and three simple items in an array you can update the column:
The snippet of code in the body that is relevant for this post:
"MM_BacklogItemStatus":{
"Label":"@{triggerBody()?['MM_BacklogItemStatus']?['Label']}",
"TermGuid":"@{triggerBody()?['MM_BacklogItemStatus']?['TermGuid']}",
"WssId": @{triggerBody()?['MM_BacklogItemStatus']?['WssId']}
}
This will only update the managed metadata if the value is empty. if there is already a value some extra work is needed 😒
1) The special thing to know is that a Managed Metadata column gets an extra hidden column which will always be the InternalName of your own column followed by _0 or _1 at the end. Make sure which number to use by searching for your column in the URL:
[varWebUrl]/_api/Web/Lists(guid'[varListGUID]')/fields
In my example the hidden column was named MM_BacklogItemStatus_0 and the fastest way to verify you will have the correct DisplayName of this hidden column is using Method 3 of my previous post: https://knowhere365.space/sharepoint-column-internal-name/
Using this method you will see that the InternalName is a special kind of code (like a GUID): in my example the InternalName of this hidden column was m3ab6bbabf1e4efaa8bb1e6cf9a3cf9a and this hidden column is what we need in our Microsoft Flow. You can off course use this new found GUID like code as a hard coded string in your Microsoft Flow but I desire some more flexibility / reusability so I put in a Send an HTTP request to SharePoint to get this GUID like code:
The code for the call:
_api/web/lists(guid'@{variables('varListGUID')}')/Fields/GetByTitle('@{variables('varMM_BacklogItemStatus')}_0')
The variable varMM_BacklogItemStatus is just the InternalName of the column MM_BacklogItemStatus and for this call I add _0 at the end. So again you could just use the hard coded MM_BacklogItemStatus_0 but I like to type as less as possible. 🦥
When you do not use this InternalName the flow will error out with a notification like: “An unexpected ‘PrimitiveValue’ node was found when reading from the JSON reader. A ‘StartObject’ node was expected.“.
2) We will use the response of this request to get the InternalName:
The code for this variable:
@{body('Send_an_HTTP_request_to_SharePoint_-_InternalNameMM_BacklogItemStatusHidden')['d']['InternalName']}
3) This InternalName we can use in our update call:
The snippet of code in the body that is relevant for this post:
"@{variables('varMM_BacklogItemStatusHiddenInternalName')}":"@{triggerBody()?['MM_BacklogItemStatus']?['Value']}"
Not that I use the Value part of the dynamic information of the Managed Metadata column:
This is simply a shortcut to the combination of the Label and the TermGUID separated by a pipeline: To do|81ab7a4c-81bf-4b2c-8fd6-d72ac08bdb08
You could also combine these parts of information yourself with a formula or store it in a variable:
@{triggerBody()?['MM_BacklogItemStatus']?['Label']}|@{triggerBody()?['MM_BacklogItemStatus']?['TermGuid']}
Now the single value managed metadata column will be updated wheither a value is empty or not.
Multi value managed metadata will be my next post because as you may guess already, this is not as simple but is built on the same logic as this post 🧱
After more testing, here is what I am seeing:
1.) Create the document set using HTTP Request to SharePoint (as you have outlined). This works fine.
2.) Update the document set properties using HTTP Request to SharePoint (as you have outlined). On the update I am updating text fields and a managed metadata field.
— The text fields update fine.
— The managed metadata field continues to be blank.
3.) I then went into the document set and manually selected an arbitrary value for the managed metadata field.
4.) Next I re-ran the Flow to update the document set managed metadata field using HTTP Request to SharePoint. Then the update works – the managed metadata field is filled in with the correct value.
Any ideas on why it seems that a value already has to be in the managed metadata field before the update works? I am consistently seeing this behavior as I am testing and analyzing.
Thank you again.
Hi Paige,
The extra work at the moment is that you need to have the ID of the Document Set. Right after creation of a new Document Set, you can get the ID from the output of the creating HTTP request but when you update an existing one you need to get the ID first.
I cannot reproduce any issues… I have the same Flow being triggered on a creation/modification of a SharePoint List Item and this Flows creates a new Document Set if not already existing and updates an existing Document Set if there is an existing one.Both update HTTP request actions are exactly the same in my Flow.
You are using the GUID of the Managed Metada Column and the right SP.Data in the Body of the HTTP request, as explained here: https://knowhere365.space/microsoft-flow-update-sharepoint-document-set/
I did read something about Managed Metadata having a Default Value could cause some issues –> do you have a Default Value configured for the Managed Metadata Column in the Document Library with the Document Sets?
If so –> can you check without a Default Value
Yes, I am getting the newly created document set ID to use in the call. I can set the text field property with no issues. It is the managed metadata field property that will not set unless there is a value there already.
For this document set, no default value is in place.
(I do have this same problem with another document set that does have a default value in a managed metadata field…. it won’t set either, but text values do get set.)
It is a very curious issue. I will keep looking. Thanks again.
Very curious indeed!
Let us continue trouble shooting on the Community Forum?
https://powerusers.microsoft.com/t5/Microsoft-Power-Automate/ct-p/MPACommunity
There we may have others joining our quest and there we can share screenshots / code better than in this simple Reply-section of a blog post 👍 (don’t forget to tag me 😁)
I ended up trying one more method, and oddly enough this is working so far.
Rather than using the HTTP Request action I used the Update Item SharePoint action. Within the Body of the action I used the following:
“Field_x0020_Name”: [
{
“Value”: “-1:#|1b344941-ff1c-4db0-b57d-cdeb26cc3bf3;-1:#|f3e13b30-247f-4f35-bb4f-e833724f2d46”
}
]
I did not have to use the hidden name or append _0 to the field name. Not sure why using the Update Item action worked, but it set the managed metadata field without me having to manually insert a value initially.
I will continue to test, but I really appreciate the time you have taken to help me figure this out. If in the end this still causes problems I will post in the Community Forum as you have suggested and tag you.
Thanks again!
Thank you for responding so quickly. I will continue to investigate as this used to work. One more question. You indicated in your post that “This will only update the managed metadata if the value is empty. if there is already a value some extra work is needed.” What are the extra steps in this case if data is already in the field? Thank you.
Hi Paige, if you use the Internal Hidden Column Name of the target column and the Label|GUID combination then the update should also work. You just have to make sure to use the correct ID of the target library.
Example of HTTP request to SharePoint that still works for me today to update existing items with existing values:
URI
_api/web/lists(guid’d4969af7-c0ee-4961-ad93-b26d8f19dfc5′)/items(196)
Headers
{
“Content-Type”: “application/json;odata=verbose”,
“Accept”: “application/json;odata=verbose”,
“X-HTTP-METHOD”: “MERGE”,
“If-Match”: “*”
}
Body
{
“__metadata”:{
“type”:”SP.Data.LibraryWithSetsItem”
},
“DocumentSetDescription”:”Set created by : Django Lohn”,
“m3ab6bbabf1e4efaa8bb1e6cf9a3cf9a”:”To do|81ab7a4c-81bf-4b2c-8fd6-d72ac08bdb08″,
“h9846defb6324a1cb093e17339e9c7ad”:”Power Apps|50e4535b-2b61-4d0b-a3c5-210467d1a82c;Power Automate|b6af564d-cd77-43b1-9249-a1a5e099068f;SharePoint Online|fd0b2a0d-b14c-414c-a804-73954ab0674b;”
}
I have had other people also complain about this concept not working, but I have flows from over a year that are still working fine so without more info about what is failing at your side, I can only say to follow the instructions to the letter.
Also, this used to work perfectly for me (in cases where there is not data already in the managed metadata field), but for the past 6 months I can no longer set the values. Do you know if the technique has changed or if there are other oddities that may be in play? Thanks so much for your excellent posts!
Hi – do you have a workaround for when there is already data in the managed metadata column? Referring to your note above:
This will only update the managed metadata if the value is empty. if there is already a value some extra work is needed 😒
I think the screenshot for #3 is not appropriate. It doesn’t have the internal field name ‘varMM_BacklogItemStatusHiddenInternalName’
You are absolutely right Vinoth! Thanks for the correction 👍