Expiry outcome after suspend nodes does not work

[Aaron Summers]

Hello,

One of my colleague bring this to my attention today and it just seems quite bizarre of what happened to these tickets.

We have BPM that start 5 working days after resolve the ticket and then automatically close if there is no activity happen in during 5 working days (which should not include the weekend).

So this is what happened to the ticket below:

This is what it look like in BPM, closure stage node:

This does include the weekend and then reopened it even though there is no activity happened during 5 working days?
 

This had affect on 5 tickets so far. (Awaiting to hear back from colleague whether there is more tickets that are affected).

Can you help to identify the issues with this please?

Thanks,
Aaron Summers

[James Ainsworth]

Hi @Aaron Summers

The Wait for Status Change will only suspend the processing of the BPM until the status has changed.  There will be another node in your workflow that does that actual changing of the status.

I might need a screen shot or copy of your workflow to look at this. 

From the timeline, in this particular case it has reached the expiry which would mean that the BPM would have restarted with the request still with the Status of Resolved.  I'm guessing that you may have a decision node following this suspend to check the status.  In this decision node it would need a route for each of the possible statuses that it could change to, including Resolved (or Expired). for when an expiry happens.  If this is the case and you do have a decision node that follows the suspend node above, maybe a screenshot of that would help.

Regards,

James

[Aaron Summers]

Hi @James Ainsworth

Technical Support team leader, Ivan have now reported of more tickets reopened themselves this morning so it had start to affect across our team tickets which seems to start from 27th November onward.

Normally when it expire after 5 working days with no activity then the ticket will automatically close and it work without any issue for us for long time so obviously something must have happened in the last week of November that have start causing this tickets for us.

Please see the BPM in Closure stage below:

(P.S. I have tried to login on Hornbill to raise a request because I need to escalate this issue for priority to fix it but I am unable to login as said "unexpected error occurred login.")

Kind regards,
Aaron Summers

[lomixture]

Good afternoon!

We have had an issue raised to our attention whereby requests that have been resolved, and then reopened either by the customer or the analyst, are not then automatically closing as per the business process once secondarily resolved.

We have looked into this previously, and got the error resolved but it appears to be back with a vengeance and I'm just getting fed up of the team keep raising the same issue to me!!

I have attached a screenshot of our BP above, are there any simple issues I am missing? I am BP blind at this stage!

Thanks

Lauren & @Gemma Morrison

[lomixture]

Me again, terrible Tuesday it would appear....

Our team are saying that our customers are continually calling this morning telling us they are receiving multiple resolution emails - i.e. in the BP listed on this request

we have a node which sends an email when a job has been closed after 20minutes. However, our staff are getting the same email EVERY 20minutes and again, we don't know why?!

Thank you in advance,

Lauren and @Gemma Morrison

[James Ainsworth]

The next thing to look at @Aaron Summers is the expression on the expired outcome.  It sounds like even when the 2 Stage Closure node expires, the decision node is not capturing this correctly and it is taking the No Match route rather than the expired route.  

What could be happening here is it doesn't look like you have an path for when a request is manually closed.  If a request is manually closed from the resolved status, this would not follow the path of being expired.  It would follow the path of No Match which would lead it to being re-opened.  However, the screen shot of the timeline in the original post doesn't suggest that a manual closing of the request is taking place.  Could the customers be accepting the resolution from Self Service which will then close the request, which again will cause an automatic re-opening.  In any case you need a separate branch from your decision node checking if the status has changed to closed.

I will contact support about the issue you have with your login to Hornbill. 

Regards,

James

[James Ainsworth]

Hi @lokent

Could you post the properties of this node...

Thanks,

James

[James Ainsworth]

Hi @lokent

Looking at the workflow in the linked post, I can see the possibility of a loop being created.  If we get to the bottom of why the re-opened requests not resolving, this may resolve both issues.

Regards,

James

[James Ainsworth]

@Aaron Summers

I've just come across this Service Manager update.  It would be worth applying this to see if this corrects the issue.  I would still recommend adding a decision option for Closed requests. 

Regards,

James

[James Ainsworth]

@lokent

It appears that a Service Manager update (1393) is available that provides a fix to the suspend operation Wait for Status Change.  I can't say at this point if it is directly related to your issue but it would be worth applying the update to see if this corrects your issue.

Regards,

James

 

[Aaron Summers]

Hi @James Ainsworth

I have already updated SM and this did not fixed the issue.

Victor is looking at this at the moment and hopefully find the solution for it.

Kind regards,
Aaron Summers

[Lauren]

Hi @James Ainsworth

