Aaron Summers Posted December 3, 2018 Share Posted December 3, 2018 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 Link to comment Share on other sites More sharing options...
James Ainsworth Posted December 3, 2018 Share Posted December 3, 2018 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 Link to comment Share on other sites More sharing options...
Aaron Summers Posted December 4, 2018 Author Share Posted December 4, 2018 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 Link to comment Share on other sites More sharing options...
lomixture Posted December 4, 2018 Share Posted December 4, 2018 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 Link to comment Share on other sites More sharing options...
lomixture Posted December 4, 2018 Share Posted December 4, 2018 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 Link to comment Share on other sites More sharing options...
James Ainsworth Posted December 4, 2018 Share Posted December 4, 2018 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 Link to comment Share on other sites More sharing options...
James Ainsworth Posted December 4, 2018 Share Posted December 4, 2018 Hi @lokent Could you post the properties of this node... Thanks, James Link to comment Share on other sites More sharing options...
James Ainsworth Posted December 4, 2018 Share Posted December 4, 2018 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 Link to comment Share on other sites More sharing options...
James Ainsworth Posted December 4, 2018 Share Posted December 4, 2018 @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 Link to comment Share on other sites More sharing options...
James Ainsworth Posted December 4, 2018 Share Posted December 4, 2018 @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 Link to comment Share on other sites More sharing options...
Aaron Summers Posted December 5, 2018 Author Share Posted December 5, 2018 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 Link to comment Share on other sites More sharing options...
Lauren Posted December 5, 2018 Share Posted December 5, 2018 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 Link to comment Share on other sites More sharing options...
samwoo Posted December 5, 2018 Share Posted December 5, 2018 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?: Link to comment Share on other sites More sharing options...
Victor Posted December 5, 2018 Share Posted December 5, 2018 This is now being investigated by support. I'll update this as soon as I have more info. Link to comment Share on other sites More sharing options...
Jeremy Posted December 5, 2018 Share Posted December 5, 2018 This is also happening for us at the UoP Link to comment Share on other sites More sharing options...
Victor Posted December 5, 2018 Share Posted December 5, 2018 @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. 1 Link to comment Share on other sites More sharing options...
samwoo Posted December 5, 2018 Share Posted December 5, 2018 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. Link to comment Share on other sites More sharing options...
Aaron Summers Posted December 6, 2018 Author Share Posted December 6, 2018 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 Link to comment Share on other sites More sharing options...
Victor Posted December 6, 2018 Share Posted December 6, 2018 Yes, there were some changes to the suspend nodes. Anyway, we fixed this issue please deploy the latest update at your earliest convenience: 1 Link to comment Share on other sites More sharing options...
Aaron Summers Posted December 6, 2018 Author Share Posted December 6, 2018 Thanks @Victor I will monitor in the next few days and confirm about this. Regards, Aaron Link to comment Share on other sites More sharing options...
lomixture Posted December 6, 2018 Share Posted December 6, 2018 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 1 Link to comment Share on other sites More sharing options...
Aaron Summers Posted December 7, 2018 Author Share Posted December 7, 2018 Hello @Victor I am pleased to say that the error have fixed and now it is working as intended. Thank you! Aaron Link to comment Share on other sites More sharing options...
Jeremy Posted December 11, 2018 Share Posted December 11, 2018 @Victor We are still experiencing this issue is there something that can be applied to our instance? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now