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

[Jeremy Wood]

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)

[Andrey - Guenov Labs]

Real options here, roughly native → app:

1. 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.
2. 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.
3. 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.
4. 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.

[Brant Schroeder]

@Jeremy Wood The easiest way to ensure that they do not loose insights into the work item is to Clone it and leave the JSM work item in place.  You can then create an automation that will move the status of the JSM work item and even provide updates based on the information of the Jira work item in the project.  I have done this in the past at a different company that I worked at and it worked well.

[Jeremy Wood]

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?