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

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