Your Confluence pages are already a database. We just don’t always treat them like one

[#1]

Confluence is usually described as a place for documentation, collaboration, and knowledge sharing.

But many teams are also using it for something else: managing structured business data.

Project status, owners, deadlines, departments, customers, risks, decisions, products, systems, policies, dependencies and dozens of other attributes are already being recorded across Confluence pages every day.

The interesting question is no longer whether Confluence contains structured data.

It clearly does.

The real question is whether we are making the most of it.

Page Properties changed how many teams use Confluence

The Page Properties macro — now called Content Properties — introduced a simple but powerful idea: information written inside a page could also be treated as structured metadata.

A page could remain a rich document containing context, discussion and decisions, while a small table identified its most important attributes:

• Owner
• Status
• Team
• Due date
• Priority

The Content Properties Report macro could then collect those attributes from multiple pages and display them in a single report.

This pattern is still one of the most useful building blocks in Confluence.

It allows teams to create project directories, product requirement indexes, decision registers, risk reports and status dashboards without moving the underlying knowledge away from the pages where it belongs.

More importantly, it connects two things that are often separated:

structured information and human context.

The page should remain the source of context

A row in a traditional database can tell us that a project is “At risk”.

A Confluence page can explain why.

It can contain the discussions, alternatives, screenshots, meeting notes, technical constraints and decisions that led to that status.

This is one of Confluence’s biggest advantages as an information platform. The structured data does not have to live in isolation. It can live alongside the knowledge that gives it meaning.

For many use cases, the page is not simply linked to the record.

The page is the record.

Where the Page Properties pattern starts to feel limited

The challenge appears as the amount of information grows.

Page Properties works extremely well when teams agree on a template, use consistent property names and apply the correct labels. But maintaining that consistency becomes harder across dozens of teams or hundreds of pages.

Small differences can quickly fragment the data:

• “Owner” versus “Project owner”
• “In progress” versus “In Progress”
• Dates entered in different formats
• Missing or inconsistent labels
• Properties added manually in a different order

The reporting macro can aggregate the resulting pages, but the output is primarily a summary table. When users need richer filtering, grouping, calculations, multiple reusable views or more control over data types, the original pattern begins to reach its natural boundaries.

This is not a criticism of Page Properties. It is evidence of how valuable the pattern has become.

Teams are asking it to solve increasingly sophisticated data-management problems because the fundamental idea is so useful.

Confluence databases are an important step forward

Native Confluence databases provide a more deliberate way to create structured collections. Fields can have defined types, entries can be filtered and sorted, and teams can create different views over the same dataset.

For inventories, directories and centrally maintained registers, this is a significant improvement.

However, databases introduce a different information model.

Instead of starting with a page and extracting its most important attributes, teams often start with a collection of rows and optionally connect those rows to pages.

That works beautifully for many scenarios. But it does not completely replace the page-centric model.

Sometimes the information already exists across hundreds of pages. Sometimes each record requires substantial narrative context. Sometimes teams want to preserve their existing templates and workflows rather than migrate everything into a new database.

The two approaches solve related, but not identical, problems.

The opportunity is not “pages or databases”

It is tempting to frame the future of structured information in Confluence as a choice:

• Use pages and Page Properties
• Or use native databases

In practice, most organisations will probably need both.

Pages are excellent containers for knowledge and context. Databases are excellent containers for structured collections. Page Properties creates a bridge between documentation and reporting.

The next opportunity is to make those models work better together.

Imagine being able to treat properties distributed across Confluence pages as a coherent dataset:

• without removing the information from its original context;
• without forcing every team into a separate database;
• without requiring users to manually maintain complex reports;
• and without losing the flexibility that made Confluence useful in the first place.

From collecting data to understanding it

Displaying a list of properties is only the beginning.

Once information is consistently structured, teams naturally want to do more with it:

• Group projects by department or status
• Calculate totals and averages
• Identify missing owners or overdue dates
• Create different views for different audiences
• Compare data across spaces
• Detect patterns and inconsistencies
• Ask questions about the information using natural language

This is where structured data stops being a reporting convenience and starts becoming organisational knowledge.

AI also makes this distinction increasingly important. An AI assistant can generate a better answer when it can distinguish reliably between an owner, a deadline, a status and an unrelated sentence somewhere in the page.

The quality of future AI experiences in Confluence will depend, at least partly, on the quality and accessibility of the underlying structured data.

A small change in how we think about Confluence

Perhaps we should stop thinking of Confluence pages as unstructured documents.

Many of them are already hybrid objects:

• part document,
• part record,
• part conversation,
• and part dataset.

Page Properties revealed this possibility years ago. Native databases have expanded it. The next stage will be about connecting these capabilities and helping teams move more easily from isolated values to useful, trustworthy information.

Because the data is already there.

What we need now are better ways to structure it, connect it and learn from it.

How is your team managing structured data in Confluence?

I would be interested to hear how other teams approach this today:

• Are you still using Page Properties and reporting macros?
• Have you moved some use cases to Confluence databases?
• Do you combine both approaches?
• What becomes difficult when the number of pages or records grows?

The answers may tell us a lot about what the next generation of data experiences in Confluence should look like.

[Veronika Chachkova I Stiltsoft]

Hi, @Mia Tamm _Simpleasyty_! 👋

We're still big users of Page Properties Report + Handy Macros for documentation-driven workflows. 

PPR works best when each item has its own Confluence page (for example, requirements, knowledge base articles, project documentation, process pages, decision logs...)

We use Handy Status (dynamic dropdowns), Handy Date (interactive dates), and Handy Timestamp (records the specific moment on the page) inside Page Properties to create structured, reportable metadata that's easy to standardize across hundreds of pages.

A few reasons this combination still works so well for our customers and us:

• Unlimited custom status sets for different teams and workflows
• Easy reporting and searching by status and other metadata
• Consistent data through page templates and standardized properties (I love the templates part!)
• Visual, easy-to-scan reports with color-coded statuses and dates (also status and date change in the view mode)
• Every record remains a full Confluence page with history, comments, attachments, and rich content

We use databases for some lightweight trackers, but for documentation-centric use cases, Page Properties Report combined with Handy Macros still offers the best of both worlds: structured reporting without giving up the flexibility and collaboration benefits of Confluence pages.

Cheers,

Veronika from Stiltsoft

[Mia Tamm _Simpleasyty_]

Thanks @Veronika Chachkova I Stiltsoft 

I completely agree with one thing you mentioned: the page should remain the primary source of truth.

That's actually one of the reasons I wanted to write this article. I think many teams naturally end up storing structured metadata inside pages because the context lives there as well.

What I'm really curious about is how teams are approaching this today now that we also have native Confluence databases.

Do you see your customers mostly staying with page-based metadata, or are you seeing more hybrid approaches where both pages and databases coexist?

I'd love to hear what you're observing.