We've observed a similar issue (first observed on Monday 3rd Dec) where some customers are being emailed every 1-2 minutes with the same resolution email. This only appears to happen when logging via a particular catalogue item.

However, the business process in question has been live for some time - I'm aware that there have been a couple of new releases over the past 7 days. Is there the possibility that this could have caused the looping?

Thanks

Lauren

for info @lokent @Gemma Morrison @BobbyB

[samwoo]

21 hours ago, James Ainsworth said:

The next thing to look at @Aaron Summers is the expression on the expired outcome.  It sounds like even when the 2 Stage Closure node expires, the decision node is not capturing this correctly and it is taking the No Match route rather than the expired route.  

What could be happening here is it doesn't look like you have an path for when a request is manually closed.  If a request is manually closed from the resolved status, this would not follow the path of being expired.  It would follow the path of No Match which would lead it to being re-opened.  However, the screen shot of the timeline in the original post doesn't suggest that a manual closing of the request is taking place.  Could the customers be accepting the resolution from Self Service which will then close the request, which again will cause an automatic re-opening.  In any case you need a separate branch from your decision node checking if the status has changed to closed.

I will contact support about the issue you have with your login to Hornbill. 

Regards,

James

Hi @James Ainsworth,

I admit we could have handled the process for manual request closures better, but the idea is that if someone closes a ticket manually we can identify who is not following the process of resolving a call and letting it close automatically after 37 working hours. It should not be using the weekend since we are using the Service Desk calendar (i have just been informed that it does include the weekend days where it shouldn't be - I will need to investigate this)

Prior to the 27th November this entire process was working as it should. We did have a couple of occassions where the analyst closed the ticket manually and it reopened, but it was working properly as we expected it to. We just cannot undertstand why nearly all of our processes are now affected by the issue, especially when the Business Processes haven't been changed.

We are now up to 50 tickets that have been reopened out of the blue... the timeline doesn't have anything to show that the ticket has been reopened by anyone... except the following (after 37 hours from being resolved):

System Internal Context
The status has been set to Open by the Business Process Engine

If you look at @Aaron Summers previous screenshot, when the task expires from the decision node, it should be going -> right to close the call. But what it looks like is happen is that when it expires, it fires a "no match" and goes up and reopens the call. Then we start to get into a loop where the analyst resolves the call again and the issue repeats.

Thanks,

Samuel

 

EDIT

Is this issue by any form or another related to the following?:

[Victor]

This is now being investigated by support. I'll update this as soon as I have more info.

[Jeremy]

This is also happening for us at the UoP

[Victor]

@Aaron Summers @samwoo @lokent @Jeremy

I have investigated this on the support request raised by Aaron and although I was unable to establish why this is happening I can clearly see it happening when it should not. I do not see any misconfiguration and as far as the process is designed, it should work... I have gathered all the info I could find about this and I have asked our dev teams to look into this with priority. I will come back to this with more updates once I have their feedback.

@lokent FYI - forum topics that you created about reopened requests not closing and multiple resolution emails being sent to customers were merged into this one as it is the same issue and is better to be discussed in one place.

[samwoo]

2 hours ago, Victor said:

@Aaron Summers @samwoo @lokent @Jeremy

I have investigated this on the support request raised by Aaron and although I was unable to establish why this is happening I can clearly see it happening when it should not. I do not see any misconfiguration and as far as the process is designed, it should work... I have gathered all the info I could find about this and I have asked our dev teams to look into this with priority. I will come back to this with more updates once I have their feedback.

@lokent FYI - forum topics that you created about reopened requests not closing and multiple resolution emails being sent to customers were merged into this one as it is the same issue and is better to be discussed in one place.

Thanks @Victor - hope a resolution can be found quickly.

[Aaron Summers]

Thanks @Victor

I am curious to ask, did Hornbill made some changes or anything of sort on between 26th-27th November? Because all tickets that are affected have started on the 27th to now.

Thanks,
Aaron

[Victor]

Yes, there were some changes to the suspend nodes. Anyway, we fixed this issue please deploy the latest update at your earliest convenience:

 

[Aaron Summers]

Thanks @Victor

I will monitor in the next few days and confirm about this.

Regards,
Aaron

[lomixture]

Hi all,

Apologies I was off yesterday and therefore did not pick any of these up.

Thank you for the above, reads as if a fix has been found so we've applied the update and will let you know if not!

Lauren

[Aaron Summers]

Hello @Victor

I am pleased to say that the error have fixed and now it is working as intended.

Thank you!

Aaron

[Jeremy]

@Victor We are still experiencing this issue is there something that can be applied to our instance?