Planning ahead
When designing a fairly complex workflow/business process it is common for a workflow to become overly complex (in programming this is often referred to as a god object). This can lead to issues down the road such as:
- Troubleshooting/Debugging difficulties.
- Difficulty maintaining code/loss of flexibility.
- Performance degradation on publishing (or even timing out altogether).
- Performance degradation on initialization (this can affect the entire farm).
- Inability to export or edit the workflow after publishing.
- Workflow template corruption (limited to the workflow itself).
Workflows should be broken up into more manageable bits whenever possible (in computer science this is called Separation of Concerns‌). An example of this would be a workflow that has multiple stages of approval and logic inside of each approval branch:
There are several approaches that can be taken to mitigate these issues:
User Defined Actions (UDAs)
User defined actions are a great tool for encapsulating a piece of workflow code/logic. Additionally, user defined actions provide a way to design your workflows to interfaces which helps to decouple‌ your logic in a way that makes it easily maintainable and reusable.
Sub Routines (Child Workflows)
Utilizing the Start Workflow action you can call subroutines (child workflows) to perform some work and report back as soon as they complete. Utilizing multiple workflows instead of one enables you to keep your workflow size down as well as avoiding performance issues that come with large workflows.
In the above example, the following could be done to break the workflow into smaller bits that could be independently updated without affecting the rest of the workflow:
- The flexi task in section A could be placed in a separate workflow. The workflow could be called by the Start Workflow action. Inside of the action it can be configured to wait for the subroutine (child workflow) to complete or not.
- The workflow code/logic in section B could be placed in a UDA (User Defined Action) or another subroutine (child workflow).
Performance
When designing a workflow, keep in mind the following: Smaller is better (and more efficient). While there is no hard limit on how large a workflow can be (the limit is dependent on your SharePoint farm configuration and overall performance), we generally start to see issues when a workflow is around 500Kb or 100 actions (these typically correlate with each other well).
To determine how large your workflow is, export the workflow from the Nintex Workflow Designer to an ‘*.nwf’ file. The size (not size on disk) of this file is the value we are looking for.
Design Considerations
- Nintex Forms can add a significant amount of size to a workflow file. If you have a workflow utilizing Nintex Forms and the workflow is no where near 100 actions however, it is over 500Kb, it is safe to assume the file size is caused by the form and not the workflow itself.
- If a workflow utilizes UDA’s, each UDA should be exported and added to the overall file size as they are combined at runtime.
More Information
- User Defined Actions - Nintex Workflow
- Approach to splitting a Nintex Workflow
- Software boundaries and limits for SharePoint 2013
- How to quickly identify large workflows in SharePoint
- Defensive Workflow Design Part 1 - Workflow History Lists‌
- Defensive Workflow Design Part 2 - SharePoint Topology‌
- Defensive Workflow Design Part 4 - Slow Down and Speed Up