Some workflow updates and changes are added to a batch and processed at a later trigger point, typically when the workflow reaches a delay, a task or the end of the workflow. This is what we consider to be a “commit point”.
Consequently, the workflow may be attempting to process a large amount of operations in a single batch or execution. For example, the "Update list item" action doesn’t actually update an item immediately, it waits until the workflow commits. As mentioned, the workflow commits at a delay/pause action, a task action or the end of the workflow. So when the “Update list item” action runs, it just registers that it needs to update the item - the item actually updates on commit.
The first step to alleviate these types of issues/errors is to either:
- Insert a “Commit pending changes” action after running each update action
- If that doesn’t work (it is known not to sometimes) insert a “Pause” action after running each “Update” action
- Insert a “Pause” action after a small set of update-type actions
This will help separate the updates into smaller, much more manageable processes. These actions will not actually be committed as they execute; instead they will only finalize the changes when a commit point is reached.
Important Note: If a “Commit pending changes” action does not always work, substitute it for a “Pause” action instead. The “Set item permissions” action is one that is known to take longer than others to complete what it’s doing, hence a Pause should always work.
Overall, commits and pauses will ensure the updates are committed as the actions are run and reduce the stress on the workflow processing engine.
For more information Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013