as we all know a list workflow can only have one running instance per item. If you try to start the workflow twice via other workflows using the "Start Workflow" action you will receive this error message:
"A workflow is currently running. Please wait for it to complete."
However, the workflow containing the "Start Workflow" action will be suspended.
Is there any way to avoid the workflow being suspended in this case?
I thought about capturing the workflow successfull bool hoping that it will activate some kind of error handling like in OnPrem so i can check the bool afterrwards and simply put a loop around my "Start workflow" action. But it seems this return value is useless as it only return true on a successfull satrt but nothing if the workflow couldnt be started.
I also thought about not using the "Start Workflow" action but a web service call. However I haven't found a way to start a nintex list workflow in O365 by using a web service call.
Any input is highly appreciated.
Update: I've worked out a way to start the workflow via REST call. Unfortunately it doesn't help me. The first REST call will start the workflow as expected (response: OK). The second call will also start the workflow and terminate it with the message that the workflow is already running BUT the webservice response is still "OK". So there is seems to be no way for me to evaluate the web service response and see if the workflow could really be started.
What are you trying to accomplish by having multiple instances of the workflow running at once? If you just need to have the workflow restart when the item changes you can have a workflow that runs that will terminate the running instance and start a new instance but if you want more than one instance running at once I don't think it's possible.
thanks for your reply. I do not want to have multiple instances of the workflow running on the same item. Instead I want to make sure that my "Start Workflow" action waits until the running workflow is finished before starting it again. Otherwise the workflow containing the "Start Workflow" action will be suspended.
Why not have a status column in the list that reads a value such as "In Progress" and then do a loop on this... loop while true----else start the workflow once it is cleared to start. You could come up with a ton of logic surrounding this idea. Essentially just poll the list until it is finished before starting the next workflow "iteration".
this is what I already tried. Unfortunately it doesnt work. When I query my status column it may tell me that the status is "completed" but when the "Start workflow" action is executed right away it gives me the usual error.
Have you tried the Nintex web service GetWorkflowHistoryForListItem? You can pass in the Item Id, List Name, "InProgress" for the state filter, and the workflow name. If it doesn't return any In Progress workflows then you can start it again.
I'm not 100% sure, best thing is just to test it. I used that web service in a different way, I was looking for In Progress workflows and terminating them so I could start a new instance. My guess is it should. With the Status column, if you are setting it in the workflow right before it ends it might take the workflow a little while to finish up and so the new workflow might start before its complete. With the web service you should only get ones that are already completed.
Another way to pull this off would be use to use a second workflow as a sort of Master to control the process. In this master workflow you could loop over an item and query its status column to see if the workflow is ready to be started, and if so do so. In other words, your non-master workflow would set its status when it first starts to something like "In Progress" and at the very end it would set its status to "Ready", which would signal to the Master that it is a candidate to be started again. I've written many highly complex workflows and have used similar techniques in the past so I know this is possible. You just need to figure out the business logic that is needed to control the functionality of the Master (like when it should run and when it should stop running against a given item) this too can be controlled by another status of sorts.
thanks for your response. I may give this a try in case I will find any time in this project
In the meantime I implemented some completely different workaround to avoid the problem at all. However, this is not a technical but an organizational change, therefore it's not worth to be posted here.