Skip to main content

What are design considerations to think about when using the “Pause For” action?

Context: I have a single workflow that can have 10-15 instances running at a given time. This workflow has a pause of 60 minutes within a loop to check a list every hour. There is concern that this may be too frequent of a check against the list and that a longer delay should be used.

 

I am a Site Collection Admin - not a Farm admin - so I have no idea what server resources are used at any given moment to support the workflows running at the same time.

 

Do Nintex workflows get preserved on the server in RAM or on Disk?

 

How would I know as an SCA the impact I have on server operations with a workflow that I create?

 

What do I need to know about the “Pause For” action so I use it efficiently and with the least amount of resource use?

Joseph, I can’t answer all of your questions about PAUSE, but I can tell you that we’re found it difficult to maintain long-running workflows in either a Task state or a Pause state. 

The alternative is to use scheduled workflows instead of looping and pauses. Scheduled workflows can achieve the same interval processing down to the hour. There doesn’t seem to be an option for smaller increments of time in the WF scheduler. 

Hope this helps somewhat.

I think gman is correct in the suggestion about using scheduled workflows instead, but specifically about how workflow state is kept, I believe that it’s written to the Nintex DB.

 

I actually tested this out recently when upgrading from SharePoint 2016 to 2019. Disconnecting the Nintex DBs, copying them, and then connecting up to the new install, we were able to keep all running workflows going just fine (note: we also copied the content databases for SP as well, so the relationships could remain the same).

 

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings