cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

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
Labels: (1)
Tags (1)
Reply
20 Replies
Automation Master
Automation Master

Re: Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

Hi Emily,

The Commit Pending Changes action is not available in O365.

Will it come or it is not necessary to have it in O365?

Regards,

Christophe

0 Kudos
Reply
Not applicable

Re: Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

Christophe,

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.

Cheers,

Andrew Beals

Reply
Automation Master
Automation Master

Re: Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

Hi

I can't see where this refers to?

"Create an item* (hybrid, see below)

Thanks

Cassy

0 Kudos
Reply
Not applicable

Re: Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

Cassy,

It is referring to the following:

  • 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
0 Kudos
Reply
Not applicable

Re: Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

Hi,

Is it Best Practice to add 'Commit Pending' action after every update item action? Or after an update action followed by a dependent read?

Thanks,

Geetha

Reply
Automation Master
Automation Master

Re: Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

Hi Geetha,

An update action followed by a dependent read.

Regards,

Christophe

Reply
jeff
Nintex Newbie

Re: Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

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?

Reply
kkj834
Nintex Newbie

Re: Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

Emily,

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.

Reply
allan48728
Nintex Newbie

Re: Designing your Workflow - Commit Pending Changes Action NW2010 & NW2013

Kim,

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.

0 Kudos
Reply