Modify in-flight workflows

  • 7 January 2016
  • 3 replies
  • 4 views
an_old_user
Badge +4

Hi,

 

We have a long running workflow which has many in-progress items.  We now need to modify the workflow structure to include an additional approval stage.  The only way I can see to update the running workflows is to stop them and restart them on the updated version.  However, items would then need to proceed through the early stages of the workflow which they have already passed. 

 

We could re-do the entire workflow as a state machine driven by list fields, which would allow us to force items into desired stages.  The drawback of this is that we loose the current comments, history and time stamps but we would gain a more manageable workflow.

 

A re-work is a fairly large task so before starting s there any known way to affect the current running workflows without stopping and restarting them?  Ideally stitching in another approval section at the end.

 

Thanks,

Barry.

3 replies

T
Userlevel 4
Badge +8

Barry - Its not possible to modify an inflight workflow, as you would like.  As a best practice, we suggest designing your process to avoid very long running workflows (e.g. more than a few weeks) for exactly this reason.  Instead, you could design the process as a group of small, modular workflows.

 

Using you state machine example, you could create different workflows with variables that have the "Show on Start Form" setting enabled.  This allows the variables to be populated as 'parameters' from another workflow.  In each state, you could use the Start Workflow action to call these other workflows, and pass data from your main workflow to the sub-workflows.  The Start Workflow action has a setting "Wait for the workflow to complete before continuing".  If your sub-workflows need to return data to the main workflow, they can write this data back to a SharePoint list (or database) and the main workflow can query that list/database using the sub-workflow's instance ID as a key.

 

Regarding comments/history... a drawback of this approach is that each workflow maintains its own history.  So I also suggest you create a master history log (either a custom list or SQL table) and have all of the workflows write history data to the shared log.  You can pass the instance ID of the main workflow as a parameter into each sub-workflow, and include the master instance ID as a key to relate all of the log records.

 

There are couple of other ways to accomplish modular workflows...

On a list workflow, you could using conditional start, when a specific field(s) match a certain value.  So a workflow could start, run and finish. The first workflow would change the value of this start field to the value needed for 2nd workflow to start. 

 

For site workflows, you can accomplish the same thing with a scheduled site workflow that runs every (day/week/month) and uses Query List action to find items that contain a specific status value.  The site workflow could then loop through all of those items and use the Start Workflow action for each one.

J
Badge +3

Hi Barry

I already seen a workflow with dynamic list of approvers.

Based on a state machine, approvers list is in a collection variable. it is possible to add new approver in the collection.

The state machine loops on this collection.

an_old_user
Badge +4

Thanks Tom. 

I had a feeling this would be the case but thought I would ask before we spend time reworking.  It's one of those solutions that with hindsight and experience you would do completely differently.

Cheers for confirming.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings