Hi @MegaJerk,
The limits mentioned are related to the SharePoint column limits.
So, if you tried to use your variable to populate a Single Lines of text column, only the first 255 characters would show.
Certainly. But for the actual variables themselves in the workflow editor, there is no actual difference between Single Line Text and a Multiple Lines of Text variable? Is that correct?
I have never tested it.
What happens if you try to put that large single line of text variable into a multi-line of text column in SharePoint? Does it work?
I think the limitations kick in when you go to use the variable like logging it or in an email, then the single line of text is truncated so as not to cause an error.
in testing it seems to me that the SLT Workflow Variable can hold *any* string and basically works like a MLT variable for all intents and purposes.
Trying to push more than 255 characters into a SharePoint Single Line of Text Column will result in an error of “The workflow could not update the item, possibly because one or more columns for the item require a different type of information.” every time. It does not truncate the string down to 255 characters.
Pushing an SLT Workflow Variable to a Multiple Lines of Text SharePoint Column works exactly like an MLT Workflow Variable pushed into a Multiple Lines of Text SharePoint Column.
To clarify:
The main reason I had been asking this question is that I had assumed there was some fundamental difference (at least on the backend) with these two workflow variable types. In some programming languages and databases, they might provide you with types that are narrowed down in terms of how many bits a particular variable / field might hold, and I was working under the assumption that this sort of behavior was present in these Workflow Variables. That if I used SLT over MLT, there might be some benefit, performance gain, or slight optimization based on the amount of memory allocated to said variable - However that seems to not be the case. They are different in name only.
Ultimately the purpose was to find out if this was how it’s supposed to be, or if this was an obscure error in Nintex Workflow.
If it’s in error, then it’s something you can elevate, and I should stick to using one variable type for one specific set of values and the other type for a different set of values.
If it’s always been this way, then I know that I can stop specifying which variable type I should be using, because it makes zero difference and is unlikely to change.
Thanks for your help with this.