How do companies manage keeping customers up to date on Jira Projects?

Question

Hello Atlassian Community,

My company has both Jira and Jira Service management in our environment. JSM is used as our main ITSM tool and is how customers reach out to the IT teams for their needs. Jira is used for individual teams (Infrastructure, ERP, etc.) to track long term project work they are completing.

This works well, except for when a custom requests something in JSM, that needs to be converted into a project as it is a large ask. We move the ticket to a Jira project and the customer losses visibility to it.

I'm curious, how do other companies handle these types of situations? 
How do you use Jira for tracking project work internally, while still being able to provide visibility to a customer? (Something that seems to be only possible in JSM)

Alina Kurinna _SaaSJet_ · Answer

Hi @Jeremy Wood

For the SLA part specifically, there are a few ways to make this setup easier to manage.

I work at SaaSJet on SLA Time and Report for Jira. If the same SLA rules need to apply across several Jira or JSM projects, you can use a Multiple-Projects SLA instead of maintaining separate SLA configurations for each project. This is exactly what the app supports, which helps simplify SLA management across multiple projects.

For the customer-facing JSM request, you can define the SLA around the lifecycle that matters to the customer, for example, when the timer starts, pauses, or stops based on statuses or other Jira fields.

Another useful part of this kind of setup is proactive SLA management. You can notify responsible users or groups before an SLA is breached and configure automated actions when a goal is exceeded, for example, escalate by changing the assignee, priority, or status, or send notifications via Slack, Microsoft Teams, or directly in the ticket. You don’t need to build this separately with Jira Automation, as these actions can be configured directly in the app, which also helps simplify the overall process.

This way, linked Jira items can still handle the internal work, while SLA tracking, notifications, and escalations help ensure that customer-facing commitments don’t get lost as work moves between teams.

Andrey - Guenov Labs · Answer

Real options here, roughly native → app:

* Clone-and-sync (what Brant suggested) — clone the JSM item into the Jira project as the customer-facing artifact, then use Automation to push status back onto the clone (issue transitions → transition the clone; comments → mirror them). To your specific questions: SLA stays on the JSM item, since that's still the record of truth the customer sees. For scoping across multiple projects, one company-managed rule (if your Jira projects share a scheme) beats per-project rules for maintainability. For narrowing which linked tickets to touch, tag the "live" link with a label or component on the Jira issue and scope your rule's JQL to that — don't rely on link-type alone, since not every epic traces back to a JSM ticket.
* Anonymous/guest access to the Jira project — technically possible, but a real security hole for anything customer-facing. Most teams rule it out for that reason.
* A scheduled Automation email straight from the Jira project to the customer — cheap, no clone needed, but push-only and reads like a ticket dump unless someone curates it.
* JSM Status Pages or Confluence + a charts app — more setup, still Jira-shaped for the reader.

What none of these solve: the customer still has to interpret ticket-shaped information, or your team maintains a second live object just to have something plain-language to point at. If what you actually want is "the customer sees one page that says where things stand," that's a different job than keeping two Jira objects in lockstep.

Full disclosure — that's the exact problem I ended up building for (verdict-first, plain-language project status, for people who'll never touch Jira). It's live on the Marketplace: https://marketplace.atlassian.com/apps/2024439873. Happy to say more if useful — but for your JSM-escalation case specifically, Brant's clone-and-sync is probably still the right native path if it needs to behave like a JSM object throughout.

Jeremy Wood · Answer

That makes sense, but does open a couple of questions.

1. How do you manage SLA's on the JSM ticket?

* I can think of several ideas but they all feel clunky so before i list them out have you found a way that works well for you?

2. As we have multiple Jira projects for each team, would we have to create the automation rule in each project to update the JSM ticket?

3. Digging into the automation, how do control you when to run the automation and what tickets to update?

* What i mean by that, is i know i can create an automation that when a comment is added to an epic, add that same comment to all linked tickets. But not every linked ticket will be the JSM ticket, and not every epic will have been created from a JSM ticket. How do i narrow in on only updating these tickets?