Has there been any solution or workaround for this? 

Bula @justin.alex - any idea if there is a way to solve this? as opposed to the workaround where users have to remove themselves from reporter/particpants and comment and then add themselve back (if needed)?

Just noticed this today, and based on what I've heard from mmcmahon, it's all about Service Desk automations. Is the SLA timer mechanism the same, though?

sfbehnke pointed a valid point: on occasions, customers tend to include agent(s) name into their email and shoot it off to the Service Desk (which then creates a new request; with the customer as its reporter and the included agent(s) as the Request Participant(s). If the agent(s) don't remove themselves as participants - and places a comment - the SLA timer for Initial Response Time will never be met.

I've never thought of this bug ever, before stumbling upon it today. To close this off - and discuss of automations in the process - is rather (unless the mechanism for SLAs was derived from automations).

Nevertheless, I'll spread the word on JSD-3506. That should be an extremely helpful module for Automations.

I believe the original summary of this bug is correct, and that in fact this has not been fixed.

The original report and the comments on the issue all point at SLA events not being respected. The atlassian responses are all discussing Automation events. These are two totally different systems and these are two totally different problems! Furthermore, this is extremely common! Agents at all of my customers use SLAs like this; as call-centers. Some customers intake 50% requests via phone call. Some customers are pure call-center, 90% phone intake.

As I understand it, we have the following scenario – 

Configuration

1. Create a new Service Desk, it doesn't matter, any default does fine
2. Create a new SLA metric
   • Name: Time to first response
   • Start event: Issue Created
   • Pause event: none
   • Stop event: Comment: For customer
3. Set the goals to anything, the default is fine

Scenario A

Story time

An aspiring Agent gets a walk-up request - their busy Customer needs their password reset! The Agent performs the job johnny-on-the-spot and the customer walks away, happy and able to work. Way to go Agent! The Agent thinks, "Hey, I should log this job!" They open the portal, log a password reset, but they leave the reporter as themselves. After all Customer's request was quite simple, no need to bother them with an email. The Agent immediately presses Resolve this issue and leaves a quick comment, to fulfill the SLA. It doesn't work. They try again; nothing. A better, more attractive Agent comments on the issue. Ahh! There we go, SLA achieved!

Summary

• An Agent creates a request and leaves the field On Behalf Of set to themselves.
• The request is created and the Agent is the Creator and the Reporter of the issue.
• The Agent immediately makes a public comment on the issue in order to fulfill the Time to first response SLA.

Expected results

The Time to first response SLA STOPS, a successful SLA metric.

Actual results

The Time to first response SLA continues ticking indefinitely.

Reproduction rate

100%

Scenario B

Story time

The IT Manager, the lovely Mitch Davis, helps out by logging issues in his teams Service Desk. This top Agent has a major request to log – The entire HR staff just personally informed Mitch that they had decided to move across the street into a new building and needed their computers hooked up by Friday morning (It was Thursday, 4:59pm). Mitch shouted out to his team,

"Oh boy! It's going to be a long night this time!"

All of the Agents groaned and many of them pulled out bottles of alcohol. Mainly whiskey. 

Mitch Davis decided to log the request immediately – He opened up the portal and logged the fifty desk-move requests, setting the reporter to each customer so they can be informed of their new details. 

The hours tick by, one by one each desk and 'puter is moved to the right spot. One by one, the legendary Mitch Davis presses Resolve this issue and informs the employee of their appropriate details. "Have a great day!" he writes.

After a hard nights work, Mitch looks back at his huge pile of requests. Wait, what's that? The SLA is still ticking on some issues? Mitch goes back to these five to ten issues – He comments on them again to no avail. He turns to his nearby Agents with a tear in his eye. The Agent knows, he comments on the request for Mitch. There we go – SLA achieved!

Summary

• An Agent creates a request and changes the field On Behalf Of to their Customer.
• The request is created and the Agent is the Creator and the Customer is the Reporter of the issue.
• The Agent immediately makes a public comment on the issue in order to fulfill the Time to first response SLA.

Expected results

The Time to first response SLA STOPS, a successful SLA metric.

Actual results

The Time to first response SLA continues ticking indefinitely.

Reproduction rate

15-30%

Hi vshort

I have investigated this further, and the reasons for the default Automation blueprints, being this way, is that a user can really only be in 1 role (either an agent or a customer) at any 1 time.

There is a workaround, however, and that would involve modifying the Automation rule for the transition, so that:

• IF status is Waiting for support and User is an agent (changed from User is not a customer) THEN transition

The side-effect of this, is that then the agent could take on 2 roles for the same issue. So if they comment above, the transition to Waiting for customer would happen. But if they then comment again, it would transition back to Waiting for support. This may not be a problem in your situation, but worth knowing before make the change.

Also, in regards to the potentially bigger issue, I have raised JSD-3506 as a suggestion to remove someone from Request Participants through Automation, and would encourage you to add any further details to the issue, as well as vote if it might be of interest to your scenario.

Additionally, if agents are raising requests on behalf of other users, and potentially using email to do this, then JSD-1462 may also be of interest.

Regards
Matt

Hi Matthew

In my example above, if the Customer knows which Agent will be dealing with their ticket, then it makes sense to cc them in the initial email as the Agent can then pick the ticket up quicker. It will be impossible to enforce that no-one should do this, plus it could slow down resolution times as the Agent would have to wait for our helpdesk team to assign the ticket to them before they know it exists.

An alternative is to inform all of my Agents to remove their name from the Request Participants field as soon as they receive the issue, else they won't be able to stop the 'Time to First Response' SLA and they won't receive internal notifications. Again, there is no way to enforce this, so Agents may end up missing important updates and going over SLA without realising it.

Regarding this comment in JSD-3390:

The default behaviour of Servicedesk works in this case as intended and here is the reason why. If you are a customer on a service desk you want to have the experience as a customer. The behaviour should not be influenced by the fact that you are an agent as well or not. This is why we prioritise the fact, that you are a request participant.

Surely the Agent status should be prioritised above the Customer, else the Agent could be missing out on receiving important information and performing essential steps in the process without even knowing it.

Kind Regards,
Vikki

Hi

This is a variation of JSD-3390, which contains a good description of why the rules work this way.

When the agent has been added to one of the customer roles (reporter, request participant) they will then become a customer, and not an agent.

So since the automation rule has the condition, "User is not a customer" it will not trigger, since the agent is the reporter (therefore a customer).

Hope this helps to explain why it works the way that it does.

Regards
Matt
JIRA Service Desk developer

Hi Matthew McMahon

This has been raised off the back of a ticket I raised relating to "Time to First Response", but the concept is the same for "Time to Resolution".
In answer to your question, I believe the SLA should stop when the Agent adds a Comment:For Customer to the issue (no matter whether it transitions to "Waiting for Customer" or not) as the two "Stop" entries in the SLA configuration should work independently of each other.
Note: We have disabled the automation rule that transitions the issue to "Waiting for Customer"/"Waiting for Support" when a comment is added because many of our Agents can also raise issues as customers, so the "User is a customer" and "User is not a customer" checks in the automation rule didn't produce the desired result (it would make more sense to have conditions saying "User is Reporter" and "User is not Reporter", but that is another discussion altogether!).

An additional thing that wasn't mentioned by Atiqah when raising this issue is that the same thing happens if the Agent is a Request Participant on the issue. So, for example:
1) Customer1 sends an email to helpdesk and Agent1 is copied in
2) Agent1 is automatically added as a Request Participant
3) Agent1 comments on the issue to inform Customer1 that they are dealing with the issue
4) The "Time to First Response" SLA should stop, but it doesn't

Thanks
Vikki

Hi nroslan

From the looks of the screenshots, after commenting on the issue, the status is still "Waiting for support", so it never transitioned status automatically, and therefore the SLA would not update.

ezhang what is the expected behaviour in regard to automation when the reporter is also the agent, and comments, auto-transitioning the status?

Thanks
Matt