Atlassian's recent decision to make Assets available directly in Jira Cloud, beyond Jira Service Management, opens up significant new possibilities for organizations using Jira.
For many Jira users, Assets may still be associated primarily with IT equipment, configuration management, or service management. However, Assets is much more than an inventory system. It introduces an entirely different way of organizing and managing information alongside Jira issues.
Understanding this distinction can fundamentally change how organizations use Jira.
Jira Issues and Assets: Two Complementary Ways to Manage Information
Jira issues are designed to manage work. They move through workflows, from creation to completion, representing tasks, requests, incidents, projects, or other activities.
Assets objects represent something fundamentally different: entities that exist independently of the work being performed on them.
Consider a company laptop.
Over its lifetime, that laptop might be involved in numerous Jira issues:
- A procurement request to purchase it.
- A service request to assign it to an employee.
- An incident reporting a hardware failure.
- A maintenance task to replace a component.
- A request to transfer it to another employee.
- A disposal request when it reaches the end of its useful life.
Each Jira issue has its own workflow and eventually reaches a resolution.
But the laptop continues to exist independently of those issues.
Its ownership, location, configuration, condition, and relationships with other assets may change many times throughout its lifetime.
The same principle applies to servers, software applications, business services, contracts, facilities, and virtually any other business entity.
This is where Assets becomes particularly powerful.
Instead of treating each Jira issue as an isolated record, organizations can use Assets to maintain a persistent representation of the entities involved in their business operations.
Jira manages the work. Assets manages the entities that the work relates to.
And the two can be connected.
Assets Is Not Just for IT
Although Assets originated in the IT service management world, its underlying capabilities are much broader.
Assets provides configurable object schemas, object types, attributes, and relationships that allow organizations to model complex business information.
For example:
IT Infrastructure
Track servers, applications, databases, network devices, environments, and their dependencies.
Human Resources
Model employees, departments, positions, equipment assignments, and organizational relationships.
Contract Management
Track contracts, suppliers, subscriptions, renewal dates, and associated business services.
Facilities Management
Manage buildings, rooms, equipment, maintenance responsibilities, and physical locations.
Business Architecture
Represent business capabilities, services, applications, organizational units, and the relationships between them.
These objects can be referenced by Jira issues without being confined to the lifecycle of any individual issue.
An organization can therefore use Jira for managing activities while Assets maintains the persistent business information those activities affect.
Atlassian's Common Data Model and Hardware Asset Management
Atlassian's recent introduction of the Common Data Model (CDM) and Hardware Asset Management (HAM) further demonstrates the potential of this approach.
The Common Data Model provides standardized structures for representing business entities and their relationships.
Hardware Asset Management builds on Assets to provide ready-made capabilities for managing physical equipment throughout its lifecycle, including procurement, deployment, maintenance, reassignment, and retirement.
What makes this development particularly interesting is that Atlassian is demonstrating how Assets can serve as the foundation for complete business applications, rather than simply as a database of configuration items.
And organizations are not limited to the predefined models provided by Atlassian. They can create their own schemas and relationships to represent their specific business requirements.
But What Happens to an Asset's History?
Once organizations begin managing persistent business entities in Assets, another important requirement emerges.
How do we understand what happened to those entities over time?
Consider the laptop example again.
Knowing who owns the laptop today is useful.
But what if you need to know:
- Who was using it six months ago?
- When was it transferred between employees?
- What was its configuration before a particular incident?
- Which attributes changed during its lifetime?
- What did the organization's entire hardware inventory look like at the end of last year?
Or consider a business application.
You might want to determine which business services depended on it before an infrastructure migration, or how its configuration changed between two releases.
These questions are different from tracking the history of individual Jira issues.
An asset's history extends beyond the lifecycle of any particular issue.
Understanding that history becomes increasingly important as Assets evolves into a platform for managing persistent business information.
How to Track Asset History in Jira Cloud
To address these requirements, we developed Assets History & Snapshots Reporter for Jira, an application built on Atlassian Forge and available on the Atlassian Marketplace.
The application complements Assets with three historical reporting capabilities.
1. Asset History — Understand What Changed
The Asset History report retrieves and presents changes to Assets objects, including:
- The object and attribute that changed.
- Previous and new attribute values.
- The date and time of the change.
- The author responsible for the change.
This makes it possible to investigate how an asset evolved over time, without having to examine individual objects one by one.
For example, you can identify when a server's configuration changed, when a laptop was reassigned, or how the attributes of a business service evolved.
2. Asset Snapshots — Reconstruct the Past
Sometimes knowing individual changes is not enough.
You need to answer a more fundamental question:
What did our assets look like on a particular date?
The Asset Snapshot report reconstructs the historical state of Assets objects at a selected point in time.
For example, you can:
- Reconstruct a hardware inventory as of the end of a financial quarter.
- Determine which employees were assigned particular equipment on a historical date.
- Review the configuration of infrastructure assets before a migration.
- Examine historical attributes of applications and business services.
- Produce historical inventory information for audits.
Importantly, these snapshots do not need to have been created or stored in advance. They are reconstructed from the available asset history.
3. Asset Snapshot Comparison — Discover What Changed Between Two Dates
The Asset Snapshot Comparison report goes one step further.
It reconstructs asset states at two selected dates and compares them to identify differences.
For example:
- Which assets changed ownership during the previous month?
- Which server configurations changed during a maintenance window?
- What changed in the organization's application portfolio between two dates?
- Which attributes of business services were modified during a migration?
- How did the hardware inventory evolve between two reporting periods?
Instead of manually examining individual change records, users can see the differences between two historical states.
All three reports support CSV and Excel exports, allowing organizations to perform additional analysis or incorporate the results into their own reporting and audit processes.
Scalability is a key design priority across our history reporting applications. Assets History & Snapshots Reporter follows the same approach, with performance tested against datasets containing over 1 million assets.
Supporting Atlassian's New Common Data Model
With Atlassian introducing new system schemas through its Common Data Model, compatibility with these structures is important.
We have tested Assets History & Snapshots Reporter with the following new Assets system schemas:
a_software_registrya_business_portfolioa_hardware_assets
Our tests confirmed that the application can discover these schemas, retrieve their objects, and report historical changes.
We have also verified historical snapshots and snapshot comparisons with the new system schemas, including the detection of actual attribute changes.
Because the application works with the underlying Assets data, the same reporting approach can support both traditional custom schemas and Atlassian's newer data models.
This means organizations adopting the Common Data Model or Hardware Asset Management can also benefit from historical reporting capabilities.
Security and Privacy — Runs on Atlassian
As Assets becomes a repository for increasingly important business information, security and data privacy become essential considerations.
Assets History & Snapshots Reporter for Jira is built entirely on Atlassian Forge and is Runs on Atlassian.
Its architecture has several important characteristics:
- No external servers: The application operates within Atlassian's infrastructure.
- No external databases: Customer asset information is not copied to third-party databases.
- No data egress: The application does not transmit customer data to external services.
- Atlassian-hosted processing: Data retrieval, processing, and reporting take place within the Atlassian platform.
This architecture is particularly relevant for organizations with strict security, privacy, and data governance requirements.
A New Perspective on Jira
Making Assets available to a broader Jira audience represents more than simply adding another feature.
It gives organizations an opportunity to rethink how they model and manage information.
Not everything belongs in a Jira issue.
Issues are excellent for managing work, coordinating activities, and tracking progress through workflows.
But many of the entities involved in that work have their own identities, relationships, and lifecycles.
An employee is not an issue. A server is not an issue. A contract is not an issue. A business application is not an issue.
These entities exist independently of the tasks, incidents, and requests associated with them.
Assets provides a way to represent them directly, while Jira issues manage the work performed in relation to them.
And once those entities are modeled in Assets, historical reporting adds another dimension: understanding not only their current state, but also how they have evolved.
That combination opens possibilities extending far beyond traditional IT asset management.
If your organization is already using Assets, or is considering adopting it now that it is available directly in Jira Cloud, historical reporting can provide additional visibility into your asset information.
Assets History & Snapshots Reporter for Jira provides object change history, historical snapshots, and comparisons between two dates, with CSV and Excel exports.
The application is built on Atlassian Forge, is Runs on Atlassian, and does not require external servers or databases.
Learn more on the Atlassian Marketplace:
Assets History & Snapshots Reporter for Jira
Disclaimer: Disclosure: I am part of the Simitech Ltd. team that developed Assets History & Snapshots Reporter for Jira.
![Photo of Petru Simion [Simitech Ltd.]](https://us.v-cdn.net/6038660/uploads/avatars/c7/df/nc7dfc3cdcefb50b8aef7269c429d3d29.png)