Closed tickets showing as Resolved

[Guest gregmarcroftorc]

We have noticed on the odd occasion that tickets that we believed were closed are showing in the request list as Resolved rather than Closed. This is odd because I do not recall us doing anything differently and it has just happened on a ticket that I closed about half an hour ago and as I said, I don't know how I would have closed it any differently.

I click the tick icon. Then type out my closure message. Then click Close.

 

Any ideas?

 

 

 

 

[Victor]

When you go into the request, is the request showing as closed or resolved? Just trying to see if there could be an issue with the request itself or the list...

[Guest gregmarcroftorc]

The green bar appears to be at the end and is showing a tick in the part that says end. The status however is "Resolved" for the ones that are coming up as resolved and obviously "Closed" for the ones that are closed.

 

I noticed when comparing that the ones that are closed say "Status has been closed by the Business Process Engine" whereas the resolved ones don't. Both say "Request has been resolved without a category".

 

It may be that we have not missed a step on them resolved ones but it seems unlikely because we always follow the same steps. Click the tick icon, type in a comment and then click close.

[James Ainsworth]

Thanks for your post. I'm wondering if there is some logic in the workflow that is making these changes.  Do you have access to the workflow and would you be able to share a screenshot of your investigation and closure stage?

The default position for completing a request is to use a two stage closure approach (resolution followed by closure). The workflow can control this behavior to have a single stage closure where one once resolved the status is automatically changed to closed.

The green bar, or the "Heads-up display", is created as part of this backend workflow by the workflow manager.   If a two stage closure is being used, additional checkpoints could be added to display the completion of both the resolved and closed stages. The "End" node of the Heads-up display signifies the end of the workflow rather than the closure of a request, although it is worth trying to align the two when creating the workflow.

I hope this helps.

James  

[Victor]

15 hours ago, gregmarcroftorc said:

I noticed when comparing that the ones that are closed say "Status has been closed by the Business Process Engine" whereas the resolved ones don't. Both say "Request has been resolved without a category".

This could be only a coincidence. What actually happens in your instance is that at some point someone changed the word "Resolved" to "Closed" via translation functionality. So when you see the "Close" button it it actually resolve. So probably this is why the requests not closed by BP will have a resolved status while the other ones will have a closed status because the BP is configured to close the calls.

Have look in the admin tool: Home -> Service Manager -> Translations. Search for this key: user.view.request.details.resolve.resolve and you will see is translated to "Close".

[Guest gregmarcroftorc]

I am not sure who could have changed anything there as there are only 2 of us with access from our side and we wouldn't have done it, and the contact who helped us set up from Hornbill has not been changing anything in there recently as far as I am aware. This is what it looks like. Is there anything that looks wrong here? It still seems odd to me that it is only about 6 requests out of all the ones we have logged in the last couple of months, so i would assume that this is something we are clicking/not clicking without realising, or it is a defect on Service Manager:

 

[Victor]

@gregmarcroftorc there is no defect is just translation of the resolve action that says "Close" instead of "Resolve". So when the analyst clicks the "Close" button it is actually resolving the request, not closing.

[James Ainsworth]

The orange button on the far right signifies that it has been changed from its default translation.  Simply by clicking on this button you will revert back to the default translation.

[Guest gregmarcroftorc]

Hi both @Victor @James Ainsworth. Thanks for your responses. I think I understand what you are both saying now about the translation and I assume it was the person from Hornbill who we have been amending certain things with who added this translation a while ago. 

However, I am still struggling to understand why only a few requests are showing as resolved so are you both please able to explain to me why you think this is? Apologies that I have not understood your explanations. For example, in July we had about 755 requests for that month, however only about 10 of them in that whole time were showing as Resolved and not Closed, yet to our knowledge, we have been following the same process each time one of us analysts closes a ticket. 

Just to avoid any confusion, when I say "close" I simply mean that we click on this button below that actually says Resolve

 

We then type out some text in the box that says Closure and then click on the Close button like this:

We do this for every single request when closing which is why I am confused as to why about 10 of them are showing as resolved and not closed. If it was to do with a translation, surely they would all show up as resolved? We are using the same BP for the vast majority of tickets and from investigating the ones that are resolved it is not linked to a difference in BP e.g our BP for self service.

 

[Guest gregmarcroftorc]

Also @James Ainsworth I missed the part of your reply where you asked for a screenshot of the Investigation and Closure part. Here it is:

 

[Victor]

@gregmarcroftorc I think I understand now why you have the "Resolve" button/action translated to "Close"... I am not familiar with the initial set up, but it kind of makes sense when I assume you had this translation as your BP will automatically close the ticket once it has been resolved. Therefore it would have been more meaningful for the analysts to see "Close" instead of "Resolve"...

 

