Atlassian Assets: One Schema or Multiple Schemas?

[Anna Kochura]

Hello everyone,

We are using Atlassian Assets for the first time and are currently planning to move all our IT assets to Jira.

We are struggling with the question of how best to structure our Asset schemas.

Would you recommend:

• One large Asset schema containing hardware, software, licenses, people, locations, etc.
• Separate Asset schemas for each asset type/domain, e.g. hardware, software, licenses, people, locations, OT, etc.

What are the pros and cons of both approaches based on your experience?

And which approach would you recommend for a larger organization?

Any best practices, lessons learned, or recommendations would be very welcome.

Thank you very much for your help!

LG,
Anna

[Jean Horn · Accepted solution]

Hello Anna, and welcome to the Atlassian Community! 👋

First of all, congratulations on taking the leap into Jira Service Management Assets. It is an incredibly powerful tool, and you are asking the absolute most important question right now. Getting the architecture right from day one will save your team a lot of headaches down the road!

For a larger organization, do not put everything into one massive schema. It is highly recommended to use Separate Asset schemas grouped by data ownership or business domains (e.g., IT, HR, Facilities), and then link them together using cross-schema references.

Here is a detailed breakdown of both approaches based on best practices:

1. One Large Asset Schema (The "Everything Bucket")
   • Pros: Very easy to create reference links between object types since everything is in one place. You get a single, massive visual graph of all your data.
   • Cons: This quickly becomes a nightmare for permissions and maintenance. If HR needs to update "People" and IT needs to update "Hardware", you have to give both teams access to the same schema. It also clutters the UI and can impact performance as the database grows.
2. Separate Asset Schemas (Recommended Approach)
   • Pros:
     • Granular Permissions: You can assign specific Object Schema Managers (e.g., Facilities manages "Locations", HR manages "People", IT manages "Hardware").
     • Cleaner UI & Maintenance: Easier to navigate, audit, and update.
     • Scalability: Much better performance for larger organizations.
   • Cons: You need to map out your architecture carefully at the start.

My Recommendation for a Larger Organization

Go with a hybrid, domain-based approach. Create schemas based on who owns the data. For example:

• ITAM Schema: Hardware, Software, Licenses, Network Equipment.
• People / HR Schema: Employees, Departments, Roles.
• Facilities / Infra Schema: Locations, Offices, OT (Operational Technology).

You can easily link an Employee (from the HR schema) to a Laptop (in the ITAM schema) using Cross-schema object references.

Relevant Notes & Permissions

• Hosting: Cross-schema referencing is fully supported natively in both JSM Cloud and recent versions of JSM Data Center.
• Permissions: You will need Jira System Admin or Assets Admin rights to create the schemas. Once created, you can delegate by assigning Object Schema Managers to the respective domain owners.
• Plans: Keep in mind that Assets is a native feature available on Jira Service Management Premium and Enterprise plans.
• Marketplace: If you plan to populate these schemas automatically, remember that while Jira offers some native discovery tools, there are excellent specialized integrations on the Atlassian Marketplace (like Device42, Lansweeper, or Snow) that can feed your separate schemas seamlessly.

I hope this helps you plan your deployment, Anna! Asset management is a journey, so take your time planning the architecture. If you found this answer helpful, please consider clicking Accept Answer so other community members facing the same challenge can find it easily.

Let us know if you need help setting up the reference attributes!

[Marc -Devoteam- · Accepted solution]

HI @Anna Kochura 

I would always suggest to use at least 2 schemas.

I like to have users and their affiliated relations (like locations, etc...) in a separate schema as this most of the time is used in multiple spaces.

Applications and Devices could be in a different schema, based on the amount you cloud decide to have separate schemas as well.