Calls not auto closing

[yelyah.nodrog]

Good Morning,

It has been raised to me by every one of out teams have noticed that their calls are not closing after the standard 5 days. We applied a auto close node to the BPM when we started using hornbill - Daniel helped us build our BPM's 

I have checked both the Incident and Service Request BPM's and they both have the auto close node set up to close after 5 days. But as you can see below no calls have been closed since the very beginning. Are the Nodes set up incorrectly or is this a known error?

Many thanks

Hayley.

[Guest]

@yelyah.nodrog This issue was reported previously and has been fixed. The fix will be available in the next Service Manager update which is due for release in the next few days. I don't think there is anything wrong with how you set up your nodes. Once you update your system when the update is available, the calls should auto-close.

 

Regards

 

Pamela

[yelyah.nodrog]

Thanks Pam 

[Graham1989]

Hi,

Has anyone managed to get the auto-close node to work? I have it set up to close after 5 days however any calls that are Service Requests are not closing and just stay as Resolved.

Any ideas?

Thanks

[Victor]

@Graham1989 it does work but it is not very straight forward how you need to set the days and time here... is the same algorithm used on SLA timers... When you set the node to 5 days, for example, this is what is actually happening:

• 5 days * 24 hrs is a day =  120 hours;
• lets assume your service level calendar is set to 8 hours/day: 120 hrs / 8 working hours in a day = 15 working days.

So you see the 5 days setting in the node actually equates with 15 working days... If you need to achieve a 5 working day closure you would need to work sort of "backwards": 5 working days x 8 working hours in a day = 40 hours - this means 24 hours + 16 hours: You would need to set the node to close after 1 day and 16 hours OR straight 40 hours.

[yelyah.nodrog]

Morning Victor,

This is actually really helpful. One question. We have 2 x service level calendars one is for our critical issues (P1 and P2's) which runs 24-7 the other is for anything below this that runs normal office hours.
The way our progressive captures are set up everything roots to one call closure node. will we have to split this depending on the priority?

Thanks

Hayley

[Guest Ehsan]

@yelyah.nodrog

You can configure a default Calendar through guest.app.timer.defaultCalendar Application Setting (Admin Tool > Click on "Hornbill Service Manager" tile > Click on "Settings" tile > Filter the results by the term). You can only set up one Calendar for the option to close a request after a period of time, so please update the Application Setting to select the preferred Calendar.

Thanks,

Ehsan

[Claire Holtham]

We have noticed that some times our calls are auto-closing after 7 days, and some times they are not closing at all but remain at 'Resolved'.

The calls that are closing properly are being marked on the checkpoint as 'closed', and the status is updating to 'Closed' by the system user: System Internal Context - this is happening after 7 days (so there is no difficulty with the working time calendar).

The calls that are not closing properly, are still being marked on the checkpoint as closed, but the status is not updating, and remains at 'Resolved'. For the period 1-7th march where 700 calls were resolved, 368 (half) are stuck at resolved, and of the 332 that were closed - 115 did so automatically (so a quarter). There is a range of bpm's being used - but the issue is not specific to particular bpms.

Our set up is that there is an activity requesting feedback/closure, and once that expires the 'System Internal Context' is supposed to close the call.

Is it possible to re-trigger that 'System Internal context' so if the activity is expired it closes the call, and we don't have to manually set hundreds of calls to 'Closed' manually?

I'd also like to know why there is the inconsistency!

[Victor]

@Claire Holtham can you give us some examples of these requests so we can establish the scenarios where this worked/not worked? Thanks!

[Claire Holtham]

Hi Victor,

I've tried spotting trends in what works and what does not. it's not specific to Service Requests or instances; it's not specific to particular bpm's - our cyc_incident_live bpm (which is probably our most used bpm) sometimes auto-closes and sometimes doesn't.

Ive attached a screen shot of the bpm.

I have created some reports - which capture the below fields

I can attach them to the call if you think that would help.

Request ID

Catalog

Date Closed

Date Resolved

Status

Service Name

Closed By Username

Closed By Team

[Melissa Gurney]

@Victor FYI I will be picking this issue up whilst Claire is away this week. Thanks, Melissa

[Steve Giller]

On the above flow, the Await Closure node appears to be a Human Task - the "autoclose" node should be an Automated Task I believe?

[Melissa Gurney]

Ah right ok thanks @DeadMeatGF. I will try it as automatic. Odd as that was added by Hornbill during a remote session. Thanks, Melissa

[Victor]

@DeadMeatGF @Melissa Gurney the task should be human... to cater for a request reopening... and is how an analyst should reopen a request if necessary. The "automatic closure" node will not cater for any request status it will proceed with closure regardless of what happens to the request. The way it works is that it creates a BP "close request" event on that specific date/time. When the date/time is reached the event triggers, regardless of the request condition/status... So, you should use the automatic closure only when you are sure teh request should be closed regardless in that specific time frame...

[Steve Giller]

Sorry - what I missed was the Human Task to close the call is there, but there's no "Close after [time]" node before it, so it will never autoclose, which I believe is what is required here.

[Melissa Gurney]

@Victor are you able to confirm if the above BP is correctly set up? TIA

[Victor]

@DeadMeatGF it will (sort of) auto close when the tasks expires... BP will follow the "Expired" branch which closes the request... So the general idea was that you create a human task with X days expiration time.... task has 2 outcomes "Close" and "Reopen". On "Close" it will happen basically the same as when the task would expire which is to set request status to closed (and trigger the whole close request flowcode). If the analyst selects "Reopen" then the request status is changed to open and loops back on "resolution"...

@Melissa Gurney if nothing changed (in your support internal process) since we discussed the BP then yes, it looks correctly configured

[Melissa Gurney]

@Victor thank you. Nothing has changed with our internal processes so not sure why we are having issues with calls randomly not closing automatically.

[Victor]

@Melissa Gurney if you can gather couple of examples I can have a look and see if I can find anything...

[Melissa Gurney]

@Victor Ill do that now thanks. Shall I do this on the forum or raise a request?

[Victor]

@Melissa Gurney whichever you prefer  

Raising a request gives you a reference if you want to track it... but here is fine also since I am trolling the forums anyway

[Melissa Gurney]

@Victor I have raised a request - just makes it easier to send stuff through to you and for Claire to pick up when she returns

 

[Victor]

@Melissa Gurney no worries, we'll raise an incident now and update you as soon as possible