Assets in Jira Are Persistent Objects — Not Just Fields in Issues

Petru Simion [Simitech Ltd.]

In Jira Service Management, Assets are often treated as “just another field” attached to an issue.
That mental model is convenient — but fundamentally wrong.

Assets are persistent objects.
Issues are temporary workflows.

And confusing the two is the reason many teams struggle with visibility, accountability, and traceability once their asset usage grows beyond a single project.

---

Issues Are Ephemeral. Assets Are Not.

An issue has a lifecycle:

• Created

• Worked on

• Transitioned

• Closed

Eventually, it disappears into history.

An asset does not behave that way.

An asset:

• Exists before an issue

• Is referenced by many issues

• Moves through multiple workflows

• Changes ownership, state, and attributes over time

• Continues to exist long after any single issue is closed

Treating an asset as something that “belongs” to one issue is a category mistake.

---

Assets Live Across Projects and Workflows

In real-world setups, the same asset is often involved in multiple independent workflows, for example:

• A device is received by a procurement project

• It is repaired via a maintenance project

• It is deployed through a field operations project

• It is later audited by finance or compliance

Each of these workflows:

• Lives in a different project

• Has its own statuses

• Has its own transitions

• Has its own purpose

Yet the asset itself is the same object throughout all of this.

The issue changes.
The asset persists.

---

The Missing Perspective: Asset-Centric Thinking

Jira is issue-centric by design, so most reporting answers questions like:

• Which issues are open?

• How long did a ticket stay in a status?

• Who transitioned a task?

But asset-driven teams eventually need different questions answered:

• Where has this asset been over time?

• Which workflows interacted with it?

• What attributes changed, and when?

• Who was responsible for it at each point in time?

• What state was it in during a given incident or audit window?

These questions cannot be answered by looking at a single issue — or even a single project.

They require asset-centric history, not issue-centric history.

---

Assets Have State — and State Has History

Assets are not static references. They have:

• Attributes that evolve

• States that change

• Relationships that come and go

• Ownership that shifts between teams

If an object has state, then state history matters.

And if an object outlives workflows, then its history must also exist independently of those workflows.

---

Where This Breaks Down in Practice

This gap usually becomes visible only when something goes wrong:

• Teams argue over who had the asset last

• Audits fail because historical state cannot be reconstructed

• Investigations stall because attribute changes lack context

• Ownership transitions are unclear

• Compliance evidence becomes manual and error-prone

At that point, teams realize they need visibility beyond the current asset state.

They need to query, search, and export how assets changed over time, across projects and workflows.

---

Bridging the Gap: Making Asset History First-Class

This is exactly the gap that Assets History Reporter for Jira , one of the apps released by our team,  was built to address.

Instead of treating asset history as a per-object detail hidden in the UI, it makes asset changes:

• Searchable across schemas and object types

• Filterable by attribute, author, date, and change type

• Independent of any single issue or project

• Exportable as structured data (CSV) for audits, analysis, and reporting

In other words, it treats assets the way they actually behave in real systems:
as persistent objects with traceable history.

---

Final Thought

If your assets:

• Move between teams

• Participate in multiple workflows

• Change state over time

• Are reused across projects

…then treating them as transient issue metadata will eventually break down.

Once assets become shared, long-lived objects, asset-centric history stops being optional.

It becomes foundational.

 

Halina Cudakiewicz_Deviniti_

This is a really helpful way to explain why Assets break down when they’re treated like “just another field.”

A very common example of this is equipment assignment. During onboarding or offboarding, the asset (laptop, phone, license) already exists and lives longer than the ticket. The request is just the workflow around it.

The problem is that portal users or approvers often need to select or confirm the exact asset during the process. When that happens via comments or manual updates, ownership and history quickly fall apart. Solutions like Actions for JSM let teams tie those moments to the workflow (selecting a specific asset, assigning it to a user, and later listing everything to be returned) while keeping the asset as the persistent source of truth.