Using Assets as a Document Control Register for Confluence, SharePoint, Box, etc.

[#1]

Hi everyone, I am currently exploring an idea for using Assets in Jira Service Management as a document/KB articles control register for our operational documentation and knowledge base.

The main objective is not to replace Confluence, SharePoint, Box, etc. These platforms would continue to be the actual repositories where documents, articles, files, and procedures are stored.

Instead, the idea is to use Assets as the control layer for documentation management.

Like many organisations, we have documentation spread across different platforms and business areas. Some documents are in Confluence, some are in SharePoint, some are in Box, etc. The challenge is not only where the documents are stored, the bigger challenge is maintaining proper control over them, for example: Who owns the document? Is the document still current? When was it last reviewed? When is the next review due? Is the document still relevant? Has it been superseded by another document? Is there a clear audit trail showing that the document was reviewed?

Over time, documents can easily become outdated, duplicated, or unclear in terms of ownership. This creates operational risk, especially when documentation is used to support service management, technical support, deployment activities, customer support, and quality processes.

Therefore, the idea is to create an Assets schema where each controlled document is registered as an object. The actual document would remain in its source repository, but the Assets object would contain the document metadata and control information. For example, each document object could include attributes such as:

- Document title
- Document number
- Revision or version
- Document link
- Document category
- Document type
- Owning organisation or team
- Document owner
- Document author
- Lifecycle status
- Review status
- Confidentiality classification
- Date of issue or publishing
- Last reviewed date
- Date of next periodic review
- Review frequency
- Archive retention period
- Related JSM review request
- Supersedes / superseded by relationship

The document link would point to the source of truth, whether that is in Confluence, SharePoint, Box, or other document repository tool. Since Jira can integrate with these platforms, the link itself can show where the document is located, so we may not need a separate repository attribute at the beginning.

One important point we are considering is separating the document lifecycle status from the review status.

For example, lifecycle status could be: Draft or Current or Superseded or Archived or Obsolete. In the other hand, thee Review status could be Not due or Due soon or Needs review or Under review or Overdue.

This separation seems important because a document can still be current but due for review. The review status should trigger action, while the lifecycle status should indicate whether the document is still valid for use.

The next step would be to use automation to create document review requests in JSM. For example, when the next review date is approaching, Jira automation could create a JSM work item and assign it to the document owner. The work item would include the asset field pre-filled, document link, review deadline, current revision, and required action.

The review could then be tracked through a JSM workflow, such as:

Open → In Review → Update Required → Approval Required → Completed

Or, if no change is required: Open → In Review → No Change Required → Completed

Once the review is completed, the Assets object could be updated with Last reviewed date,Next periodic review date, Updated review status,Updated revision/version, if applicable Link to the completed JSM review request. This would provide a much clearer audit trail and reduce the number of documents that remain outdated or unreviewed.

Questions for the community:

I would be very interested to hear from others who have tried something similar. Has anyone used Assets to manage documentation metadata, ownership, review cycles, or document control?

[Dave Rosenlund _Trundl_]

I think this is a very interesting idea. Please keep us posted about your journey with it. 

[Aron Gombas _Midori_]

@Joao Galego It is interesting!

How do you plan to display everything (incl. the content itself, its metadata + status, related review task, etc.) in a single location? I think it is crucial to keep everything in a single view, which will require integrations between Jira and all content repositories (Confluence, Box, Sharepoint, etc.).

[Susan Waldrip]

Really intriguing idea, @Joao Galego ! Depending on the number of documents you're working with, this would make sense for JSM Premium and Enterprise, but the limitations of JSM Standard might be prohibitive (5000 assets, 5,000 successful automation runs per month). Also, you may want a field or asset attribute related to document-level (or more granular) security depending on the types of content your setup would be tracking and helping to maintain.

Looking forward to any updates you're willing to provide for this effort. It seems like a very feasible and logical way to maintain and report on documentation and still allow your users/customers the most flexibility in native formats and locations. Good luck!

[Joao Galego]

 Hi  @Aron Gombas _Midori_ 

Yes, I agree. I think the “single view” is one of the key points we need to validate during the pilot.

At this stage, my thinking is that the Assets object would become the control record for each document, while the actual content would remain in its original source repository.

For example:

- If the document is a Confluence page, the page itself would be the controlled document.

- If the document is stored in Box, SharePoint, or another repository, a structured Confluence page could contain the link to that source document.

- The Assets object would then hold the metadata, owner, lifecycle status, review status, review dates, and link to the relevant document location.

- The JSM work item would be used to track the active review task and would be linked back to the Assets object

Another option I am considering is the QR code that can be generated from an Assets object. I am not fully sure yet how useful this will be in the documentation context, but the idea would be that scanning the QR code takes the user directly to the Assets object, where they can see the document metadata, status, owner, review information, and link to the source document.

This may be more useful for printed copies, controlled documents, training material, or cases where people need a quick way to check whether a document is still current.

However, I agree that the main success factor will be whether the integration between Jira/JSM, Assets, Confluence, Box, SharePoint, etc., can provide a practical single view without duplicating the actual document content.

So, for the pilot, one of the things we need to test is exactly this, whether the Assets object + JSM review work item + source repository link gives users enough visibility in one place.

[Joao Galego]

Hi @Susan Waldrip 
Thank you for the feedback. You raised two very important points.

The first one is the scale/licensing limitation. For the pilot, we are planning to start with a limited number of documents so we can validate the concept before considering any broader rollout. I agree that if the number of controlled documents becomes large, or if we create too many objects for revisions, review records, or related items, the Assets object limit and automation execution limits could become a real design constraint.

To avoid that, my current thinking is to keep the model lean: one Assets object per controlled document or KB article, while the actual review execution and audit trail would be handled through JSM work items. I do not want to create unnecessary Assets objects for every review activity unless there is a clear reason to do so.

The second point is document-level security. We are already considering a confidentiality/security classification attribute, but your comment makes me think we should treat this as one of the key pilot validation points. The Assets object should probably indicate the document classification, but the actual access control still needs to remain enforced in the source repository, such as Confluence, SharePoint, Box, etc., and also through the relevant JSM permissions where applicable.

So I think the pilot needs to validate not only whether the schema works functionally, but also whether the model remains scalable, does not consume automation excessively, and respects the security model of each source repository.

I appreciate your comment as this is the type of practical considerations we need to test before scaling this further.