Use Databases for your docs life-cycle management

[#1]

Here's a quick tip how to put Confluence Database to use - the tool is still in beta, many Confluence users don't know how it can be actually useful. So perhaps this will help.

Anyway... :)

My use-case - an LCM database for docs space

I use it to get a quick overview of Confluence space where we author and manage Emplifi documentation. It makes life-cycle management (LCM) of our doc sets so much easier.

So here's what I have:

• page title (column is set up as a page link field)
• last updated
• ...by
• label
• owner
• created
• page history version
• excerpt content

In this use case, I have an overview of the entire space and can easily sort the table to see the last updated/added pages, ensure they all have proper labels. I can turn it around and see the oldest pages in the space. Content by label is especially sweet as you don't need an extra page to deploy that macro.

Get all pages into your DB

The trick was to figure out how to get all pages (page links) in to the database. I wish it could be automated but it's a question of a couple of minutes to get it all done.

Here's a how-to gif (it's public link from my private Confluence as it's too big for a Community post. 

The database works just fine even with 900 pages (tested). Sorting by date is relatively  fast but it obviously depends on how many pages and details your database displays.

Another use-case example

Another use-case is monitoring a collection of pages that serves a specific purpose.

Say that you have a course in your LMS that relies on the content from your Confluence sourced docs.

Simply create a DB for that specific course, list the pages the course is using, enter the date when the course went live. If the 'last updated date' of a page is newer than the course date, you know that you need to update your LMS content.

Confluence Databases wishlist

• Populate the DB with all space's pages
• List each history version number along with the editor of the given version
• allow listing apps data
  • Comala Document Approval status
  • Comala Publishing status
  • Scroll Document version
  • Scroll Viewport default/custom links
  • Scroll Viewports where the page is

Last word

You might argue that many of the features can be replicate by labels. But you can have all that, and more, in a single place with context for any individual information type. The app was called 'Orderly Databases' for a reason when it was first developed by K15t (before Atlassian acquired the app).

[Panagiotis]

Hello @Kristian Klima ,

This is amazing. Thank you for sharing. 

Hopefully we will find a way to automatically keep this database up to date with newly created pages! 

[Kristian Klima]

@Panagiotis Yes, that would be tremendously useful.

- create page option - add to DB, Yes/No, if yes then select DB.

- Page menu option - add to DB, select DB.

Also, the copy/paste hack from the reorder page works great but it's no fun expanding all parent pages - one missed click and one can start again :) 

[Aron Gombas [Midori]]

I like the idea of using a Confluence database to solve this kind of lifecycle management problems, but...

1. It requires repeated and manual work, right?
2. Will this method scale if the site grows for a few-thousand pages?

[Kristian Klima]

@Aron Gombas [Midori] 

1. Yes, once you add the existing pages (which you can do in one go), you have to add the pages manually.
   But as @Panagiotis quipped, there might be a solution.
2. I have close to 1K pages in my space and the DB loads fully in a couple of seconds. Reordering, say by date, takes 10-20 seconds - it depends how detailed are your other columns. If you have an Excerpt column and a lot of pages with excerpt content, it takes longer.

DBs are still in beta so I wouldn't judge it too harshly :)

[Tom Carrott]

Interesting post @Kristian Klima and very relevant to me (as you well know from our previous chat) ;) 

[Tom Carrott]

@Panagiotis - i'm very interested in your views on this topic. Its an area of research & discovery for me at the moment - would you be willing to have a short call with me to discuss this further? 

[Levente Szabo _Midori_]

Hey @Kristian Klima and all,

I understand that this is a promising approach for displaying pages in a table-like format and getting a glance at some metadata, like last updated date, creation date, or owner.

What I don't understand is how content lifecycle management (CLM) comes into play here. In my mind, Confluence content lifecycle management is a framework that nurtures content through different statuses (mostly automatically) from creation to dislocation and allows for actions (manual or automatic) along the way like notifications and automatic archiving, (based on preset rules) to keep Confluence up-to-date.

You mentioned lifecycle management, so I was wondering what you do with all the 1000 pages in your database besides displaying them. What are the principles for CLM and how does this database approach support that?

[Kristian Klima]

Hi @Levente Szabo _Midori_ 

For customer facing product documentation (technical docs), my vision of life-cycle management is to ensure the docs always reflect the product.

This is crucial when one's on pretty much continuous delivery, supporting tens of development swimlanes, each of which moves at its own speed, aligned by GTM that's measured in days.

A database that I created helps in the overall docs LCM process - it's one of the tools, not a single tool. But over the last two months or so I've been using it, it made my life easier and it'd be even more so with apps integration, etc. Not to mention using dedicated Confluence Databases as tools to LCM content in our learning platform. 

The point is that In our world, there's no such a thing as mandatory reviews, page expirations, etc.  as time itself is never a benchmark to asses and invalidate a document. Maybe this is down to my time spent as a tech writer on mainframe products where a page that's 30 years old is as up to date as a page I created in the same tree section yesterday. I'm not joking :) 

I think it comes to down to the nature of the content. Is your content static and in need of regular reviews? Or is your content itself a process? To me, it's the latter. And for that purpose, having a DB is tremendously useful.