Avoid Looping Throttles With Nintex for Office 365 Workflows
How to best avoid throttle events due to looping within Nintex Workflow for Office 365.
Best practices to avoid throttling
Reduce the number of operations per request:
When multiple workflows are running at the same time, if workflows are waiting for a wake-up event, make sure that this event will only affect the workflow running on the current item.
Example: When using the Wait for Event in List Item action; if any item on the list is interacted with, workflows waiting on this action will wake up, resulting in a high number of calls being made to the SharePoint environment.
The preferred alternative would be using an action like Wait for Field Change in Current Item. This action will only wake up the workflow instance if the item it is running on is interacted with instead of any item on the list.
Breaking workflow definition into smaller parts, and calling these child workflows through the Start Workflow action. This will help reduce the number of requests per workflow instance.
Reduce the frequency of calls:
If loops are being used within workflow designs, add a try/catch that will pause the workflow after a specified number of loops. This can be accomplished by adding a Pause action inside of a conditional Run If action within the loop that will pause the workflow every X number of loops (for example after every 20 iterations of the loop, the workflow will pause for 1 minute).
If a workflow contains any loop logic (loop/for-each/state machines) consider leaving out actions such as Log to History List as they can quickly fill a workflow history list if left unchecked, and result in a large number of calls being made to the SharePoint environment.
Split large workflows with many actions into smaller sub-processes with fewer actions:
While the final design of how to break down individual business processes will be up to your design team, and the various business owners involved; most workflows have logical breakpoints within the design where a split could be made. Here are some common breakpoints where a workflow could be potentially broken down:
Within State Machine – Each branch can function as an independent workflow
Within Parallel Blocks – Similar to State Machines, each branch of the Parallel Block can sometimes be broken into its own process
After conditional checks – Based on the outcome of the condition the parent workflow may start one child workflow vs. another