Nintex 2010 Workflow LazyApproval and Inline Functions – fn-Substring explained

I recently completed an update to a workflow to enable LazyApproval.  Seemed easy enough to do.  There’s just a checkbox in the Flexi-task.  I found that after I enabled the feature and a user approved the workflow task by replying to the email that the workflow was erroring out.  After the approval request was approved or declined, the workflow was updating some fields in the InfoPath form in the form library.  Four promoted fields in an InfoPath form library – three single line of text fields and a date field. Here is the error:

The workflow could not update the item, possibly because one or more columns for the item require a different type of information.

Outcome: Unknown

This was puzzling because if the user approved the task via the Task Form, all fields were updated successfully.  I started to think the issue was with the Date field but discovered it was actually with the Approvers Comments field.  When the user replies via email with a LazyApproval, the approvers comments are the entire email.  In my case, the contents of the email exceeded the limit of the Single Line of Text field.  Since this InfoPath field was promoted as a SharePoint field I wasn’t able update the field type to accommodate this by changing the column data type in the List Settings page.  This ended up breaking the InfoPath form when I tried to publish an update.  InfoPath indicated the field mapping had changed.  Enter the fn-Substring Inline Function.

So having just narrowed down the issue to the number of characters being passed back to the field in the InfoPath Form Library I thought the use of the Inline Function fn-Substring would take care of it.  Well, not quite.  I decided to declare a workflow variable (single line of text) and set it equal to the results of the inline function fn-Substring.  Here’s what that looked like…

fn-Substring({Common:LastApproverComments}, 0, 200)

first variable: Approvers Comments, second variable: 0 – start at the first character, third variable: 200 – include the first 200 characters.  I figured this would be enough.

The result of the initial fn-Substring was just the plain text from the email preceded by the function.  fn-Substring(body of email….  This didn’t seem right.  Why would it work with some plain text in a test workflow but not with my real data.  I missed one crucial piece of information from the documentation on how to use this function.  Let me share it with you.

If text used for a function argument contains function syntax (i.e. a brace or comma character) wrap the argument with {TextStart} and {TextEnd} to indicate a block of text that should not be parsed further.

For example, if a number variable that contains a decimal value is passed to the function, and the decimal separator for your region is a comma, the {TextStart} and {TextEnd} tokens will need to be used.

The stars started to align at this point.  I needed to wrap my first variable {Common:LastApproverComments} between the {TextStart} and {TextEnd} because the contents of the email included commas open and close ().  I assumed the curly braces around Common:LastApproversComments were able to interpret that the entirety of that variable was in fact the first variable – not true.

The completed Inline Function looks like this now.

fn-Substring({TextStart}{Common:LastApproverComments}{TextEnd}, 0, 200)

It’s great that Nintex provide documentation which made troubleshooting this much easier.  It would be great if there was a cheat sheet of all the nuances to Nintex like the tokens {TextStart} and {TextEnd}.  Maybe I’ll start one and post it someday.  Hopefully this helps someone else down the road.