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

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.

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.

@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.