Give these steps a try. I know it's not the most optimal to re-retrieve the list item even though it may already be available in the Start Event, but you can get the Metadata Label field this way.
1. Use the "Retrieve an item" action to retrieve the current item that starts your workflow.
2. Set the Item ID based on the start event ID variable that triggers your workflow.
3. Store the result in an object variable for that list/library item.
From there you can get to the metadata fields Label variable which stores a semi-colon delimited list of your selected metadata values:
Results:
You can also use the Apply a regular expression action to take the metadata variable's delimited text string and load it into a collection using the Split option with a semi-colon. From there you can work through the list as needed.
Hope that helps!
Wow, @JRoberts, what a perfectly described and illustrated solution! Thanks for your fast help here, it worked like a charm!
Kind regards and happy weekend!
Tim
As this is a suitable workaround, why in the world the StartEvent does not contain all fields from a given list or library?
As it can be done with a “Retrieve an item”-Action, it may has no technical reason.
Are there any plans to fix this bug (you may call it a limitation)?
Please excuse my impatience, but moving a corporate farm to NAC and encountering a new obstacle every day can be very frustrating.
With kind regards, Ronny
When using “Retrieve an item”-Action, I do not get the Label fields as in your screenshots.
If I log the field values, I get:
Sprache: {"WssId":1,"TermGuid":"80f11bae-9a87-46c8-8025-f1f5f0488d52","Label":"1"}
Another obstacle, I will open a case.
With kind regards, Ronny
@RonLevy There reason why MM and Lookup columns are not part of the start event data is because it’s a technical limitation on the API side otherwise we would of certainly provided it. The retrieve was the only option available.
If you have any other specific isses around the SharePoint connectors or events please feel free to contact me directly at rick.demarco@nintex.com
Cheers, Ric
@rickdemarco Thanks for your quick response. I opened a ticket and had a Teams-Session yesterday. Nintex is trying to replicate the issue. It is not solved until now. It may has to do with our default language (site and term-store). Thanks for the offer. All the best, Ronny
@rickdemarco : Nintex has confirmed, that this is a bug and it has indeed to do with the language.
While it's not guaranteed, they expect the fix to be rolled out in couple of weeks.
Nintex Support Case #00530600
Cheers, Ronny
The fix has been released. Issue is solved. Wonderful, thanks Nintex