Symptoms

In-process workflows causing version mismatch with newly deployed versions of forms / child workflows.
 

Diagnoses

We're having issues with our K2 workflows in Production. We recently deployed a new version of several workflows and Smartforms. The issue occurs when an in-flight workflow, one that started before we updated the workflows, runs into a data mismatch when trying to trigger an IPC event, or a Smartform client event. This old version of the workflow is trying to access the newest version of the Smartform and IPC events are referencing a new version of the child workflow.

In both cases, I'm dealing with cases where I added or removed/renamed a datafield and since that datafield doesn't exist in the old version of the workflow, but the new version of the form is trying to write to it, it causes an error. Similarly when the old version of the workflow tries to kick off a new version of an IPC event where I changed the name of a datafield to align it with other similar workflows, the old version of the workflow can't find the datafield with the name it was expecting since it's written to match the old version of the child workflow.

On Smartforms Client events, there is a checkbox for "Bind Form Version to Process Version (on Deploy)" which according to your documentation is Disabled Functionality.

The workflows in question are triggered daily and run for weeks, so there is never a point that we can update our workflows without affecting those items currently in process. Is there a way to lock versions of forms / workflows together somehow? Is this something that is being worked on?
 

Resolution

The "Bind Form Version to Process Version (on Deploy)"/"Use Default Version" functionality that is currently available in the Smartforms Client event is currently not functional and is still being reviewed for the future. A TFS item have been logged to removehide this UI in a future release and the online documentation will be updated accordingly. As this functionality currently does not exist, the process only knows about the current/active version of the form as such, please plan the process and form design/update accordingly.

In an IPC process situation, as the running parent process only know about the process version in which it was running on it does not know about the changes in the child IPC process definition until the execution of that IPC event to call the start of that child process (the IPC event will execute against the Child IPC process that is currently set as default, as it is currently not possible to specify which version of the child IPC process the event should call with). As such, for running process instances and IPC process compatibility please also take the process design/support/non-supported scenarios into consideration as detailed in:

http://help.k2.com/onlinehelp/k2blackpearl/devref/current/default.htm_important_notes.html

Unsupported Changes:
The following process definition changes are NOT supported when migrating between process versions (this is essentially what the IPC event is also doing, if the child process has been updated, this event will still call with all of the parameterfields from the parent process that it was configured with):

• Removal of the following from the process definition:

Activities
Lines
Events
Data fields
Xml fields
Escalations
Actions
• Renaming the following within the process definition:

Activities
Lines
Events
Data fields
Xml fields
Escalations
Actions
• Changes to any of the following:

Environment Fields (String Tables)
retroactive Activity Slot count
retroactive Activity Plan Option’s
retroactive process escalations