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

Question

Question

Does workflow go stale?

asked on October 8, 2014

We have a workflow that runs great, except on older items. It runs an approval process, and sometimes managers don't get around to approving the documents right away and the documents sit in there for a while - they do get reminders about them. My issue is that after a few months when managers go to approve them, they mark them approved and these documents won't do what they are supposed to, which is A) move to the approval folder and B) have the data recorded in a spreadsheet.

 

However, they can do the same with more recent documents and these process as they should. I may have modified the workflow in the meantime, but I always choose to update any running instances when I publish the workflow.

 

So, my questions are:  Why does it do this/what can I do to correct this?

 

And, is there a way to play a workflow from the middle? This workflow sends out confirmations and alerts and I don't want to play it and send these out again, and I can't manually move it, or it won't update the external spreadsheet, which is the whole point of the workflow. And suggestions would be much appreciated, thanks!

0 0

Replies

replied on October 8, 2014

Is the workflow instance still running? What version are you using? We've had some issues in the past where updating running instances interfered with evaluating wait conditions on user actions on the document Workflow was waiting on.

1 0
replied on October 9, 2014

Hey Danielle,

In the Workflow administration console you can override Wait Conditions under Monitoring -> Wait Conditions. Just find the name of the workflow and look for the instance that is stuck. You can then see which activity it is stuck on, and in the right-hand panel override the wait condition. If you had tons of running instances stuck you could even override all of them.

I'm not 100% sure that this will work with this problem, but if it does that should get the workflow back on track.

 

1 0
replied on October 27, 2014

Thanks! I want to say we've tried this before and it didn't work, but maybe not. I think that it didn't appear here because it wasn't "waiting" - it had already been approved and should have been on its way. Like there was a disconnect between all of the info on the back side - where it didn't register any documents waiting and where the condition evaluated to true, but it just wouldn't move and there was no logical reason it shouldn't have. I will definitely try this next time.

 

Also, I didn't realize that by not updating running instances that they would run off an old version. I guess that would make sense (and I should have done my homework!) I was thinking that if I replaced the workflow entirely, that there would be no workflow for the old ones to run off! Well, I'll stop doing that when possible then, thanks for the tip!

0 0
replied on October 10, 2014 Show version history

Take a look at this answer, it got a workaround for future workflows, but for now what is stuck is stuck, better to end them:

 

https://answers.laserfiche.com/questions/52073/Wait-condition-met-but-workflow-does-not-move-to-next-step

 

Based on what you said "I may have modified the workflow in the meantime, but I always choose to update any running instances when I publish the workflow."

In short, if your workflow was waiting and you update running instances, your workflow will stuck, better not to update running instance, yes they will have the old logic, but at least they are working.

 

Try these steps and you will notice it is similar to what you are facing, it was very difficult to spot the reason as our WF run for months:

 

1- Publish a WF with Route Entry to Folder with waiting status for example <tag> is set and to Send Email every 5 minutes for 60 email - the idea is to have "Route Entry to Folder" to be in waiting state while sending emails.

2- Run it on entry

Definition: Version 1
Designer : Version 1 - Waiting

Diagnostic: Version 1 - False - Next Timer: (Date/Time + 5 minutes)

2- Wait for the first email to be sent so you can 5 minutes to do next step

3- Publish: Overwrite: Yes - Update running WF: Yes

Definition: Version 2
Designer : Version 1 - Waiting
Diagnostic: Version 2 - True - Next Timer: (Date/Time + 5 minutes)

4- Wait for the next email, then notice values changed

Definition: Version 2
Designer : Version 2 - Waiting
Diagnostic: Version 1 - False - Next Timer: (Date/Time + 5 minutes)

5- When the Next Timer the WF will stuck on running with these values

Definition: Version 2
Designer : Version 2 - Running
Diagnostic: Version 1 - False - Next Timer: Empty

6- Error in Activity log but last modified date remain the same

7- Set the tag to true to end the wait and you will see an activity (wait for entry change) highlighted in blue in the instance details, but the conditions tab shows the conditions for it have evaluated successfully.

 

 

 

1 0
replied on October 9, 2014

We are now on 9.1.1.365. And that's exactly what is happening, it's stuck on a wait condition. It even evaluates to True, yet it won't move. I think that I'm done messing with the workflow, so hopefully I won't have to update it anymore and cause these problems, but I wanted to find a solution in case it happens again in the future on this workflow or another. At the moment, I have a workaround, but if I had a bunch of documents, it would not be pretty.

 

I wish I could click the document and hit "play from here", or click into the workflow in a certain place and play it on that document.

 

Would it be best practice to break out the workflow and after the wait condition, invoke another workflow (2nd half of the original workflow)? Thanks!

0 0
replied on January 23, 2018

I wish I could click the document and hit "play from here", or click into the workflow in a certain place and play it on that document.

 

I second this option.

1 0
replied on January 24, 2018 Show version history

What I ended up doing was copying half of my workflow to a new workflow that remained unscheduled and un-conditioned (?) - nothing would trigger it, it was merely for me to play on stuck things. 

 

If I were to play the entire thing on the stuck document to "refresh" the workflow, it would kick off a bunch of notifications. So I basically created a separate workflow that I could specifically play on stuck items that would not kick off any notifications. If I made any changes to the workflow, it was easy enough to just copy and paste them over to my refresh workflow. 

 

I have not had this happen in some time though. I can't remember if I actually stopped updating the running instances as a practice, though I feel like that's what I do now. (I am no longer the LF administrator for my org :( ) That somehow there may be some disconnect between those instances running off one workflow and then another. And I typically don't change criteria that would make a material difference to this - it's usually some sort of error handling. 

0 0
replied on January 23, 2018

I am having that same issue with the wait conditions waiting off of an old workflow and not overriding to the new one..... my wait condition used to be  "Wait until the 'patrol exam score' field is greater than or equal to 70" 

Now that department wants it to be just pass or fail... so that field got changed. 

the waiting instances are still waiting on that 70+ score and if the value is "fail" it will still pass it through.....

 

Any tips on how to get this corrected? will the override wait conditions just pass the instance onto the ext activity?

0 0
replied on January 23, 2018

Perhaps you didn't  select the option to update running instances when you updated the workflow.

Note my answer "replied on October 10, 2014". Better to keep the old instance using the old logic - at least they are working, else they will stuck and then you will have to end them.

 

0 0
replied on January 24, 2018

Do you have 2 different fields - one that has the score and another that is pass or fail? If so, I would change your criteria to wait for both fields - 70+ AND Pass or <70 and Fail. Or, if it's one field, for now change the criteria to wait for either or. Or, sometimes I'll go in and change anything currently waiting to the new criteria (if that is prudent for your position).

 

Whenever I do changes like that, I try to accommodate both the old and the new for a time period, if I can't just change the field to the new criteria - like I do when we just reclassify filed docs. I used to accept only a certain form. Then they changed the form. Without fail, every month I would get people submitting the old form and it would mess things up. So, I accommodated for both for a time until the old one phased out. 

0 0
replied on January 24, 2018

When you publish changes to a workflow (and choose to update the running instances), any currently executing activities will not update. Only activities after the currently running one(s) would update.

So, any instances currently in a wait state will continue to wait for the conditions that existed when the wait started. Overriding them in the admin console will just release the document on to the next step. Your workflow design would have to account for any missing data due to the design changes.

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

Sign in to reply to this post.