I've had a couple of customers report the same issue to OT support and the response was that the issue is due to 3rd party code when in reality the issue is due to bad code in CS core and other modules. Many modules that are using forms in workflows have code similar to the following snippet:
for i in WORK_PACKAGES
if (i.TYPE == 1 && i.SubType == 4) // Form?
if ( Type(i.USERDATA) == StringType )
udata = Str.StringToValue(i.USERDATA)
else
udata = i.USERDATA[1]
end
This is wrong on multiple fronts. First, the code should not be using hard coded integers to compare the Type and SubType of the data type. That is a minor issue. The big problem is in the next section where it does a Str.StringToValue. This is wrong and evil. It assumes that it knows the structure of the form data in the workflow. That is a really bad assumption. When painting a workflow map, or initiating a workflow, the form data is stored in multiple formats depending upon how it is accessed and updated. This is necessary because the data may need to be thrown away if the map is not saved or the workflow not initiated. Because of this, the Form data type has a method that must be called when accessing the Form data. The above snippet should look like this:
Object formObj = $WFMain.WFPackageSubsystem.GetItemByName( 'Form' )
for i in WORK_PACKAGES
if ( { i.TYPE, i.SubType } == { formObj.fType, formObj.fSubType } ) // Form?
udata = formObj.ReadyForModification( prgCtx, i.UserData )
You must call the ReadyForModification method when accessing forms in a workflow. That method knows how to adjust the form data to return the list of forms in the correct format.
I see the same wrong code all over the place, core workflow, XML Workflow Extensions, WebReports etc. This message is to inform people so they can write their own code correctly. Hopefully, OT development will read this as well 
