Simple question on Nintex Workflow 2010
I have a choice column that allows multiple values. Let's say those choices are "A" and "B".
If I read the value of the column in a workflow the possile values are-
However when I try to write values into the column, the single values work but setting the string "A, B" on the column doesn't select both the "A" and "B" values. I have tried separatig the values with a comma or a semicolon, with or without the space after the separator.
I remember a similar problems with people picker fields that required you to build this weirdly constructed setting string that looked like-
but that's not working either.
Any clues would be much appreciated, and PLEASE Nintex can we have some useful help WITH EXAMPLES on this type of issue in the online help and manuals, which currently manage to be full of words and not much information.
Have you tried separating the items with a semi-colon and a hash, so for instance, for your string, you would type A;#B
Hope this helps.
I would add that you must do these in order, so, for instance if you had a multi-select of A, B, C, D and you wanted to select A and D, D;#A would not work, but A;#D would.
Thanks for your message.
I believe your are talking about the "Build Dynamic String" action.
Firstly, you should query the columns for data, and then set these as multiple variables. Then use a Build Dynamic String action, and insert both variables seperated by a ; symbol. You can then update the value of a column with the variable that the Build Dynamic String action stores.
I hope this helps, but please let me know if you don't get the desired outcome.
Thanks for your comments, we are currently working on improving our documentation!
Yes you're correct, thank you.
It turns out that for multi-value choice columns Sharepoint wants a separator of ";#", and no value prefix, so the required setting string looks like-
Whereas for multi-select people picker fields it wants a separator of ";" with a value prefix of "-1;#" so the string looks like (for users called ALAN and BILL)-
I just couldn't remember the right incantation, and ended up getting it by trial and error.
Ideally of course a tool like Nintex would clean up these grungy bits of the Sharepoint API (for example give us the capability to assign a collection of plain string values to a column, and fix the interface behind the scenes), but until that happens, decent documentation with working examples woud save customers a lot of frustration.
With that off my chest, thanks to the users who replied. Help much appreciated ! ;-)
I continued to have problems with updating this multi-value choice field and after far too much time searching on Google, and finding mutiple variants all claims to be the correct syntax for setting these fields-
Either way, I found on my list, this week, it needs the last of these options to work. That is, to set the Choices "A" and "B" and"C" on a multi-value choice item you need to create the following string in a workflow variable and write it to the field value-
I have to say it is frankly ludicrous that (a) it's this hard to set a field value from a business workflow tool, and (b) that it's so poorly documented- as evidenced by the number of different "correct" andwers you can find in a Google search.
This is just a horrible API that needs to be fixed ASAP.
Nintex supports collection variables as a (sort of) array equivalent. If the workflow contains a set of values in a collection, the API should allow for writing the collection to a multi-value field type in a single operation, with all the bizarre complexities of the Sharepoint API hidden "under the covers".
Regards: Colin E
That was well answered and researched. You have correctly identified both the cause and the required formatting.
I'm now going to highlight how to workaround this. Here's the scenario I had:
However, as-is (and with a very recent version of Nintex Forms 2013) this is broken. It will allow the view of choices but not allow them to correctly display when editing. The view will show Choice A;Choice B;Choice C. This makes any multi-select value useless from a data management point of view.
The cause of this is that the formatting delimiter has not been correctly coded when the workflow variable is being invoked elsewhere (in this case, within the Create Item action). To work around this I built a series of Build Dynamic String actions with a Convert Value added for good measure. Here's my workaround until Nintex resolves this bug. There may be more elegant ways of doing this, but this worked first time and I need waste no more time:
Hopefully, this helps you. This approach could be used with mutli-select lookup fields too (I had to create a similar workaround for that in another more complex solution.
I've replicated this as a bug and submitted it to Nintex Support. This is a bug well over 2 years in existence. It has impacts on both multi-select choice and multi-select lookup. There's a clear miss in the coding to place the correct delimiters.
I've posted a workaround below in response to Colin's comment. But I agree with him. That this is still a bug is quite shocking. That we have to use clunky workflow actions, which are at a premium in most workflows of any complexity, is unfortunate.
Hi Carmien, thanks for the supportive comments :-)
Yes this is a truly nasty part of the Nintex / Sharepoint API. The fact that it's still there, with no attempt to fix it, and not even any documentation on how to work around the problems after this long does not say good things about Nintex's concern for the user experience.
Your post below (which is great BTW, thanks!) deals with a multi-value choice field within form logic.
The workflow that prompted my original question now has a relatively simple piece of business logic that has to identify a group of people (from a lookup list) that are "interested" in an approval process, then adds these to a couple of multi-value people picker fields in combination with some other IDs (like the submitter).
The result in Nintex is about 22 actions, involving loops and obscure string manipulations, that took me many hours to research, write, and debug. Should anyone come along after me and try to maintain or modify this code they are going to be left scratching their heads as to what the heck is going on here, when in reality all it does is about 4 simple things in business terms.
Because of our internal support arrangements for Sharepoint, I have to go though our internal IT department to log bugs on Nintex which adds another layer of explanation / analysis and delay. I don't always log every bug I should. Thanks for raising this one formally with Nintex Support, let's hope it finally gets some attention!