4 tactics for managing SLAs across multiple JSM projects

[#1]

You don’t need a stack of add-ons to run consistent SLAs across many Jira Service Management (Cloud) projects. Native JSM gets you most of the way—if you set it up with intent and test as you go. 

This short, practical playbook will show you how to standardize rules, align calendars across time zones, make status visible, and control pauses and handoffs.

          

           Juggling SLAs in many JSM projects? Follow these tactics and you’ll be (really) fine.

---

#1 Align calendars and time zones so SLAs mean the same thing

Goal: Make “2 hours” mean two business hours for every team, everywhere.

1. In each project, open Project settings → SLAs and click the calendar icon.
2. Add calendar → name it clearly (e.g., “Support EU CET”), pick the Time zone, and set Working days/hours.
3. In each SLA Goal, select the correct Calendar so the clock runs only during those hours.
4. Repeat across projects; keep naming, time zones, and hours consistent.

Read more about how to align regional team calendars to the client’s localization. 

⚠️ Heads-up: By default, SLAs run 24/7 unless a calendar is attached. If you change a calendar or SLA, JSM typically recalculates ongoing cycles only—closed issues usually won’t update. After edits, spot-check a few issues to confirm timers.

When you need retroactive accuracy:
If compliance or reporting requires recalculating historical cycles (including closed issues), a focused add-on like SLA Time Management can apply the updated logic and recalculate past timers where native JSM won’t.

---

#2 Standardize SLA rules across projects

Goal: Create one reference configuration, then replicate it safely.

1. In your reference project, go to Project settings → SLAs → Click the Calendar icon and Create a calendar.
2. Add SLA and its name.
3. Set Goals (by priority and/or using JQL). Attach a Calendar to each goal so timers respect business hours.
4. Order goals carefully. JSM evaluates top-down with OR logic.
5. In conditions, define Start, Pause, and Stop events using statuses and field changes that reflect your workflow.
6. Choose an SLA format display.
7. Open a few issues and confirm that the SLA panel displays the expected countdowns.
8. Replicate the SLA logic (copy and paste each field one by one) into other projects, then spot-check the behavior. 
9. In Filters use SLA-aware JQL for cross-project triage: remaining("2h"), breached(), paused().

⚠️ Heads-up: If two goals could match, only the first match counts—mis-ordering goals leads to surprising timers.

---

#3 Give agents and customers real-time SLA visibility

Goal: Make it easy to see “what’s at risk” without leaving JSM.

For agents: Add SLA columns to project queues

1. Go to your JSM project.
2. Click on "Queues" in the project sidebar and select the desired queues. 
3. In the Columns, look for your SLA names.
4. Choose these options from the dropdown menu.
5. Click Save.

Now your queues will display these SLA timers for each issue, helping agents quickly spot items nearing SLA deadlines.

For agents: Create cross-project filters to highlight risky issues

1. Go to the Issues menu in the JSM top navigation and select Search for issues.
2. Switch to Advanced search (JQL) if you are not already there.
3. Enter one of these SLA queries to find issues at risk:

• Issues with less than 2 hours remaining: remaining("2h")
• Issues with breached SLAs: breached()
• Issues with paused SLAs: paused()

1. To cover multiple projects, add a project filter to your JQL, for example: project in (PROJ1, PROJ2) AND remaining("2h").
2. Click Save as above the search bar, give your filter a clear name like “SLAs At Risk Across Projects,” and save it.

Adds-on: If you’re team wants to save time on setting cross-project queues, you can use solutions like Queues for Jira and JSM that allow users to gather issues from multiple projects and Customer Portals into a unified view.

For customers: close the visibility gap

⚠️ Heads-up: The customer portal and My requests views don’t show SLA timers natively—customers can’t see “time left” by default. Read more about this in another article in our series. 

Use SLA Time Management to display live SLA progress and time-zone-aware ETAs in the Customer Portal request view and in My requests (including integration with My Requests Extension for JSM). This keeps customers informed without back-and-forth communication.

SLA tracker in the request view on the Customer Portal

---

#4 Control pauses and handoffs with precise conditions

Goal: Pause when you’re truly waiting; resume as soon as work restarts—consistently.

1. Pair SLAs with Automation to keep handoffs clean. Go to Automation in Request management -> Create a rule:
   
   
   • Trigger: Issue commented
     
     
   • Condition: Comment by customer/agent
     
     
   • Action: Transition to the right status to pause/resume the SLA.
     
     
2. Track operational hygiene with SLA JQL: paused(), running(), remaining("2h"), breached().

⚠️ Heads-up: Copying pause logic into many projects is error-prone, and diagnosing “why did this pause?” can take digging.

---

Quick checklist

• Build one reference SLA config; replicate and spot-check across projects.
  
  
• Attach the right calendars to every Goal (no silent 24/7 timers).
  
  
• Create cross-project filters using remaining("2h"), breached(), and paused().
  
  
• Use Automation to transition on customer/agent comments and control pauses.
  
  
• Add time-saving solutions like SLA Time Management when you need a centralized SLA management, portal visibility for customers, and/or retroactive recalculation for accurate reporting.

What are your challenges and wins in managing SLAs across many projects? Drop them in the comments, and let’s discuss the patterns :)