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
As the O365 product works within the newer Workflow Manager this article will not apply to our O365 product. This article was written for the 2010 workflow engine (legacy workflow engine in 2013) and not for workflow manager.
It is referring to the following:
Is it Best Practice to add 'Commit Pending' action after every update item action? Or after an update action followed by a dependent read?
How the batches work and esp. differences between Nintex and SharePoint batches is a little unclear. I am very interested in the "beware of timing issues" because I believe I'm suffering from an intermittent problem where I'm both changing list item permissions and updating the list item, and very rarely the list item ends up being in a state where it can be read but nothing else can be done with it (can't be updated, deleted, re-permissioned, etc.). So the advice here is to replace the "Commit Pending Changes" action with a "Pause" action? Does it matter how long the pause action is?
I just got back from the Nintex conference and am making lots of changes to my workflows. One of the places I have added pauses is at the beginning of the workflow so all of the form data settles before the workflow starts. Would this action also solve that issue? I was having the form only complete the item partially without the pause. This caused errors because the data wasn't there when the workflow needed it.
The impression that I'm getting is that the pause action solves it only in some cases. You might try the "Wait until item update" action if there's a specific field you're waiting on. You might try adding both a pause and "Commit pending changes" actions to see which resolve it. I was just told by Nintex Support that adding "Commit pending changes" after setting any variable is the recommended best practice. If the workflow isn't working then I recommend adding "Commit pending changes" after any of the above listed actions (e.g. Set variable, Set field value, Update item), and then if that resolves it, work backwards from there to remove unnecessary "Commit pending changes" actions in the workflow.