Commit Pending Changes In Workflow Design

[#1]

Question

What is the purpose of the Commit Pending Changes action within a workflow design?

Answer

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:

1. Set item permissions action (Nintex)
2. Update list item action (Microsoft SharePoint)
3. Set permissions action (Nintex)

These would actually execute in this order:

1. Set permissions action (Nintex)
2. Set permissions action (Nintex)
3. Update list item action (Microsoft SharePoint)

Why does this happen?

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.

Where does the Commit pending changes workflow come in?

The "Commit pending changes" action is another point where a workflow will execute all its batch operations. So, modifying the above example:

1. Set permissions action (Nintex)
2. Update list item action (Microsoft SharePoint)
3. Commit pending changes
4. Set permissions action (Nintex)

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

• Cancel check out
• Check out item
• Copy an item
• Create an item* (hybrid, see below)
• Delete an item
• Log in the History List
• Set field
• Update item
• Wait for item update

Actions that are processed in the Nintex batch

• Check-in item* (hybrid, see below)
• Set approval status
• Set item permissions
• Start workflow
• Stop a workflow
• Update XML

Hybrid actions

• Check-in item - if you choose Major check-in and minor versions are not allowed on the library, it's effectively a SharePoint action (and batch). For other options, it's batched by Nintex.
• Create an item - some special library types such as wiki pages, have been enhanced by Nintex as well as a number of other options. However it most commonly works as part of the SharePoint batch.  It acts as a Nintex action for the following SharePoint objects:
  • Discussions and Replies
  • DocumentSet (Nintex Workflow 2010)
  • WikiDocument
  • Folders