Process Monitor - In-Flight Work - From Previous to Newly Deployed Process Model

[PaulSuh]

We would like the ability to automate the hopping of in-flight work to the latest deployed version of the process model associated to the Business Area / Work Type. In seeing how each user task within a process model is associated to a back-end identifier (GUID), there would be a match for the same GUID on any newly deployed version of that process model. All active work on the previously deployed version of the process model to be transferred to the corresponding GUID on the latest deployed version of that model.

The Scenario:

1. A business request is received to update/fix an existing process model with a change to routing attributes (for example).
2. The process model is updated with changes to a particular gateway and deployed as the newest version to that BA/WT.

Given Statements:

1. All the work objects created prior to the deploying of the latest version remains on the previously deployed version.
2. The changes to the gateway on the newest version do not apply to any active work objects created on the previous version.
3. The only options at this time:
   1. inform the business that the latest changes to the process model will only apply to newly created work objects (date-specific) and that any in-flight work is to remain on the old process model.
   2. or the workflow administrator can manually hop (pause existing tasks on previously deployed process model version and resume on corresponding task on the latest deployed version)

Some Limitations:

There are some restrictions to manually hopping (pause/resuming via Monitor) work from old to new:

1. Once a work object is "paused" by a workflow admin:
   1. any pending timer expiry attributes are lost
   2. any suspension activate attributes are lost
   3. any user assignments are lost
2. For larger process models that have numerous user tasks, this task of manually hopping could be resource intensive (although it depends on the scenario as well). A monthly deployment cadence where process models could be deployed once a month is not as bad.
3. For process models that have nested sub-processes (could be various levels deep), the manual process of hopping work objects from tasks within a nested sub-process out to the same user task that is nested in a different version of the process model is also labor intensive and requires a methodical approach (where to pause on parent process prior to resuming, etc.).

The Ask:

Provide functionality within the Monitoring tool (or elsewhere) to automate the hopping of active work objects to the latest deployed version of the process model associated to the BA/WT.

1. Hop work from and to the same user task (as identified by the GUID) on the newest deployed process model version (if a GUID match is found).
2. For each work object that is hopped, as applicable:
   1. retain and reapply the timer expiry attributes
   2. retain and reapply the suspension activate attributes
   3. retain and reapply user assignments
3. For work objects on the old model that are in a user task that does not exist on the newly deployed model (no GUID match), these work objects are left as-is on the old model and is flagged to the workflow admin (via report or through the Monitor interface, identifying those that were not hopped, requiring manual review/action).
4. Provide the ability for workflow admin to select which processes to apply the hopper automation as there may be situations where hopper automation would not be required, for example, the newly deployed process model is a complete overhaul (user tasks deleted, etc.).

History:

Prior to our upgrade to Chorus (previously on AWD SP8.8), we had an in-house SQL script that would fulfill the above functionality. With each month's release, we would include the execution of the process model hopper within our deployment runbook. For the past decade, this script executed without flaw and workflow administrators did not have to manually hop work from previous to newly deployed process model versions with each deployment. The "Active" tab within the workflow admin suite would have the list of all process models deployed, and all work would be always on the latest deployed version (providing ease of work object maintenance as well).

However, with the move to Chorus, due to the changes to the back end database tables for work objects, our current scripts utilized with AWD is no longer compatible, and would require a re-write/mapping of GUID, process model version comparisons.

[Karen_Hunter]

Added to Enhancement Board for Process Monitor to (1) review current challenges with manual hopping Pause/Resume (2) improve management and migration of inflight work between model versions.

Open for additional comments and use cases. 

Votes matter. 

[Karen_Hunter]

Process Monitor Improvements are in scope for the 24.1 release.  Improved visibility to select, pause, and resume active work is in scope for this effort and includes analysis of retaining timer and/or assignment attributes when resuming in a new version of the model.  Please contact your Account Representative and mention this enhancement request if you are interested in providing early customer feedback on the proposed design and priority of new/changed functionality.