Jump to content

David Hall

Hornbill Developer
  • Posts

    539
  • Joined

  • Last visited

  • Days Won

    17

Posts posted by David Hall

  1. Hi @simonadams

    From the Request List view if you click on the cog at the top right to configure the available columns, there is a column named "SL" or "SLT".  If you select that column to be available in your view then you will see the indicator dots made available.  These will alter in colour based on the current state of the service level timers you have running against the requests.

    Hope that helps,

    Kind regards,

    Dave.

     image.png

  2. Hi @Rashid.Ahmed

    I've still not been able to fully replicate locally but I have a suspicion it could be down to the fact the request was raised out of working hours and then escalated immediately before any time elapsed.  I'm just trying to recreate that scenario to see if I can confirm whether that is the reason for the resolution time being incorrectly reset.  Will let you know when I can confirm or not.

    Kind Regards,

    Dave.

  3. Hi @Rashid.Ahmed

    It does look incorrect but its pretty hard to confirm from the screenshot, sometimes changing an SLA after a target has already been missed etc can result in this view for example. 

    If there has not been an SLA change to cause this scenario, if you have the "Incident Management Full Access" role you should be able to click on the blue button under "Service Level" to open the SLA update popup.  To the bottom right of the popup there is a diagnostics button which will show a list of the primary SLA actions e.g. pause/resume etc.  It might be worth checking that to see if that shows when the pause and resume took place and when the resolution/fix target was marked to see if that highlights any reason for the above.

    Kind Regards,

    Dave

  4. @Michael SharpI've just reviewed this and can see the reason. 

    To clarify, the h_withinresponse value (and h_withinfix value) are only set when the target is confirmed as being within or outside of the target time.  This has always been the case and continues to be so.

    Regarding your question on this request, if I read the screenshot correctly, the target response time was 12:05, the target was missed and then at 12:06 the SLA was changed which altered the time to an hour ahead.  In this scenario because the target had been missed at the point at which the SLA was changed, we set the h_withinresponse to 0 hence why it will not be appearing in the results.  If the SLA change was made before the target time then the value would have remained as null.

    Hope that clears it up,

    Kind Regards,

    Dave

  5. @Paul Alexander

    I've reviewed the code and currently months are as you say just being determined as a 4 week period, this is likely just a legacy choice due to ambiguity over what is defined as a month e.g. 28 Days in Feb/31 Days in March etc.

    I'll make an enhancement to this flowcode so that when you are defining months and we are not working against a working time calendar, we will treat "a month" as the same day in the following month etc.. so in your example 26th Feb will become 26th August, however there will of course be some exceptions e.g. adding 1 month to Jan 30th with result in March 2nd rather than a non existent February day.

    All of the datetimes are calculated and stored in UTC and formatted in the UI according to your regional settings, so the value is not one hour ahead in the database it is just being displayed as one hour ahead due to being in BST at the date in August.

    As an alternative until this is available you could:
    1.  Apply a number of days e.g. 182 days for 6 months or any of the smaller time denominations as @Victor suggests above (accepting the calendar day may not match)

    2. If you have any way to make the exact date available to the BPM at that point (e.g. a date selected custom field on a request) then you can pass in an exact date to the "On Hold Until" parameter of that flowcode which allows you to set the exact datetime.

    Regards,

    Dave.
     

  6. Hi @Jeremy

    Just wanted to check if you are still experiencing this problem?  Checking the error, the only reason it would likely occur is if the ID value of the service was not sent when it tried to do the update... so just wanted to check if something had not refreshed correctly after you added the field etc. or if the issue has persisted.  If you still have the problem, if you could outline the steps you took to encounter the error and we can see if we can replicate.

    Kind Regards,

    Dave.

×
×
  • Create New...