Feature Request: Use date field as SLA start time (instead of state transition)

Issue #110 resolved
Anonymous created an issue

SLA relevant actions are not synchronously in jira and the real world

Motivation: Some of the SLA relevant time stamps are not linked to synchronous jira status transitions

Example: For critical issues customers are required to call our 24/7 stand-by staff by phone.
Our Staff will then immediately start working on the problem until the system can be restored (e.g. by providing a workaround).
Thereafter the issue will be recorded in our jira for documentation. The issue will remain unresolved until a final solution is provided.

=> So the status transition to New will be considerably different from SLA relevant start time (time of customer phone call)
=> The same applies to the time when the system is restored. Actually there always passes some time after the workaround is in place, as the customer needs verify/acept the workaround. But for SLAs the time of fix should be considered, not the time of approval.

Possible Solution:
- Add a configuration option for the TTS "From Status" to use a selectable date field of the issue as SLA start time
- Add a configuration option for the TTS "To Status" to use a selectable date field of the issue as SLA end time
- Updates on the values of any of the above mentioned date fields should trigger a recalculation of the related SLAs
- Configured "Pause Status" should be taken into account, but only between the SLA start time and SLA end time
- It should be possible to define SLAs with "From Status" as date and "To Status" as transition (and vice versa)
- It should be possible to define SLAs with both "From Status" and "To Status" as date

Comments (15)

  1. Jóhann B. Guðmundsson

    What's he requesting here is somewhat silly and would be implemented via Frozen transaction in status workflows called "Workaround Implemented" then you would have two measurements one that measures the acknowledgement and the implementation of the workaround and another for "total" sla for the time the fix was properly implemented anyway since you are working on this take into account Issues #32 and #111 which are request for "SLA negotiated time" and are similar in nature like what's being requested here ( except you are only dealing with single selectable date field and calculate the sla resolution against that )

  2. Tuncay Senturk [Snapbytes] repo owner

    Hi Johann,

    It may be confusing but I'll try to make things clear.
    Some clients start working with a problem before the issue is created. For instance, they have an urgent issue and start working on it, and the issue creation takes place later.
    In this scenario, they want to set a custom field which will indicate the actual start of the SLA (rather than a status).
    As an example :
    - Problem arrived at 12:30
    - Developer started working on the problem at 12:45
    - Issue was created at 13:00
    Currently, TTS only starts SLA at 13:00, but client wants it to be started at 12:30
    Here, in this issue, reporter wants to set a date custom field in which the actual starting time of the SLA will be stored, and SLA will be calculated accordingly.

    Same for SLA End time, they want to set actual end time to a custom field and want TTS to calculate SLA data according to this field, not a target status.

    I hope I was clear
    Tuncay

  3. Jóhann B. Guðmundsson

    Yes I understood that and the clients expectations is that the issue is created immediately which should happen when the customer contacts the service desk or whomever the customer contacts as in they should create the issue ( while talking to him on the phone or online ) or it gets created via email when he sends in anyway the SLA End time is basically the same as SLA negotiated time, the only difference being for sla negotiated time ( Issues #32 and #111 ) you calculate the sla of the issue against the original create date of the issue not some arbitrary date set by another custom date field so you need to support calculating the second field against the original created date as well as against some custom date field and then you can close issue 32 and 111

  4. Jóhann B. Guðmundsson

    Here he's requesting for "live" calculation based on the new custom date field values either from the "new" create date or the "new" end date ( which is the same as target date in the terms of sla negotiated ) so you need to recalculate everything as changes are made to those..

    Assuming how you would implement this is that you would create a custom field of "Date Time Picker" call it "SLA Create Time" and you would create another custom field of "Date Time Picker" and call that one "SLA End Date" then tell TTS via configure that it should calculate the sla between those two custom fields if they are set.

    For SLA negotiated you would create a single custom field of "Date Time Picker" and call that one "SLA Negotiated " and calculate it against the original create date of the issue not another "Date Time Picker" custom field.

  5. Tuncay Senturk [Snapbytes] repo owner

    Absolutely, with a small difference.
    - SLA Start Date will be configurable and user will select any of date custom field in his JIRA instance.
    - SLA End Date will be same as "SLA Start Date"
    - Both fields are optional, so it is not mandatory to select both of them. I mean SLA will be able to start with a date field and end with a status. And likely, SLA can start with status and end with SLA End Date.
    - SLA Negotiated is part of #111 and will not be implemented within next release.

    Tuncay

  6. Log in to comment