Keep Assets Flowing Across Teams & Projects in Jira Service Management

[#1]

Most IT service teams using Jira Service Management (JSM) are already familiar with the power of Assets. You’ve probably set up schemas for laptops, servers, or services, and you’re linking tickets to those Assets for faster resolutions.

But what happens when work leaves your team?

The Challenge: Assets Don’t Travel

Within a single JSM project, Assets do their job well. But many teams run into the same challenges when tickets are escalated:

• Assets are trapped within a single project or instance.

• Context is lost when a work item moves to a vendor or development team.

• Reports break when bugs span multiple systems.

In other words: Assets don’t travel with the work item.

First-Level vs. Second-Level Support: Where It Breaks Down

Here’s how most IT support is structured:

• First-level support gets a ticket from a customer and tries to resolve it. They also make sure to assign the right Assets, use automations to get tickets to the right team, and keep data up to date.

• Second-level support, usually consisting of more experienced developers from different departments, steps in when a work item is escalated.

The challenge: when the ticket crosses that departmental or team boundary and gets escalated, the carefully linked JSM Assets often get lost. The second-level team, usually working on a different Jira project or instance, no longer knows what’s affected, and the reporting back in JSM loses accuracy.

Syncing Assets Across Jira Projects or Instances With Backbone

That’s exactly where Backbone’s new Asset Syncing feature comes in. With it, Asset context moves with the ticket - whether the other team’s Jira project supports Assets or not.

• If both teams use Assets: Map Asset-to-Asset fields directly. Updates sync automatically in both directions, so everyone stays aligned.

• If the other team’s project doesn’t support Assets: Map the Asset name or label into a text field so context stays visible. Now they still see which product or team Asset the request relates to - even if they don’t have access to the original Asset field.

Example:

A customer reports a bug: “When I try to export a report to PDF, the file is empty.” The ticket is tied to the Asset “Export Module - Smart App.” The first-level service desk verifies the problem and escalates the ticket to the product development team, which works in another Jira project connected through Backbone.

Learn more about how to sync JSM tickets across different projects ->

Since both teams have set up Backbone to sync their work items and fields, including Assets,

• Everyone sees the same Asset in their respective fields.

• Any updates to the asset across both sides stay aligned automatically.

• The customer request gets resolved quickly and more accurately, leading to better satisfaction.

Why This Matters

• Reports stay useful: Dashboards and metrics don’t break when tickets leave your project.

• Escalations are smooth: No more chasing missing Asset info or using clunky Jira Automations to sync the info across Jira projects.

• Collaboration scales: Assets become a shared language across teams, projects, and even companies.

Your Turn

How do you handle ticket escalations today? Do your Assets make the journey, or do they get left behind?

Curious how Asset syncing could help your team? Watch the demo or share how you’re handling escalations today.

Drop your thoughts in the comments 👇 And if Asset silos are holding you back, check out Backbone’s new Asset syncing release.