Skip to main content

I have list workflows that are scheduled to run when a process status has been completed or placed in pending status. I even built site workflows to follow behind every 1 hour and cleanup any that might have been missed. My workflows run and move items to the completed or pending lists like they should but then they are supposed to clear out fields to have available for next review. It is not re-setting the fields but I noticed when I do a manual run, everything moves and updates fine. So I know my workflow works good, but it's getting held up at times. I have a commit changes action in the workflow and some others have suggested pauses in the workflow. Does anyone have a good solution to this issue?

Thanks!

Cassy Freeman

Hello Josh Shutts​ -

You will want to use Commit Pending Changes action before you query the item to ensure you are getting any updates that have occurred. Check out Video: Batched Actions and Committing Changes in Nintex Workflow for a more elegant explanation by Mike Fitzmaurice​.

One aspect to think about is if users are initiating the workflows, do they have permissions to update the corresponding lists? If you run it and never encounter the issue, it may be permissions.

Hope this helps!


I know you've tagged me on this one but I don't have anything valuable to add that Jesse McHargue​ hasn't already said happy.png


Thank you Jesse! I had been placing the commit pending changes to the very end of my workflow. From the video, it sounds like you have to be careful where you place these because the workflow doesn't necessarily  run in the order it's built. I will let you know my outcome.

And thanks Cassy Freeman​ for responding. Sorry if I tag you too much. :-)


Hey Jesse and Cassy Freeman

If I have a action set workflow (no query) and I am using the commit pending changes action, does it even do anything? Do I need to have that at the beginning to or just somewhere in the control box? Thanks!


Hello Josh Shutts​ -

If you are making updates/changes to items and then calling a Commit Changes action, the forces the workflow to batch the updates. Keep in mind though, that if you are not reading from the updated item, it is a bit overkill. You only need a commit before a dependent read (reading something that is dependent on a previous update).

I try to stick to the same logic for each of my workflows; query lists/items, perform required action(s), update required lists/items.

I try not to read and update the same field multiple times within a workflow to avoid these issues, but sometimes it is required. I like to use State Machines (probably too much...) as they help break the actions into more manageable sections. This allows me to visually see what actions will be batched and executed once the state machine is directed to move to another state.

Hope this helps! If you need anything else, or a stumped, please let us know!

Always happy to help happy.png


Good Morning Jesse

Thanks for this. It is very helpful. It appears the commit pending changes worked great. My finally obstacle is that my due date isn't updating like it should. Cassy Freeman​ has been awesome in helping me with this this piece but I may have confused myself with how to store the data. The below workflow has an initial query that finds loans past due and logs into the vIDPastDueItem id in the foreach action.  I then have a second query in the workflow is intended to query loans that matched that vIDPastDueItem then update the due date using a calculated variable date. Question1...do I need a pending commit change before this second query too? Question 2...do I even have this written correctly? Btw...it is scheduled to run every night at 11:30pm.

186252_pastedImage_3.png

186243_pastedImage_0.png

186251_pastedImage_2.png


Hello Josh Shutts​ -

186257_pastedImage_3.pngFrom what I can gather, you are simply querying a list to get IDs (for items that are "Past Due") and storing them in a Collection variable.

Using a for each loop action, you are looping through the collection of IDs and then querying the list again for more due date. Do a calculation to find the updated due date, and then update the list item. Correct? (See my example to the left)

Your questions:

1. You do not need a commit changes unless you are querying the item/list again later in the workflow for something else. You can always test the results at that point by adding in a Log History action or emailing yourself the data to verify.

2. It looks good to me and this is similar to how I would approach the problem. I did notice that you are using a "Update Multiple Items" action, rather than a single update. Is there a reason that you are using that? I would think that updating the item you are working with in the loop currently should be updated in consecutive order would be better.

Hope this helps!


Hi Jesse

Very close. I am actually using the second query to find the due dates that I collected from the first query. I am using the update multiple items because I have over ten fields I updating to blank and then also updating the due date to next day. I just wasn't sure if I did the second query correctly by querying for the collection.

186260_pastedImage_0.png


Question for you -

Does your second query look at the list where you just created the item (in the previous action)?

186258_pastedImage_0.png


No, the second query doesn't go back to the "created" list. It looks back at the original one again.


You should be good to go then, no need for a Commit Pending Changes.

Post more questions to the community if you have any other issues and I'm sure someone will help out!


Reply