Using Confluence databases for a FAQ
I frequently find myself using Confluence to track Frequently Asked Questions (FAQ). I’ve done this for HR/People teams, Customer Support, Engineering, and many others, and it’s a great use of the platform.
Historically I’ve accomplished this one of two ways:
Parent with Children - Have a parent page called “HR FAQ” and then have a single child for each question and answer. (Check out that approach here)
Headers and sub headers - Have a single page with all the FAQ and use headers (and the Table of Contents macro) to break out questions.
Since the launch of databases, however, I’ve found myself wondering (and have been asked about) how databases could support an FAQ.
What are databases?
Databases are a relatively new feature to Confluence that allow you to build a structured data set into Confluence. On the surface they can look a bit like a table but they go far beyond the humble table and start to overlap (a bit) with the concept of a Jira ticket.
Each column of the table is a piece of data about something. In our FAQ this would be information about the question - its name, an answer (or link to one), the owner, category and more.
Each row is an entry - in our case, a question.
Databases also include some additional features that make them very useful:
Saving filtered views
These are a saved list of all rows that meet some criteria. For our FAQ this could be all IT related questions, or anything unanswered.
Different visualizations
Databases display info in a tabular view by default, but there are other options include cards and a board view. For me the table view works best for a FAQ, but teams may prefer the others as well.
Search
Databases have their own search bar. This allows users to easily search within just that database. This makes it easy for your users to find answers in your FAQ.
Catch up on other basic features in this video:
How do they help build an FAQ?
Databases live in the content tree, making them very simple to insert where people will look for information. They also allow multiple entries, keeping their presence in the content tree limited (if you go with the “one page per question” route you end up with a lot of pages, which can easily turn some teams or groups off from considering it as an option).
Since databases allow for multiple columns you can also include a lot of information about questions. Things like who asked it, what type of question it is, what version it controls, etc. can all be included (This could also replace using page properties if you’re using that to track this type of information). This allows you to build very robust answers, including linking out to reference content and more. You can even pull in excerpts from linked pages, potentially allowing you to include an answer directly in the database automatically.
Anyone with edit access can also add new entries to the database, making it very easy for someone to be able to add questions. Imagine if anyone at your organization could drop in and add a new question which you can easily filter for and assigning to someone to answer.
What are the downsides of using a database for a Confluence FAQ?
There are a few downsides to using a database to host questions and answers:
Jira Knowledge Base - JSM appears to only see Pages as answers to questions. This means if you’ve got a JSM instance linked to Confluence answers in your databases can’t currently be displayed… so if you want to use this to support your help desk you’re a bit out of luck (although you could use this to support agents, or others who leverage Confluence, but they’d have to access it independently of JSM).
Control - Like other forms of content you can place restrictions on the database… However, those restrictions apply to all records. This means you can’t “lock” a single row and prevent anyone but yourself from editing it. This opens up the risk that answers will be changed or added when they shouldn’t be. You can solve this by restricting editing to only a few folks, but then you face a bottle neck around adding new questions.
Confluence search - Individual database entries currently are invisible to general Confluence search. This means someone searching from another piece of content may not be able to find your FAQ.
Final Thoughts
While using a database to host FAQ is a great way to store info it does present it’s limitations. This makes them less-than ideal for some applications, however, for instances where you have an internal team who knows which database to look at these are incredibly powerful. Similarly if you are able to share saved views with internal users you’ll likely get a lot of utility out of them.
More Info
See how to set them up in this hands-on video:
