Jump to content

Calls not auto closing


yelyah.nodrog
 Share

Recommended Posts

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?

CaptureCloseSR.thumb.PNG.14e8e934990e61c878b8fe9982ce1cbd.PNGCaptureClose.thumb.PNG.8a7520fda7376bc3ebdcbc8cabc65343.PNG

CaptureReqpg.thumb.PNG.cfee76150ba32e809510222e4a863d3a.PNG

Many thanks

Hayley.

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

  • 2 weeks later...

@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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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

cyc_incident_live.png

Link to comment
Share on other sites

@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...

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...