SLA - Time to first Response SLA not affecting customer source or API requestchannel type issues

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

Juuso Ikonen

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.