What is wrong on TerminateWorkflowByNameForListItem if multiple emails are sent?

  • 15 March 2017
  • 7 replies
  • 3 views

Badge +5

Hi everybody,

I'm, experience an annoying issue with terminating workflow instances by WebService.

This is my scenario: it should be possible for users to push a button in my Nintex Form to cancel all running instances of two workflows for the current list item.
I realized this with a site workflow that get's started by webservice-call via click on the button. This works well, both running workflow instances are terminated on the list item. I realized it with this:

200883_pastedImage_1.png

The webservice-actions are configured like this (example for the bottom-action):

200884_pastedImage_2.png

So for the following example, if the site workflow to terminate the running listitem-workflows is executed again, now for every workflow ever executed (not only the currently running) on this listitem, the notification-email is sent again, 9 times (4 on Request, 5 on Internal approval)!

200885_pastedImage_3.png

Is this a bug by Nintex, a creepy design-feature or a misconfiguration on my action? And what can I do to ensure only notifications for the two running workflows will be sent? Or better no notifications for that special workflows?

Greetings from Nuremberg

Ricky


7 replies

Userlevel 5
Badge +14

I would say it's a bug.

I can reproduce the same behaviour. I even noticed cancel is invoked for correctly completed workflows.

Badge +5

Do you know, if this is already on a buglist and if it's in sight when this is gonna be fixed, Frank Field‌?

Userlevel 5
Badge +8

Hi Ricky Mattischeck, Marian Hatala‌, this will be expected behavior when using this method.  If the 'terminatePreviousInstances' option is set to true, it will terminate any previous workflow instances associated with this item regardless of the state.  If you do not desire to have all of the workflows under that workflow name for this list item to be cancelled, you will need to set that option to false. 

Userlevel 5
Badge +14

thanks for explanation Dan Burke

however, to be honest, I miss the point not to check/consider workflow status. who might want to cancel already completed or cancelled workflows? it's even not possible to do it manually since it doesn't make any sense.

furthermore, even if I set terminatePreviousInstances to false it still goes through all the instances of current workflow version, REGARDLESS of status. so, if I have 1000 completed workflow instances of current version and 1 running instance which I'm willing to cancel,  I still get 1000+1 notifications about cancelled workflows.

I know, you may say to switch off notifications in site settings. but that's not an option, I want to be notified about failed RUNNING workflows.

I'm sorry, I somehow can not accept this as designed feature.

and final note, this topic is about notifications. but i would be interested in what's exactly going on in background when already completed workflow is to be cancelled. likely other unforeseen effects might arise (eg. it might affect cleaning jobs)

Badge +5

I can confirm ‌, that this effect also occurs if the setting for previous versions is false.

And the setting MUST be true because it could be that a new version of the workflow is published while the instance of the older version is still running but the workflow itself should be cancelled for the listitem, no matter which version the workflow is.

I can't image this is an expected behaviour as, like Marian said, there is no sense in getting noticed for already (maybe long time before) completed/errored workflows.

Userlevel 6
Badge +15

To be honest, I have used this for terminating errored workflows which appear to be dropped into the same bucket as cancelled.

Userlevel 5
Badge +14

do you mean 'the same bucket' like already cancelled workflow were being cancelled once again?

Reply