SLA - Time to first Response SLA not affecting customer source or API requestchannel type issues
Asked by Juuso Ikonen:

Hello!

I've tried to fix our SLA's myself, but am now completely out of ideas. If anyone has any notion on what to try to fix this, I'd be grateful.

We have setup 3 types of SLA:s for our SD project. This is due to differing contracts and SLA timers.

This necessitates 3 differing time to first response SLA:s as well, called.

* Time to first response
* \<CONTRACT\> 1st tier Time to Resolution
* \<CONTRACT\> 2nd tier Time to First Response

Now, Time to first response has a ton of goals in it based in whether or not the customer has subscribed to extended service times and such.  
The two \<CONTRACT\> ones are mostly the same. 1st tier version is used 99% of the time.

**The problem**

The default Time to first response works normally as it should, no problems.

The problems are in 1st tier Time to First Response, which does not apply as it should on issues with either the Source-field set to Customer or request-channel-type set to API.  
When we create an issue via our customer portal ourselves the SLA works perfectly. The accounts used to test are either gmail accounts or test accounts from our own company domain.

Details from the SLA below.

**Goals:**

* Time: 30m
* Calendar: One created for this contract. Weekdays, 7-22
* Issues to display in JQL: labels in (CONTRACT_LABEL) AND (request-channel-type != email OR request-channel-type in (api, jira))  
  * Our contract does not allow SLA on email sourced issues, thus it's excluded.
  * request-channel-type allowed is either api (we use Refined for our customer portal) or jira itself. This is treated as source = phone.
  * Originally we used the Source field to determine if SLA's should apply or not, but it had the same problem as here.

Then it has the default No Target goal with the same calendar.

**Starts counting when:**

Entered Status: In Progress  
Entered Status: Open  
Entered Status: Waiting for support  
Entered Status: Work in progress  
Issue Created  
**Pauses counting when:**  
Status: Pending  
Status: Reopened  
Status: Resolution pending  
Status: Waiting for approval  
Status: Waiting for customer  
**Finisher counting when**:  
Assignee: From Unassigned  
Resolution: Set


Answers:
author: Juuso Ikonen
body: The problem is apparently a known one and pertains more to how we handle issues when they come in rather than in the SLA setups.

<https://jira.atlassian.com/browse/JSDCLOUD-3562>

Since this SLA stops counting when the issue is moved from unassigned -\> assigned, the first response SLA does not apply if assignment is done *before* applying the SLA. In this case the SLA was applied via label that an automation attaches after filling the Organization field with certain organization names. Usually this is done *after* assigning the case.

Workaround until JSDCLOUD-3562 gets done; apply org and label before assigning issue.


author: Juuso Ikonen
body: <https://jira.atlassian.com/browse/JSDCLOUD-3562>  
Found this while researching the problem. Can also now say that the SLA just disappears off of the issue when assigning it, even if it was there before.


Tags: cloud

jira-service-management

jira-service-management-cloud