This short article describes how you can split a Nintex Workflow to improve workflow performance.
Given that there could be thousands of combinations and permutations of workflow designs, it’s very difficult to describe one way to split one complex workflow into separate parts. Therefore, a general approach is offered by way of a relatively simple example.
For example, this simple workflow has two approval stages:
There can be any extra amount of actions, however the essential part is that the workflow has two stages, the initial approval and then the second level approval. If this workflow was having issues, the logical step would be to split up the workflow into two workflows; ‘stage 1 approval’ and ‘stage 2 approval’.
To do this, you first need to determine where the second approval process begins. This is where it is best to divide the workflow. In this simple scenario, the workflow can be divided into two workflows, each containing an approval action.
In other cases it might not be as simple; a general rule is that if you are starting a new set of logic actions, approval actions or are able to group a set of actions then this can become a separate workflow.
Following on with this example, the initial workflow can be edited and all the irrelevant actions removed.
The workflow title can be changed (> workflow settings) and the workflow will be published under a new name.
The original workflow can then be edited and the second approval can be replaced with a “Start workflow” action that will start the second workflow in the overall process. The final step is to configure this action to start the “Simple Approval Stage2” workflow.
A particularly powerful method of starting and scheduling workflows is with a web service method. Using this method will also allow you to pass variables between workflows using “Start data”. For more details on how to pass variables between workflows, as well as how to configure the “Call web service” action, please refer to Start a Workflow using a Web Service.
Splitting a workflow seems useful and reasonable but what would be the approach in this case to the Status column, where you have the text of the status and a link to it. This becomes a requirement expecially in cases when the workflow doesn't start or fails and having multiple status colums (for all the sub-workflows) would not be too useful.