Some actions in SharePoint workflow don’t execute their workload immediately - instead they batch their job. For example, the "Update list item" action doesn’t actually update an item immediately, it waits until the workflow commits. The workflow commits at a delay 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 SharePoint workflow engine doesn’t necessarily commit batched operations in the order they are displayed on the designer. For example, if you had the following actions in this order:
These would actually execute in this order:
Firstly, because there are actually two batches, the Microsoft batch and the Nintex batch (any other third party has their own batch). This is because third parties cannot add operations to the Microsoft batch. Secondly, all items in a single batch are executed before actions in another batch. The batch that is executed first depends on the first activity: If the Microsoft SharePoint action was encountered first, then all the Microsoft actions would run before the Nintex actions.
The "Commit pending changes" action is another point where a workflow will execute all its batch operations. So, modifying the above example:
In this case everything will run in order. The Nintex batch will run first because the Nintex action is first encountered, but in this scenario there is only one action in this batch. The "Update item" action will run. Then the workflow will commit, and the final "Set item permissions" action is in a new batch.
**Be aware of timing issues: That one batch EXECUTES before another, does not mean that the first batch to execute will FINISH its processing before the second batch executes and finishes. This can cause timing issues. As a general rule, if you try a Commit action and it works intermittently, replace the Commit action with a "Pause" action. This will eliminate any risk of timing issues between different batches. A common scenario when this occurs is using a "Set item permissions" action followed by a Commit then an "Update list" action. The "Set item permissions" action takes longer than other actions to finish its task and can end up taking effect AFTER the "Update list" action, causing problems. Replacing the Commit action with a Delay in this scenario is known to fix the timing issue.
Actions that are processed in the SharePoint batch
Actions that are processed in the Nintex batch