I'm struggling with following situation that we are facing.
We need to create SLA reports that are not based on ticket status but that are based on time information that are added by custom fields which are standard date- and time fields.
Is there any way to make SLA calculations based on custom added standard time fields?
Background is that we need to be able to create incidents in the JIRA service desk tool where creation date is newer than the event of the incident but SLA must rely on the event of the incident and not on the creation date of the ticket.
I was using the search and couldn't even find a plugIn that was available for the cloud service.
Anyone any ideas?
Hi @Jens Niedrich,
I may be misinterpreting your question, but you seem to be saying that you create Service Desk tickets before incidents actually happen ("creation date is older than the event of the incident").
I assume that it is probably the other way around and that you run into a situation where tickets are created later than an incident actually occurs, but still want to report on SLA relative to the date of occurrence, rather than the creation date of the ticket.
If my assumption is right, you should consider the difference between the purpose of SLA to help your team determine what needs to be done first versus reporting on lead times from incident occurrence to resolution.
The SLA configuration is based on Jira events. The timer starts running at a given time (usually when a ticket is created), pauses when your SLA calendar says it should or when certain events occur and stops when the determined goal is reached. It cannot run when your ticket is not created yet and as such, you cannot build reporting on it that backdates to before the ticket was created.
Nothing stops you, however, from reporting on the dates you enter. It might e.g. be really interesting to investigate how often and how much time gets lost between the occurrence of an incident and the moment a ticket gets created for it. As that would be something you would want to eliminate.
For that purpose, you could use calculated fields and/or reporting add-ons that help you measure the time between different dates (and times) in the system.
Hi @Walter Buggenhout [ACA IT], thanks for your feedback. Your assumption is right and my wording indeed is wrong. The Incident happens and the JIRA ticket creation is happening at a later time. SLA needs to reflect the event of incident happening and not of ticket creation time.
The process is out of our control and we can't optimize ticket creation date anymore as JIRA is used as second ticket tool and the incident is being logged in another tool that sends an e-mail and we only can act on receiving this e-mail.
I'm looking exactly for a reporting add-on that is available for the JIRA service desk solution running on atlassian cloud as our JIRA is not running on premise.
Is there a tool that you can recommend? I couldn't find one in the atlassian market place.
Hi @Jens Niedrich,
Thx for the additional input! I think it still comes down to the goal you are after: do you want a traceable SLA that helps you solve issues on time (i.e. within preset SLA targets) or do you only want to report on lead times (for informational purposes).
In the first case, I would recommend you to implement a calculation on issue creation to set the due date for your issue, based on the incident date you somehow/sometime add to your ticket and the SLA rules want to apply. Scriptrunner can help you do that. Once you have this date filled out, you can prioritise your issues with service desk queues or a Jira dashboard.
In the latter case, you will probably still want to start from the first step, so you have an idea whether an issue is overdue or not. As soon as you have the date, you can report on your issues using standard JQL. You can always take your reporting up a notch by exporting the results or by using a reporting tool such as EazyBI.
To conclude, your use case remains rather unfortunate. If you really want to deliver quality service and meet SLA requirements, your targets should be within your area of control. If someone can forward you an email for something that needs to be fixed in 15 minutes (hypothetically) while the issue has been sitting in another system for 5 days (also hypothetically), how can they possibly expect you to deliver? So apart from the above, I would still have a look at how the process is defined and whether you cannot come to SLA targets for you, starting at the moment where you are able to take control (i.e. when the ticket is created).
Thx once more for coming back to me. Your conclusion is completely correct. For operational purposes we want (!) to use our JIRA to have a tool at hand that works for us best. The client does not want to use JIRA but we are enforced to provide SLA reports.
Client tool in deed does allow the scenario you just described. Fortunately our responsibility starts "only" when the mail from the other tool arrives. So based on the JIRA values we already have, we can provide relevant timings like Time to respond and time to resolve - but only for the parts of the process within our control. If we could add the time stamp of the incident event than we could provide SLA reporting for the whole incident - which is the more interesting value for the client.
To keep efforts for SLA reportings in acceptable numbers we will now create SLA reporting based of the JIRA information and will leave it to the client to create the more holistic reporting based on his tool.
Therefore I will mark this question now as solved
Thanks for your feedback anyways.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs