The whole concept of a workflow being too large is defined by the current state of a user’s environment, the hardware available, the version of SharePoint patching installed and SQL Server performance. In most cases Nintex has investigated, when a timeout on publish or start has occurred there have also been other back-end related issues and general SharePoint timeout errors (in the application event log) as well as occasional network/SQL connectivity issues.
As mentioned earlier, this is a dynamic issue that varies between each SharePoint farm. Based on numerous investigations, this issue is due to time-outs caused by the amount of time it takes to compile the workflow. When a workflow is first run or published it is ‘compiled’ and a temporary copy is stored within SharePoint. This process can time-out, as can subsequent attempts to start the workflow.
In many cases, the only option is to redesign the workflow into smaller, connected sub-processes (refer to the second section below) . Dividing a workflow in such a way normally circumvents this issue as each workflow will compile and run in a smaller amount of time and consume fewer resources for a shorter amount of time.
However, that can be a time-consuming process, so before going to the effort, you can try increasing some of the SharePoint time-outs that relate to workflow processes.
Please note: User Defined Actions (UDAs) may appear to reduce the amount of work being done when viewed on-screen, but that is not the case. At run-time, all the actions used in the UDA are compiled as part of the workflow.
Why you should split into sub-workflows?
If a workflow process has become overly difficult to view, contains multiple approval stages or is running into issues/errors when publishing or initiating (especially time-outs), then the overall design should be split into sub-workflows that are started by a preceding workflow in the chain.
We have listed the advantages and disadvantage of splitting up a large workflow.
Advantages of splitting a workflow into separate sub processes
1. Avoiding the repetition of a long, complex process
In a complex workflow process, an error may occur for an unexpected reason and in these cases the workflow will need to be restarted from the beginning. This is standard SharePoint behavior and is how declarative workflows operate; Nintex cannot alter this behavior.
This can potentially lead to a workflow that was nearing completion but failed during its last set of actions, which in turns means the workflow must be restarted from the very beginning and any approval type actions must be repeated.
If a workflow has been split up into sub workflows, the entire process will not need to be started from the beginning. The sub-workflow that failed can simply be started manually on the item and the appropriate start data also manually entered. This not only saves time but ensures if an unexpected issue does occur it will have the smallest impact possible.
2. Ease of troubleshooting
Smaller workflows also have the advantage of being much easier to diagnose and troubleshoot. If an error occurs in a workflow with hundreds of actions, the first step may be to reproduce the error. This can be very difficult and often is a process of running the workflow manually and editing it to determine bit by bit which actions are causing the issue. Once the issue has been determined the cause can then be investigated.
A workflow with fewer actions is much easier to manage and to determine which section or action is causing an issue. Also, in terms of error replication, a workflow with fewer actions is advantageous since there are simply fewer factors at play which could stop the real problem from being discovered.
3. Eliminating time-outs
Each time a workflow is run for the first time, a temporary version is created and compiled on the SharePoint server. When running a workflow that is overly large this process can take some time and create extra load on the server. Smaller workflows with fewer actions will compile faster and increase performance.
1. Understanding your process at a glance
Splitting up a workflow means you will no longer be able to see your entire process in the one place.
For information on approaches to splitting a workflow, please see Approach to splitting a Nintex Workflow