Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Set up a SLA based on a custom field

Sabrina Boetzkes June 17, 2024

I am currently importing issues from an external system via CSV from a merger of 2 companies. These issues currently don't have a SLA so when I import them I don't want them to get an SLA. I have tried, based on a custom field where I can indicate for which product the issue is, to set up the SLA in that way the issue won't get the SLA. But even when creating a new issue, the SLA still gets into the issue. 

The main reason for my request is, I don't want to change all these imported issues manually when I do the final import. That will just take me too much time. 

Setup that I've made now:

The custom field is a field set up as a dropdown. In the dropdown I can choose 3 product types:

1. Current product (with SLA)

2. Product that is being imported (no SLA)

3. New product to be created (will have SLA later on when it is actually there)

Setting of the custom field:2024-06-17 16_23_53-Edit Custom Field - Details - Livits Jira.jpg

Setting of my SLA:

2024-06-17 16_25_45-Support 1e lijn - Service level agreements - Service project - Livits Jira.jpg

2024-06-17 16_26_33-Support 1e lijn - Service level agreements - Service project - Livits Jira.jpg

So when creating an issue and changing the product, it still has an SLA which, in my opinion with the settings above, should not be the case. 

Any ideas on how to solve this and make sure that this will work?

 

2 answers

1 accepted

0 votes
Answer accepted
Walter Buggenhout
Community Champion
June 17, 2024

Hi @Sabrina Boetzkes,

From your explanation, I cannot clearly derive what brings you to the statement that "it" still has an SLA. 

In short: if you specify a JQL filter to add target timings to your SLA, a box with that SLA target and a timer should be displayed on issues that match that filter. Issues that don't match the filter and don't get a target should not have the SLA target visible.

However, if you already had a calculated SLA on these issues and you changed the configuration afterwards, it may happen that old values still show. I am not 100% sure if this is still the case, but in the past SLA's on already closed issues (issues where the SLA timer had met its end state) were not recalculated when you change the configuration. Maybe this is impacting your specific use case?

If you are seeing data that seem inconsistent with your current settings and that cannot be explained through the points I mentioned above, you may consider forcing a recalculation of your SLA's on the issues you consider wrong. You might inspiration on how to do this in this support article.

Hope this helps! 

0 votes
Sabrina Boetzkes June 18, 2024

@Walter Buggenhout , thanks for your response. It made me realise that I have been approaching this whole thing from the wrong end. The issue should match the SLA and if it doesn't it doesn't get any. So I had to change this thing around and make sure that product type 1 matches the SLA completely and product 2 does not. 

Changed it in the settings of the SLA and now it finally works. So probably should have asked my question earlier as it took me quite some time to figure out. 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events