You are viewing limited content. For full access, please sign in.

Question

Question

Removed some intermediate timers from a forms process, and now all the instances are terminating

Forms
Updated September 8, 2021
asked on June 10, 2019

We are on 10.2.1

We have a process that had some intermediate timers attached to user tasks that sent email reminders:

We decided against this, and removed the intermediate timer events.

Now though, process instances have started terminating one by one, and we can't seem to be able to stop it, or to recover them.

We noted that sometimes, Forms warns you if you try to delete an activity:

However, for the intermediate timer events, we did NOT receive this warning. And yet, the instances are still terminating.

How do we stop it? There are literally hundreds.

(I also want to note that this is some terrible user-hostile software design, since Forms has no concept of process versioning, or a way of saying "apply this change only to newly started instances.")

2 0

Replies

replied on September 19, 2019

Had a similar issue, there is no fix. Was also surprised that there was no warning that processes depended on the timer like it normally provides for other items on the canvas. 

1 0
replied on December 2, 2019

Just encountered this problem myself. Definitely not intuitive and didn't expect processes to start terminating. This highlights the need to be able to restart processes from point of termination. 

1 0
replied on September 19, 2019

It makes sense and doesn't at the same time. Since the instances were not specifically at the intermediate timer event, I would have expected that removing it would not interfere with instances that were at the task it was attached to. On the other hand, depending on how that is programmed it could see it as one thing and because of the change terminates the instances at that task. Not saying it's good, just trying to understand. I am also surprised that it does not warn you like you mentioned though.

0 0
replied on October 8, 2019 • Show version history

I wanted to chime in as a victim. I had to manually reassign and process about 100 instances to remediate. This flaw (yes, flaw imo) should be addressed more clearly, loudly and persistently. 

Also, to effectively deactivate a timer when you have many active instances that could potentially be using the timer: 

  • send the timer to an 'end event' AND KEEP IT RIGHT WHERE IT IS. DO NOT DELETE. This is UN-intuitive to say the least. 

 

I looked through the 10.4 list of changes and the Forms 10.4.1 Update 1 list of changes. Nothing.

 

 

0 0
replied on October 8, 2019

Agreed that it is not intuitive in the slightest and downright dangerous if it happens to a production instance.

My workaround was to wait until after hours since the timers were attached to an approval process [1] then create a duplicate task called approval process [2] with all the same outflows as ap[1]. I then connected ap[1] to ap[2] using an outflow I had configured labelled "Redirect to AP2".. I then reassigned the processes to myself one by one and redirected them to ap[2] which didn't have a timer attachment. I didn't need to reassign the redirected tasks as they automatically assigned themselves based on a variable.. Would have been a different story (simply would have taken more time, not impossible) if it were a based on "Previous Submitter" or team based assignment though. :(

 

Hopefully the team consider fixing it by adding more process controls.

0 0
replied on October 10, 2019 • Show version history

Has anyone here seen the notification @████████ shows above in versions later than 10.2.1? This is regarding the deletion of an activity, timer, throw, catch, etc..

Here it is:

Thanks

0 0
View 1 previous reply
replied on October 10, 2019

Yes. This happens if you try to delete a TASK that is currently assigned to someone. There is no warning if you delete a TIMER event from a task.

My solution:

 

1 0
replied on September 7, 2021

@Kris Hyman   did you just leave this re-route in the production BP?  How did you return the BP to 'normal' operation?

0 0
replied on September 7, 2021

Hi @████████

In production it would look slightly different. I would have routed all "new" submissions (coming via the Start Event in the example) away from the troubled "Original User Task" and straight to the new Task (Copy of Original User Task). 

That way should any new traffic arrive while I'm working on migrating the the tasks away from the troubled task, they will be managed correctly / as normal. 

Don't get me started on how these workarounds impact reporting. Haha.

As a side note, I don't come across this issues as much because Laserfiche implemented a native "reminders function" tab directly into Tasks and that has really reduced the number of timers we use in our process designs. 

0 0
replied on September 8, 2021

@Kris Hyman, that makes sense.

I'm still not sure how to route the flow past the affected timer since my timer task routed back to the task itself, not to another task and end event.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...