Time to First Response SLA - Sometimes it works and sometimes it doesn't?

[Kylie Ham]

I have two SLAs set up for my Jira service project. At first, it appeared they were both running smoothly. However over the last couple weeks I have noticed that sometimes the SLA will capture and other times the SLA will keep running even though the finish time condition has been met. 

For more context the Time to First Response SLA is set up with the following:

Start counting when... Issue created

Pause counting when... none

Stop counting when... Comment: For Customers

I understand a lot of people run into the issue around comment for customers because sometimes people have the service desk customer role in the project so the SLA won't count when they comment. I recognized that early in the process and none of my project users have that role anymore. I thought the SLA was fixed after that, but I still run into the issue of sometimes when we comment the SLA will stop and sometimes it will never stop even though there is a lot of back and forth within the ticket. There seems to be no reasoning behind why it sometimes works and other times does not. Please let me know if there are any other things I can try to solve this.

[Ramiro Fontes]

Hey @Kylie Ham @Rahul Pal not sure if you still have this issue, but, in case you do, check if the agent that created the comment isn't added to the "Request Participants" field,

I was having the same issue and noticed that the time to first response SLA ignores the comment in case it was done by someone added to that field.

[Cameron Bassett]

Has any one received a resolution on this yet?

[Kateryna_v_SaaSJet_]

Hi @Kylie Ham 

Sometimes resolving issues with the Atlassian team can take longer than expected. Therefore, if the problem is still relevant to you, I suggest you use the 30-day trial period of third-party apps as an alternative that definitely works every time.

For example, in the SLA Time and Report for Jira add-on (developed by my team, Start-Pause-Stop conditions are configured in one window with automation and SLA goals.

If you set something incorrectly, the application automatically shows you an error, preventing errors in the SLA setting process.

Try it, and you might like the app more than the built-in solution.

[Joseph Chung Yin]

@Kylie Ham -

Welcome to the community.  Your specific SLA configuration calls (based on your ask and information provided) out that when the comments is Public "For Customer" and then the SLA will stop.

Based on what you provided, it means that if issue comment is entered and it is set for "Internal" then the SLA will not stop.  Only when the issue comment is entered and shared with customer (meaning public comment) "For customer", then the SLA counting with be stopped.

So, please check your issue's comments type to further investigate on your end.

Hope this helps.

Best, Joseph Chung Yin

Jira/JSM Functional Lead, Global Technology Applications Team

Viasat Inc.

[Kylie Ham]

Yes I'm talking about situations where our comments are public for the customer and not internal notes. Once again sometimes the SLA will stop and sometimes it doesn't. Any other suggestions?

[Joseph Chung Yin]

@Kylie Ham -

For the specific SLA, once the SLA is stopped, then it will no longer be activated again.  Can this be the issue that you are facing?

Can you also reproduce the issue at will?  Lastly, please take a screenshot of the actual SLA configuration for us to take a look further?

Best, Joseph

[Kylie Ham]

Hi @Joseph Chung Yin 

The SLA seems to work fine once it has been stopped. Its the issue that sometimes even though someone comments, the SLA will not stop counting and will show we are overdue.

I have included screenshots below to help explain the situation further. The first screenshot shows when someone comments and the SLA shows as complete and stops counting. The second screenshot is also when someone comments (in this example my coworker commented on 6/27) and the SLA does not stop counting even though there was a comment before the deadline. The third screenshot is the configuration of the Time to First response SLA. Please let me know if you have any thoughts. Thanks!

[Joseph Chung Yin]

@Kylie Ham -

Thanks for the updates.  There seems to be two different SLA going on - One "Time to first response" and other one is"Time to triage normal ..." 

What is the configuration for the second SLA?  Your second image shows the 2nd one completed, however it never triggered the first SLA.

Please review both SLAs again as needed to determine what is the difference.

Best, Joseph

[Kylie Ham]

Hi @Joseph Chung Yin Yes we do have two SLAs going. However, the "Time to triage normal change" is independent from and not connected to the "Time to first response" in any way. They do not have any sort of "trigger" between the two of them. 

"Time to triage normal change" - is the below screenshot and has not had any issues whatsoever with capturing every time I assign an issue to someone.

Both SLAs start counting time from Issue created so they don't have anything to do with each other. The only issue I'm having is with the "Time to first response" which is why I didn't mention the second SLA.

[Joseph Chung Yin]

@Kylie Ham -

Again, thanks for your updates.  For your 2nd SLA "Time to triage normal change", does your team also adds a public comments back to the customers as a default process.  Or, it is optional.  In addition, do you have any automation setup where when when assignee is changed (after the issue creation), it adds public comment to the issues?

For the two issues that you listed as an example, the second one which failed to stop the clock for the 1st SLA, did you checked/verified that the initial public comment was made against the issue?

Based on your two SLA configurations, it did seem to setup correctly and should have triggered the clock to stop for the 1st SLA.

Best, Joseph

[Kylie Ham]

@Joseph Chung Yin 

Our internal process for handling requests is below:

1. Once a request has been submitted to our help desk, it is assigned to a member of our team. That is captured in the "Time to triage normal change."

2. After the request has been assigned, we comment back to the reporter to give an update. These are always public comments, which should be captured in our "Time to First Response" SLA.

As of now we do not have any automations set up in our portal. So there is never a public comment added unless we manually put one in.

Additionally, I have confirmed that on all the requests this issue is happening on, they have been public comments. I have tried to find some sort of pattern and its seems to randomly happen. We are having full blown conversations and back and forth comments between us and the reporter and it will still say the SLA hasn't been met. This is why I decided to post the question because there isn't any reason to when it works and when it doesn't. 

[Joseph Chung Yin]

@Kylie Ham -

Ok, at this time, I would recommend you to contact Atlassian Support (https://support.atlassian.com) for further assistance and troubleshooting.  They will be able to review the backend logs on your instance/process to further determining if there were any error in my opinion.

Hope this helps.

Best, Joseph

[Rahul Pal]

Hi @Kylie Ham 

Just checking in to see if you ever received a resolution for this issue. I am encountering an identical issue and since it has been more than a year I assume this must have been resolved. If yes, can you please share the solution? If no, then I will be raising a support request with the Atlassian support team.

Regards,
Rahul