Bridging Documentation and Asset (CMDB): The Need for Asset Tagging in Confluence

[Stephanie P_]

Background

We as an organizations increasingly rely on Jira Service Management Assets as our CMDB and source of truth for applications, infrastructure, integrations, and business services, documentation becomes just as important as the asset data itself.

While Assets provides an excellent way to manage relationships between systems, services, and configuration items, there is still a gap when it comes to connecting operational knowledge and documentation directly to those assets.

Today, documentation is often stored in Confluence, while asset information resides in Jira Assets. Although Atlassian provides Assets macros that allow Assets data to be displayed in Confluence pages, there is no simple and native way to "tag" a Confluence page to a specific Asset and automatically establish a persistent relationship between the two.

The Challenge

Consider an application asset stored in Assets.

The related documentation may include:

• Architecture documentation
• Operational runbooks
• Disaster recovery procedures
• Integration guides
• Compliance documentation
• Ownership and support information
• Change and migration history

Although all of this information may exist in Confluence, there is often no authoritative connection between the Asset and the documentation.

As a result:

• Documentation becomes difficult to discover.
• Teams spend time searching for information.
• Knowledge is fragmented across multiple spaces.
• New team members face longer onboarding times.
• Asset owners struggle to maintain a complete picture of their services.
• CMDB data lacks the context needed for effective operations and governance.

What Existing Solutions Provide

Atlassian already supports displaying Assets objects within Confluence pages through the Assets macro. Organizations can embed Asset data, query Assets, and create reports based on object information.

However, this relationship is largely one-directional:

Assets → Confluence

The missing capability is:

Confluence → Asset

In other words, the ability for a document to explicitly declare:

"This page is documentation for Asset XYZ."

and for Asset XYZ to automatically reference that documentation.

Proposed Feature: Native Asset Tagging in Confluence

A valuable enhancement would be a native "Asset Tag" macro or page property that allows authors to associate one or more Assets directly with a Confluence page.

Example:

Associated Assets

• Customer Data Platform
• Azure Integration Hub
• SAP Interface Gateway

Once tagged, the relationship should become visible in both directions.

From Confluence

A page could display:

• Related Assets
• Asset owner
• Service criticality
• Lifecycle status
• Environment information

From Assets

An Asset could automatically display:

• All linked Confluence pages
  • Architecture documents
  • Operational procedures
  • Troubleshooting guides
  • Design decisions
  • Historical documentation

My recommendation to Atlassian

Atlassian already provides mechanisms for displaying Assets data inside Confluence pages, demonstrating that the technical foundation exists. 

The next logical step would be to introduce a native, bidirectional relationship between Assets and Confluence documentation through Asset tagging or linked knowledge objects.

This would enable organizations to treat documentation as a first-class component of an Asset, transforming the CMDB from a repository of configuration data into a comprehensive source of operational knowledge.

In short: Every Asset should know which documentation belongs to it, and every document should know which Asset it supports.

That relationship is currently missing and would be a highly valuable enhancement to the Atlassian platform.

I know this was a long story, so thanks for reading this far. Let me know if you have same issues. 

Best regards Stephanie 

[Gabriela - LeanZero]

Hi @Stephanie P_, the closest thing to your "From Assets" list runs on Data Center, and it is smaller than what you sketched. There is a Confluence attribute type there: an admin adds it to the object type, then someone picks a page per object by hand. Atlassian's DC doc words it "This type enables a link to a Confluence page." One page, chosen manually, so not the automatic roll-up of runbooks and architecture docs you described. It hasn't crossed to Cloud.

The Cloud attribute picker doesn't offer it. Atlassian's Cloud doc lists seven groups, Default, Object, User, Group, Project, Status and Bitbucket Repository, and that is the lot. If you go digging in the Cloud Assets REST spec you will find a parameter description that still names a Confluence type, though the type table in the same spec omits it, along with Project and Bitbucket, which do exist. I haven't tested whether the API takes it, so I would go by the picker.

The open request is JSDCLOUD-10243, Gathering Interest, 22 votes, filed August 2021. The same ask came round again in July 2022 as JSDCLOUD-11598, and Atlassian closed that one on 13 May 2025, resolution Low Engagement, on 4 votes. Read its closing comment before you decide where to spend the effort. They put the close down to "inactivity for an extended period of time", they say votes sit alongside support insight, product analytics and research, and they finish with "if you feel like this Suggestion is still important to your team please let us know by commenting on this ticket." So comment on 10243 with your use case. Most of what you wrote above already is that.

Your Confluence side is thinner. JSDSERVER-8065 is the one that covers it, seeing from a page which objects reference it, but it sits in the Data Center project on zero votes. Nearest live Cloud ticket is CONFCLOUD-79139, a field in a Confluence database holding Jira assets, 28 votes, which gets you a database entry rather than the page. Filing the missing one yourself isn't an option either. Since April 2023 Atlassian stopped customers creating suggestions on JAC for Cloud products, so it goes through give feedback in the help menu, or a support ticket if you're a product admin, and an engineer creates it on your behalf. That is how 79139 got there, its reporter is an atlassian.com address.

In the meantime the only thing that actually works is a Default attribute of type URL on the object type, one per document class. No picker, no validation, a link sitting in a text field, but the object at least carries its runbook.