Confluence is a great tool for hosting content and storing information. Not all content, however, is the same. So, let’s take a look at the basic types of content that you can add to Confluence (at least as of the time of writing! Atlassian is constantly expanding and exploring new things to do with this tool, so I wouldn’t be surprised if this changed over time…).
Note all Blogs, Databases and Whiteboards can be disabled by a Space admin, so if you don’t see them check with your IT department or Space admin for help.

Keep reading for more, or check out this video walking you through them all

Pages

Pages are what most people think of when they think of content in Confluence. They’re a blank document that can contain any combination of text, images, attachments, macros and more. They’re also an easy entry as many people are already familiar with a document (Word, Google, Lotus, etc.), and many of the concepts and ideas behind word processing apply to pages.

Pages are also the only content type that cannot be disabled - meaning every space will always have this content type available for use.

What are pages for?

I find pages to be particularly useful for content that is perennial - that is it’s always useful or needed. Things like policies, team playbooks, how-to articles and the like are things that someone can always pull off the shelf and use. This is in contrast to “point-in-time” information, which we’ll explore down in blogs.

Pages also exist in the space hierarchy, meaning you can nest them under, or use them to use, other pieces of content. This allows you to build out a visual representation of information. For example a “policies” page could house every policy, or a page about a system could have everything related to that system under it.

What are pages not good for?

While pages are versatile they aren’t always the best at conveying visual information (check out whiteboards for that), and while they can house a table, they’re not the best at conveying structured data (check out databases instead). 

Blogs

Blogs look very similar to pages… they have the same editor, and they are (almost) visually indistinguishable from pages. That said, there’s a key difference - they don’t live in the page hierarchy. Instead, they live under the “blogs” link, and, unlike pages, they can be disabled on a space-by-space basis (so if you don’t see the menu, check with your space admin for help).

What are they good for?

While blogs don’t appear in the space hierarchy, they do sort themselves chronologically. This makes them a great candidate for point-in-time information. Common examples I’ve seen include:

1. Product updates

2. Weekly data drops

3. Personal performance information

4. Team announcements

Information of this type tends to be useful in the moment, but quickly becomes outdated as things change (e.g. there’s a new release). This doesn’t mean it isn’t useful, just that we need to put different things in as a blog.

What are they not good for?

Given that blogs aren’t part of the page hierarchy they’re not the best place to put information that needs a general structure. For example, I can’t nest a blog post under another page, so using it for a how to article wouldn’t make sense. This also means blogs should be (relatively) contained and not outside context to fully understand.

Whiteboards

Whiteboards are what they sound like - a digital space to map, diagram, draw and collaborate. They allow users to collectively work on diagrams, brainstorm and manipulate objects in real time. Personally I prefer a big physical whiteboard, but frequently my team isn’t in the same office, so this virtual version is a great replacement.

Like pages, whiteboards appear in the space hierarchy, which is a great feature. This allows you to nest them under related information - think putting a system diagram under the page that details that system, or the sprint planning whiteboard under the sprint’s main page. This makes it incredibly easy for teams to quickly find related information, and to gain important context, about what’s on that whiteboard.

What are they for?

Whiteboards are great for conveying, and collaborating, on visual information. Need to diagram a system? What about brainstorm how to improve a process? Diagram that process? All of that can be done in a whiteboard, and saved directly into the page hierarchy near related information. I find them useful any time I need to draw out my thoughts, or walk someone through a process (both things that are hard/challenging in other types of content).

They do also integrate with Jira, allowing you to pull Jira tickets into the whiteboard as objects. You can also represent confluence pages as objects. This allows you to easily pull in related information, or build page hierarchies visually.

What are they not good at?

Whiteboards are not good for storing a lot of text, or managing written information. They also don’t contain macros, so there’s not as many clever things you can do within a whiteboard (pages are better at that).

Databases

Up until the release of Databases your only option to represent data in Confluence was to use a table. Tables are great, however, they have a lot of limitations that Databases don’t. This includes things like:

1. Add different information, like dropdowns, to cells

2. Back link entries in one database with another (e.g. having one database list customers, and another list all the contacts for them)

3. Pull in Jira or Confluence information automagically

4. And more

What are they for?

I find that databases bridge the gap between a page and a Jira ticket. They offer a lot more options for storing and sharing information than a table, but aren’t as complex as a ticket. This makes them great at helping organize information - think things like project plans, a CRM or marketing plan. They also have some great features allowing you to save various views (for example showing all the unresolved items) and easily share them with stakeholders. This makes sharing all that structured information a lot easier.

You can also copy the structure of database into a new one, which makes using them for similar needs a breeze.

What are they not good at?

While Databases are a great middle ground, there are times when you need more than what they offer. If you have a need to move things through a workflow or share outside of Confluence you might need Jira instead. Similarly if you have a simple use case - just recording names or a list - you might opt to go with a page instead.