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.
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
For me another disadvantage is that workflow variables declared in the first workflow are not automatically available in the other workflows. There is processes to pass variables (send and retrieve actions) but it makes the workflows bigger and more complex than if you had just a single workflow.
I like the idea of dividing up a workflow to sub-workflows. 1 of the key disadvantages I've encountered doing this is that sub-workflows do not start immediately. This means if you have a lot of sub-workflows users may experience more delays than they would if it was all in one workflow.
This is my standard, it is much better to split workflows it's like delegating work to other people. What I also like to use is a way of integrating these workflows, I use the wait for field to be yes for the other workflow to take over the process and it has been working so well for me.
Anything more complex than a simple approval workflow I split
I always have 1 main workflow which all it does is start and manage all the other sub-workflows, by reading and writing status and wait untils. That way I can restart any workflow including the main one and they will just skip to where the process last stopped.
Workflows fail all the time, most of the time for unknown reasons (damn gremlins), but if workflows have build-in ability to skip previously action steps I'm all good.
I never had a user complain that they had to wait 20 seconds rather than 1 for a workflow to start, I use lot of waits to avoid processing issues any ways to time to me isn't an issue.
Isn't it also a disadvantage of subworkflows, that you have to wait for the timerjob to pick up the individual parts, introducting an up to five minutes wait between each sub workflow being completed?
That's nice. It is something I wanted to do but did in a different way; I used main workflow and have sub workflow but without reading and writing statuses. Your way seems cleaner and nicer for both the user and the developer.