yelyah.nodrog Posted March 30, 2017 Share Posted March 30, 2017 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. Link to comment Share on other sites More sharing options...
Guest Posted March 30, 2017 Share Posted March 30, 2017 @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 More sharing options...
yelyah.nodrog Posted March 30, 2017 Author Share Posted March 30, 2017 Thanks Pam Link to comment Share on other sites More sharing options...
Graham1989 Posted April 12, 2017 Share Posted April 12, 2017 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 Link to comment Share on other sites More sharing options...
Victor Posted April 12, 2017 Share Posted April 12, 2017 @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 More sharing options...
yelyah.nodrog Posted April 13, 2017 Author Share Posted April 13, 2017 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 More sharing options...
Guest Ehsan Posted April 13, 2017 Share Posted April 13, 2017 @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 More sharing options...
Claire Holtham Posted April 13, 2017 Share Posted April 13, 2017 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 More sharing options...
Victor Posted April 13, 2017 Share Posted April 13, 2017 @Claire Holtham can you give us some examples of these requests so we can establish the scenarios where this worked/not worked? Thanks! Link to comment Share on other sites More sharing options...
Claire Holtham Posted April 13, 2017 Share Posted April 13, 2017 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 Link to comment Share on other sites More sharing options...
Melissa Gurney Posted April 19, 2017 Share Posted April 19, 2017 @Victor FYI I will be picking this issue up whilst Claire is away this week. Thanks, Melissa Link to comment Share on other sites More sharing options...
Steve Giller Posted April 19, 2017 Share Posted April 19, 2017 On the above flow, the Await Closure node appears to be a Human Task - the "autoclose" node should be an Automated Task I believe? Link to comment Share on other sites More sharing options...
Melissa Gurney Posted April 19, 2017 Share Posted April 19, 2017 Ah right ok thanks @DeadMeatGF. I will try it as automatic. Odd as that was added by Hornbill during a remote session. Thanks, Melissa Link to comment Share on other sites More sharing options...
Victor Posted April 19, 2017 Share Posted April 19, 2017 @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 More sharing options...
Steve Giller Posted April 19, 2017 Share Posted April 19, 2017 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. Link to comment Share on other sites More sharing options...
Melissa Gurney Posted April 19, 2017 Share Posted April 19, 2017 @Victor are you able to confirm if the above BP is correctly set up? TIA Link to comment Share on other sites More sharing options...
Victor Posted April 19, 2017 Share Posted April 19, 2017 @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 More sharing options...
Melissa Gurney Posted April 19, 2017 Share Posted April 19, 2017 @Victor thank you. Nothing has changed with our internal processes so not sure why we are having issues with calls randomly not closing automatically. Link to comment Share on other sites More sharing options...
Victor Posted April 19, 2017 Share Posted April 19, 2017 @Melissa Gurney if you can gather couple of examples I can have a look and see if I can find anything... Link to comment Share on other sites More sharing options...
Melissa Gurney Posted April 19, 2017 Share Posted April 19, 2017 @Victor Ill do that now thanks. Shall I do this on the forum or raise a request? Link to comment Share on other sites More sharing options...
Victor Posted April 19, 2017 Share Posted April 19, 2017 @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 Link to comment Share on other sites More sharing options...
Melissa Gurney Posted April 19, 2017 Share Posted April 19, 2017 @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 Link to comment Share on other sites More sharing options...
Victor Posted April 19, 2017 Share Posted April 19, 2017 @Melissa Gurney no worries, we'll raise an incident now and update you as soon as possible 1 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