This being said, I don't really see why some of the tickets woudl have remained in a resolved state... unless... one scenario I can think of is perhaps the ticket was reopened... in this case, because the BP finished when it was originally resolved, when it was reopened and resolved the second time it would have stayed in the resolved state - the BP would have not been there to close it automatically. So unless the analyst would have closed it manually (unlikely since your analysts are not used to it since usually is enough for them to resolve it  - translated to close) ... another scenario woudl have been if for some reason the BP failed to go past the "Await Resolution" node even if a resolution exists on the ticket... this would be a defect in my view...

 

Sorry for the long and convoluted post, hope it makes sense

 

I can have a look in your instance and see if I can find out why the 10 tickets remained in the resolved state and I would need some call references to investigate this...

 

EDIT: following you post regarding missing rows for "SLA met/not met" report, another scenario for this issue might be that the 10 tickets do not have the BP associated. Following my above reasoning, the BP would have not been there to close the ticket so they would have remained in a resolved state....

[Guest gregmarcroftorc]

Thanks Victor. I can only find the following but these are the ones that were showing as resolved. Both myself and colleague noticed these so in the end we went in and clicked close again on them after they were showing as resolved. 

IN00000525

IN00000858

IN00000838

IN00000479

IN00000561

IN00000813

With the last one on that list, I remember closing that one as I normally would and then being surprised that it was showing as resolved and not closed. I didn't do anything different to normal as far as I know. I then went and clicked the Close button to close it off properly.

 

 

[Victor]

@gregmarcroftorc had a quick look at the examples you mentioned:

IN00000525, IN00000858, IN00000838, IN00000813  - reopened - so they would fall under the first scenario (reopened scenario that I described above).

IN00000561 - missing BP - would fall under the second scenario (missing BP scenario that I described above).

IN00000479 - now this is an interesting one!

This one actually followed the process, as intended and it would have been closed as any other "regular" ticket but... looking at the timeline I believe the following scenario occurred:

• call logged at 04/07 at 16:28 and progressed normally
• call resolved by analyst (like any other call) on 11/07 at 14:32:37 (second are important, you'll see why below)

The BP did its thing as you can see at 14:32:38 set the status to Closed and at 14:32:39 sent the resolution email to customer. The timeline updates and the quick sequence shows that it could only have been the BP that set the status and sent the resolution email.

The important part happened now. The analyst, Peter, still had the request open with action focus on resolution box. Because the request had not been refreshed (not to any fault from Peter by the way), the "Close" button was still "active" as resolve! Hope this part makes sense  The UI did not know that the BP actually set the status to closed.... So when Peter clicked the "Close" button again, it changed the request status to resolved... as it usually does when the resolve action is performed. So basically it reverted the closing action that the BP just did!

 

Now I imagine you woudl want to avoid this scenario in the future so I'll have a look and see what can be done, I'll get back to you on this... Meanwhile, may I suggest to let your analysts know that is sufficient to perform the "Close" action only once as the BP will do the rest (i.e. close the ticket) regardless of the UI status... 

[Guest gregmarcroftorc]

Thanks a lot for looking in to this @Victor.

I have had a look in to those re-opened ones now and have found out the reason it happens on those ones. I logged a test ticket and I noticed that once you have re-opened the ticket, when you go to "close" it again by selecting the tick icon and clicking the Close button, this only seems to do half the job, e.g it only sets it to resolve as you mentioned. We then need to click on close again to actually turn it from resolved to closed. This is not the case when we follow our normal procedure to close a ticket where we only have to click on that close button once. I will make sure the rest of my team are aware of this now.

Funnily enough this seems to conflict with ticket 479 where you mentioned that clicking close twice actually reverts the action. 

These anomalies are not much of an issue providing we know the cause which we now do so I will make sure the team are aware.

Greg

 

[Victor]

5 minutes ago, gregmarcroftorc said:

I logged a test ticket and I noticed that once you have re-opened the ticket, when you go to "close" it again by selecting the tick icon and clicking the Close button, this only seems to do half the job, e.g it only sets it to resolve as you mentioned. We then need to click on close again to actually turn it from resolved to closed.

Indeed, because there is no BP any more on these ones to perform the actual closure, the BP concluded/ended first time it was resolved/closed.

 

6 minutes ago, gregmarcroftorc said:

Funnily enough this seems to conflict with ticket 479 where you mentioned that clicking close twice actually reverts the action. 

Well, kind of, as I said is a bit of interesting one... basically the BP does something (i.e. setting the status to close) but this is not picked up by the request interface, unless the request is refreshed so the UI reads the current/new request values, it won't do it automatically as it is not designed as such...

So from the request perspective (exclusively) it is not reverting a closed ticket... One of the things "resolve" action does is to set the request status to resolved...now, you can have something else (like the BP) which can set a closed status so in the end it will look like it reverts... but in fact "resolve" is acting as designed - to set the status to resolved... 

 

I will suggest our developers to make change in the resolve action to check for the request status prior to changing it to resolved... so if the request status is currently set to close, then the resolve action will prompt a warning or info to the user saying that it could not perform the resolve action as the current status is set to closed...

 

[Guest gregmarcroftorc]

Ok thanks for the clarification, I see what you are saying.

Greg