It looks like a small UI change. Spoiler: it isn't.
Assets used to be strongly associated with Jira Service Management. For a long time, it was only available when buying this app, or later, as part of a Service Collection package. This basically meant that, when we thought about Assets, it was help desk teams that came to mind.
For many Atlassian users, especially people outside service management, Assets was something they could safely ignore. I think I can even assume that, for many people, this won't seem like any kind of change. And yet…
Assets is becoming an Atlassian Platform app. The visible manifestation doesn’t seem like much: another app in the app switcher, a grey icon, separate administration.
But the underlying change is much bigger:
- Assets is being separated administratively from JSM.
- Its data can increasingly be used across the Atlassian platform (and by Rovo)
- Availability is expanding beyond JSM customers.
And this changes the role of Assets from a JSM extra into something closer to a shared business-data layer for the Atlassian ecosystem.
So what actually changed?
I see three main changes:
1. Assets are becoming available for almost everyone
Atlassian Cloud Platform apps come pre-loaded with every Atlassian cloud app or collection. These apps are accessible via the app Switcher.
That means that Assets are becoming available for almost everyone. With that said, Assets is being separated from Jira Service Management in Atlassian Administration. It means that it gets its own administration context, roles, and access - but we’ll discuss that more broadly below.
2. One small change in navigation, one giant change in the ecosystem
Atlassian increasingly talks about a connected platform rather than isolated products/apps. For that model to work, Jira issues and Confluence pages aren't enough. Organizations also operate around everything that we can call assets - people, systems, services, vendors etc.
Assets gives Atlassian a structured way of representing those business objects and feeds the Teamwork Graph.
Therefore:
Turning Assets into a Platform app makes strategic sense even if the Assets UI itself barely changes.
3. Assets data is moving into the wider Atlassian ecosystem
Assets objects are becoming part of the data/context Atlassian can surface across its ecosystem like Teamwork Graph and Rovo, Atlassian Search etc.
Rovo is especially worth calling out.
AI is only as useful as the context it has. Assets gives Rovo structured information about the actual things a business operates.
That makes Assets potentially much more valuable than a standalone CMDB/database. We’re essentially creating a place to store information about objects for the entire Atlassian ecosystem - whether we want to use it as a dictionary value for a field or to keep track of things that aren’t even related to our processes (e.g., a list of our offices).
What’s more, Atlassian says Assets objects are being woven into Teamwork Graph, and Assets objects can already appear in Rovo Search, with deeper natural-language functionality planned.
In other words, we're providing Rovo AI with an additional source of information to enrich the Teamwork graph - and, by extension, its responses to our prompts.
Who cares? Or rather - who should care? 🙂
- Existing Assets users and admins
The functionality isn't suddenly unfamiliar, but its organizational position is changing. Admins should pay attention to administration, permissions, roles, governance, who can see which data, who owns Assets at organization level and prepare training for new users.
The other topic is are your current schemas ready to become organization-wide data sources? A schema designed for five JSM admins is a different proposition when other teams begin discovering it through search/Rovo/Jira.
- Service Collection Standard customers
This is perhaps the easiest group to explain. Previously, they had a much higher barrier to effectively using Assets. The Standard package now includes 5,000 objects, meaning all users can access the product at no extra cost.
- Jira / Teamwork Collection users who have never cared about Assets
In my opinion, this group stands to benefit the most from the entire change. Paid Jira and Teamwork Collection customers now have included Assets allowances. Assets can represent much more than configuration items and be useful for almost any team. The combination of Assets + Jira + Confluence + Rovo potentially makes structured business information usable directly where people work.
“There is no better price than free”
“Free” isn't exactly the right term, but as part of your package, you get a brand-new app that can be successfully used for a wide range of purposes. For many customers, the barrier to trying Assets has effectively disappeared.
What new opportunities does this create?
- Move away from spreadsheets and other databases - now your data that sits in them can be moved into one system connected with Atlassian Cloud. This is an opportunity to review your existing sources and maybe decide whether to migrate your previous CMDB.
- Non-IT use cases - People/HR operations, Vendor and contract management, Facilities, Sales - I'm sure many users would be happy to use these features if only they knew about them.
“But Wojciech, broader access creates a governance problem”
Yes, it does. Making Assets easier to access is positive - provided the data is actually ready for wider consumption ❗️
→ Schemas created historically for one team may use cryptic names.
→ Relationships may make sense only to the original admin.
→ Ownership may be unclear.
→ Old/stale data becomes more problematic if Rovo/search exposes it to more people.
More visibility makes governance more important, not less. We need to prepare our instances for this change in advance.
What is already clear
- Assets is positioned as a standalone Atlassian Platform app.
- Assets is rolling out as a platform app starting from September 2026.
- Service Collection Standard includes Assets.
- Atlassian is integrating Assets data with Teamwork Graph/Rovo.
- Assets has standalone administration/governance work underway.
- There are limits of some products:
- Jira Standard/Premium/Enterprise: 1,000 objects.
- Teamwork Collection: 5,000 objects.
- Service Collection Standard: 5,000.
- Service Collection Premium: 50,000.
- Service Collection Enterprise: 500,000.
As for the other collections and products, we do not have that information.
A few additional restrictions worth noting:
- Technical limit of 3 million objects per site (and a global limit of ~10 million, 20,000 in the Services schema)
- The allowance is calculated at the organizational level (aggregating sites into a single pool), and Enterprise is an exception - the allowance is per subscription, not per site. This significantly changes planning for larger customers.
Usage-based pricing
Atlassian is introducing usage-based pricing for objects that exceed your plan's limits. Your usage is the number of objects in all schemas on each site, excluding system schemas. Each site can contain up to three million objects, and the total limit is based on the plans for the entire site.
Does it apply to the Data Center as well?
Which means no.
Conclusion: stop thinking of Assets as a JSM feature
Because it’s much more now!
The grey icon is a symptom of a big change. More use cases, a low barrier to entry, new data for the teamwork graph. Assets change is the highlight of the approach that Atlassian has been promoting for some time now - a single source of truth for everyone.
Extra checklist for admins - how to prepare for the changes
Access and roles
Check:
- Who should administer Assets?
- Who should edit objects?
- Who only needs to consume/search the data?
- Are groups and roles still appropriate?
Atlassian has specifically moved Assets governance into Admin Hub and introduced Assets-specific controls.
Schema visibility
Review:
- Which schemas should be broadly discoverable?
- Which contain sensitive/internal information?
- Whether current permissions match the new audience.
Schema naming
Check whether names make sense outside the original team.
For example, avoid internal abbreviations that only three admins understand.
Data ownership
For every important schema, identify:
- business owner,
- technical/admin owner,
- who maintains data quality,
- expected source of truth.
Data quality
Check:
- stale records,
- duplicates,
- missing owners,
- inconsistent status values,
- incomplete relationships.
User guidance
Prepare a lightweight explanation:
- What is Assets?
- What should employees use it for?
- What shouldn't they put there?
- Who should create schemas/objects?
Documentation
Update:
- screenshots/navigation,
- admin documentation,
- access instructions,
- onboarding,
- internal references that still say “Assets in JSM.”
