I need to run a Terminate Workflow activity but sometimes the workflow may have already been terminated or finished. When it runs on an item that is not actively running this workflow, then it errors because there is no active instance.
Is it possible to query the active instances so that I can set up criterea for running the terminate workflows activity? Or a setting I missed in this activity that will prevent the error?
The intent of that action wasn't to run as a cleanup action outside of a self-contained workflow. Meaning, you would include the terminate instances within a workflow so that it would know the container of the workflow ID and instances to then terminate.
There isn't an OOTB way to do this with Nintex as of yet.
For withdrawals of the request, that's easy and I just end it by calling a workflow from the form on the item itelf that terminates it and I'm done.
The reason I can't terminate within the workflow itself for this particular reason is that I have to have the ability to restart the approval approval process at any point within the workflow. In the terminating and restarting workflow I clear some, all, or none of the existing signatures based on user input.
It may or may not be currently running because it could have been rejected by an approver and thus ended or previously withdrawn and thus terminated in either case. But in the cases where it is still currently running, I need to terminate the workflow so I can restart it from the beginning. In the main workflow I built conditions to collect the signature if the signature is missing else it moves to the next approver.
So maybe there is a way to attack this situation differently? at the very least I could say that if it had been withdrawn or rejected (both recorded in the table) then don't terminate and only restart.
@eharris04 I just had a thought... What about at the REST service? Is there something I can get from REST about the active instances? I don't know much about making calls though, I can get attachments and thats all I've tried thus far.
@jacquenv for this... instead of thinking of the workflow as a whole process that needs to be terminated, why not leverage the task that places an intermittent pause in the workflow until the task is complete. You could assign the task to yourself or to an approver. This mixed with using a state machine could allow you to move back and forth through workflow logic in a step approach if you needed something with more control other than trying to restart the actual workflow.
Doing this, the workflow would start once, and be in a running state until completed. I mention these steps assuming you have access to all these actions.
@eharris04 Yes I have access to all those. The only thing I don't is Azure and related tasks.
The restart tho is going to be not often and with the insaine amount of workflows we are going to have running when we go live, having another workflow waiting is going to burden the system.
Also the workflow may have already been rejected in most cases and thus ended and it also may still be running (like it got to Fiscal Approval and Fiscal says "you chose the worng budget and thus the wrong approvers" and they need to re-collect signatures prior to that stage). So I am not sure adding a state is going to be worthwhile. It's already 167 activities in this workflow, that's A LOT and not sure I want to add even more. If it's ended, it's ended and if it's still running I need to be able to terminate since I can't run multiple of the same workflow..