Hi Jeffo,

Can you let me know what you need this behaviour for? In the 2013 Workflow engine that Nintex uses in SharePoint O365, there are a few states that workflows can end up in, Completed (finished normally), Suspended (a problem occured, but resumable), Terminated (manually stopped or not recoverable, not resumable). 

Which of the states are you looking for? Also what is the purpose of this (catching errors, or ensuring that there are workflows constantly running). 

In Office 365 the architecture of SharePoint workflow is quite different to the 2010 Workflow engine used in Nintex for the On-Prem SharePoint, just want to check that what you are trying to do is necessary.

Thanks,

Callum

We have two scenarios that we are using this functionality for:

• We have lists where we have seen scenarios in SP2010 were workflows would fail due to many different issues (users update data in rapid succession, an update would fail for no real reason, etc).  Many of our sites are business critical and would would scan the lists every day to see if there were failed workflows.  If there were we would rerun them automatically and 99% of the time they would be successful and the business would never know there were issues.
• We have a process on a group of sites that has bidirectional data transfer to an external vendor's SharePoint instance.  In this case we were trapping instances where there were unexpected failures due to connection issues or network (anything that was outside the scope of what we could trap via the SP webservices.

We were planning to build a similar solution for our Nintex workflows in O365 so that we could easily find items that were in a suspended state and notify the developers and/or rerun the workflow.  My developer noticed some APIs that were from SharePoint but before performing a POC to determine the proper parameters I thought I would post my question here.

The workflow that we are looking to build would be a generic workflow where we could pass in the site, list, workflow, and date range.  It would then troll through the items in the list and find suspended items, terminate them, log that the item was terminated, and then rerun the workflow.