Display Names Update for Assets and What It Means for Your CMDB

[#1]

Hi Community 👋

Today I want to share a small but meaningful update to how asset entities are named and more importantly, explain why we made this change and what problem it solves for IT and operations teams.

The problem we kept hearing

If you've managed a CMDB in Assets for any length of time, you've likely hit this wall: you can't rename things without breaking things.

Want to relabel "Server_Linux_Prod" to something your service desk agents can actually understand? That rename ripples through your AQL filters, automation rules, and API integrations. Potentially breaking reports, workflows, and scripts overnight. So most admins face a painful trade-off:

• Prioritize the end-user → use human-readable names like "Production Database" and deal with the AQL nightmare of spaces, special characters, and escaping syntax.
• Prioritize the developer → use machine-safe names like database_instance_prod and accept that your portals, dashboards, and reports look like they were written for a compiler, not a person.

Neither is a good answer. And as your organization evolves, teams rename, services consolidate, terminology changes, that technical debt compounds. What started as a clean CMDB slowly becomes a mess of legacy names that nobody wants to touch because the blast radius of a rename is too unpredictable.

What we built: a dual-identifier model

We've introduced Display Names for all Assets configuration entities: schemas, object types, attributes, statuses, and reference types.

Every entity now has two identifiers:

Identifier	Purpose	Mutable
Name	System identifier used in AQL, APIs, and automations	Yes, but triggers a warning modal
Display Name	Human-readable label shown in the UI, portals, and reports	Yes, freely. No downstream impact

When you create a new entity, you enter a Display Name first. Assets automatically generates a safe system Name from it, which you can override before saving. Existing entities have been automatically backfilled your Display Name will initially match your current Name, so nothing changes on day one.

Why this matters at scale

For IT Directors and Operations leaders managing enterprise-scale CMDBs, the implications go beyond cosmetic:

• Eliminate integration fragility. Your AQL queries, Jira automation rules, and API scripts are anchored to the system Name, which is now protected. UI rebranding is fully decoupled from system stability.
• Accelerate org changes. When your company rebrands a service or restructures IT, a terminology update is now a 5-second config change; not a database migration that requires coordination across every team that references that schema.
• Support global teams. Display Names allow you to present localized, language-appropriate labels in your portals for regional teams, while the underlying AQL remains a single consistent identifier across your global instance.
• Cleaner self-service portals. End users and service desk agents see readable, business-friendly labels — not the developer conventions your CMDB was built on years ago.

One important note for your integrations team

AQL, APIs, and automations continue to resolve entities using the system Name, not the Display Name. If you have existing scripts or filters, nothing changes unless you explicitly edit the Name field (which will surface a warning before saving). This change is fully backward-compatible.

Getting started

1. Open Assets → select any schema, object type, or attribute.
2. Find the Display name field under the General tab → enter your preferred label → Save.

SAC Documentation

• https://support.atlassian.com/assets/docs/change-the-name-or-description-of-an-object-schema/

• https://support.atlassian.com/assets/docs/change-the-name-or-description-of-an-object-type/

• https://support.atlassian.com/assets/docs/edit-a-status/

• https://support.atlassian.com/assets/docs/edit-a-reference/

• https://support.atlassian.com/assets/docs/create-an-attribute/

• https://support.atlassian.com/assets/docs/what-are-attributes/

• https://support.atlassian.com/assets/docs/glossary-of-assets-in-jira-service-management/

[Mathew Lederman]

@Makarand Gomashe does this make change assets fields any more user-friendly in a Jira search? Today searching for asset fields via JQL or Basic search is nearly impossible unless you are INTIMATELY familiar with the scheme configuration.

[Quang Kieu]

Hello @Makarand Gomashe , 
Does this apply to the Asset macro in Confluence? 

[Dirk Ronsmans]

Lovely addition/change.

Having a "configuration"-identifier and a "human readable"-identifier should be done for each configuration item. Would also help in propagating between instances :) But it will definetly help in avoiding issues now when an object type changes name.

Good start @Makarand Gomashe !