Setting managed metadata fields in a Nintex workflow

Up until now, I have not really had a need to work with managed metadata fields in a Nintex workflow. My first impression was that it would be pretty straightforward, maybe get as complicated as working with lookup lists. Unfortunately, it was a bit more complicated than I expected. Hopefully this post will help others who may be having issues with this.

This Nintex connect thread explains how to get the values, but I could not understand updating managed metadata fields with this approach. I also came across a dev blog on how this works in detail. I found a pretty straightforward solution that works without the need to go digging for term IDs in a site’s TaxonomyHiddenList (<Web URL>/Lists/TaxonomyHiddenList/AllItems.aspx). You may want to refer to these articles on how to retrieve the term GUID if you do not already have this.

In our scenario, we have a list and a document library with a managed metadata property. After an approval process on the list is finished, a document is created in the document library. The value stored in the managed metadata property on the list should be copied to the same managed metadata property on the document library.

At first glance this looks pretty straightforward, after creating a new document in the document library I just call the Update an item Nintex action and set the metadata field based on what is stored in the list, right? Except when I tried this, no value is populated in the destination list. There were also no error messages.

As an example, I have a managed metadata property on my list called Primary Category

What is important to understand is that for each managed metadata column, the list has two separate columns:

  1. One is a Taxonomy field type with the name of the managed metadata property, in our case PrimaryCategory
    1. When reading this value it is in the fomat: Name of term|GUID of term
    2. For example: Engineeering|6154607f-c48e-4583-bc0e-3603e521537c
  2. The other is a Note type and has a name of fieldname TaxHTField0, in our case PrimaryCategoryTaxHTField0.

In order to update this value we have to set both fields. The format to set these is:

Field TypeFormatExample (note, no spaces!)
Taxonomy field-1;#Name_of_term|GUID_of_term-1;#Engineeering|6154607f-c48e-4583-bc0e-3603e521537c
Note fieldName_of_term|GUID_of_termEngineeering|6154607f-c48e-4583-bc0e-3603e521537c

The -1 notation is actually supposed to be the Term ID value, but setting this as -1 tells SharePoint that we don’t know what this is, so SharePoint will figure it out for us.

The only way to set these values in Nintex is with a Call web service action and leveraging the SharePoint Web Services.

I have noticed that before calling the web service action, the values should be stored in a single line of text variables first, otherwise this would not update correctly for me.

  • txtTermFull stores the value read from the managed metadata field (Name_of_term|GUID_of_term)
  • txtTermFullMinus1 is populated from a Build String action with a value of (no spaces!): -1;# Name_of_term|GUID_of_term or also -1;#{WorkflowVariable:txtTermFull}
  • You will also need the list ID you will be updating, in my case this is set to a list item ID field lidDocID earlier in my workflow.

The web service call looks something like this:

The CDATA tags are not required, I just use them as a best practice. Here is the full XML when calling the UpdateListItems web method on <Web URL>/_vti_bin/lists.asmx

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="" xmlns:soap="" xmlns:m="">
      <m:listName>CRL Documents</m:listName>
        <Batch OnError="Continue" ListVersion="1" ViewName="">
          <Method ID="1" Cmd="Update">
            <Field Name="ID">{WorkflowVariable:lidDocID}</Field>
            <Field Name="PrimaryCategory"><![CDATA[{WorkflowVariable:txtTermFullMinus1}]]></Field>
            <Field Name="PrimaryCategoryTaxHTField0"><![CDATA[{WorkflowVariable:txtTermFull}]]></Field>

If this is not getting set correctly, validate the fieldnameTaxHTField0 field exists. You can check this by emailing yourself (in plaintext) the web response of the web service call.

The above scenario only caters to a single managed metadata column type. If multiple values were allowed you would still apply the same concept as above. An easy way to do this is to use the Regular expressionaction and replace the semi-colon (;) with a -1;# and store this in a new variable. You also want to prepend this new variable value with a -1;#.


The full term value:

Construction|543622c3-8542-40af-9f01-9129c1cc2917;Corporate|7b21c2ea-b994-4c64-8b43-78b05464b0f8;Employee Development|ed96010a-04ba-4e17-b4f8-6ee5b72fde05

The full term minus 1 value:

-1;#Construction|543622c3-8542-40af-9f01-9129c1cc2917-1;#Corporate|7b21c2ea-b994-4c64-8b43-78b05464b0f8-1;#Employee Development|ed96010a-04ba-4e17-b4f8-6ee5b72fde05

If you are setting more than one managed metadata property at once where some of them are required and others are not, it is okay to have blank values in the web service call. Just make sure you are not including -1;# on empty values.

So that’s it, a pretty straightforward way of setting a managed metadata field in Nintex workflow. If you are having any issues or have any questions just let me know.

Stories say it best.

Are you ready to make your workplace awesome? We're keen to hear what you have in mind.

Interested in learning more about the work we do?

Explore our culture and transformation services.

Our commitment to reconciliation

Learn how Habanero is responding to the Truth and Reconciliation Calls to Action as a settler-owned company operating on Indigenous territories across what is now called Canada.

Read about our commitment