Are you not supposed to share SLA field between multiple projects?

[KC Wong]

I created Project #1. It uses issue type "Domain" and has a SLA named "Renewal SLA". It starts at "New" and stops at "Closed" or "Renewal". In its automation rules I can read the SLA value using {{issue."Renewal SLA"}}. 

Then I created Project #2. It shares the issue type "Domain". When I go add SLA, the interface prompted me to reuse "Renewal SLA", so I did. It starts at "To Be Confirmed" and stops at "Renewal" or "Closed". 

But Project #2's automation rule fails to read SLA value using the same {{issue."Renewal SLA"}}. I can see the SLA displayed in the interface, but automation rule will get a blank value. If I export the issue to CSV, I can see the SLA field value. 

I tested by creating a manually triggered automation rule to print {{issue."Renewal SLA"}}. It works on Project #1 but not Project #2.

I tested again by creating a brand new SLA for Project #2. This new SLA I can print the value in automation rule.

So what's happening here, are SLA fields not supposed to be shared across projects? 

[Alina Kurinna _SaaSJet_]

Hi @KC Wong 

From your test, this does not look like a configuration mistake.

Jira Service Management does allow you to create an SLA by entering a new name or choosing an existing one, so your expectation is reasonable. If the UI offers to reuse "Renewal SLA", it is fair to assume that the field should behave consistently across projects.

But based on what you described, the problem seems to be this:

• the SLA value is visible in the interface
• the SLA value is present in CSV export
• the same smart value works in Project #1
• the reused SLA field returns blank in automation for Project #2
• a newly created SLA in Project #2 works correctly

So I would not read this as “shared SLA fields are definitely unsupported.”
I would read it as “reusing the same native SLA field across projects does not appear to behave reliably in automation.”

Normally, SLA smart values can be accessed with {{issue."Renewal SLA"}}, and Atlassian also documents using the custom field ID. Since you already tested both, and the rule is manually triggered, this seems less like a timing issue and more like a platform limitation or bug.

My practical recommendation would be:

• if automation is critical, avoid relying on one reused native SLA field across multiple projects
• create a separate SLA per project instead
• and raise this with Atlassian support, because your expectation is valid and the current behavior does look inconsistent

If your actual goal is to manage one SLA model across multiple projects more deliberately, that is where a dedicated app can help more than native JSM. For example, SLA Time and Report for Jira has an SLA Grid for monitoring SLAs in one place and supports tracking SLAs across multiple projects, so you are not depending on reused native SLA field behavior inside Jira automation.

Hope this can help!

[Hana Kučerová]

Hi @KC Wong ,

I believe your configuration is correct and the automation should work in the second project.

Have you tried to use {{issue.customfield_xxxxx}} instead of SLA name? 

I suggest to ask Atlassian directly (create support issue) and let's see if this is a bug. 

[KC Wong]

Yes, I tried using custom field ID, same result. Verified there's only one custom field with name "Renewal SLA". 

While exported issue CSV contains a value for the SLA field, Rovo seems to think it's actually absent, hence {{issue."Renewal SLA"}} gives me blank.

No idea how to solve it, for now I've settled with using a new SLA and naming it differently. 

[KC Wong]

To begin with, this whole thing about custom field names being non-distinct and still used as a reference is such a mess. 

Then you have people setting up multiple custom fields with same name (and by default, in global context). Then the UI to select fields to add to a screen only shows you the name and nothing else. You'll see 3 copies of "Start date" and good luck finding out which is which. 

[Benjamin]

Hi @KC Wong ,

Correct. SLA are not intended for cross-project. Each JSM project is treated separately like for each customer. Each customer you would have an agreed SLA with. That's why concept of going across doesn't add up since that would be like sharing SLA contracts across clients/ customers. You may find some options in the marketplace that may expand the capabilities. I would start looking into the Atlassian marketplace to see what's available around SLA extensions.

-Ben

[KC Wong]

But each JSM project has its own SLA settings - they are saved separately. One is from New->Renewal/Closed, one is from To Be Confirmed->Renewal/Closed. 

They are only sharing the SLA custom field - and this is enforced by the interface, it forces me to select the same SLA custom field if I want to use the same name "Renewal SLA". 

If I cannot share the SLA custom field, then I'm forced to invent new names for each project's set of SLAs. What if both projects want "Renewal SLA"? 

[KC Wong]

Also when you create a JSM project, by default you are given the Time to First Response and Time to Resolution SLAs. Aren't those shared already?