I'm curious how others are handling structured metadata in Confluence Cloud, especially when the same information needs to be maintained across lots of pages. Page Properties works reasonably well for smaller setups, but things seem to get more complicated when you need consistent fields, reporting across spaces, or a way to keep track of changes. A few things I'm particularly interested in: * Keeping metadata fields consistent across different pages and spaces. * Building reports without maintaining lots of Page Properties macros. * Handling changes to metadata over time. Are people still mostly using Page Properties and Page Properties Report for this, or have you found other approaches that scale better? Would be interested to hear what's working for others.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How are you managing structured metadata across Confluence pages without relying on Page Properties?

Jesus Nieto

I'm curious how others are handling structured metadata in Confluence Cloud, especially when the same information needs to be maintained across lots of pages.

Page Properties works reasonably well for smaller setups, but things seem to get more complicated when you need consistent fields, reporting across spaces, or a way to keep track of changes.

A few things I'm particularly interested in:

Keeping metadata fields consistent across different pages and spaces.
Building reports without maintaining lots of Page Properties macros.
Handling changes to metadata over time.

Are people still mostly using Page Properties and Page Properties Report for this, or have you found other approaches that scale better?

Would be interested to hear what's working for others.

Accepted answers

Mia Tamm _Simpleasyty_

Hello @Jesus Nieto, really interesting discussion here, especially the points about consistency and version history.

I'm Mia, part of the team behind Simple Metadata for Confluence, and these are exactly some of the challenges we've been working on.

One thing we've noticed is that Page Properties can work well for smaller setups, but maintaining consistent metadata across hundreds or thousands of pages becomes much harder over time.

We've been exploring a different approach using reusable metadata schemas, structured fields, reporting, and change history.

We also built a migration tool that helps convert existing Page Properties into structured metadata without having to rebuild everything manually.

Here's a short video showing the migration process in action, in case it's useful to anyone dealing with a larger Confluence setup:

https://www.youtube.com/watch?v=HVt7EV3pweM

I also agree that Confluence Databases are worth considering. I think the interesting question is when metadata should live directly on the pages themselves versus in a separate database.

Curious how others are approaching that distinction, particularly in larger environments.

Sami Shaik

@Jesus Nieto , good thread. @Kris Klima K15t, @Ciro and @Arkadiusz Wroblewski have covered the options ; let me add the boundaries, because your three requirements (consistent fields, cross-space reporting, change tracking) each stop at a different native wall, and knowing where is what keeps you out of a rebuild later.

1. Consistent fields: templates enforce at creation, nothing native enforces afterwards.
Ciro’s pattern is the right native one: the content properties macro (the renamed Page Properties macro) inside a template, keys pre-filled, label applied by the template. The wall: once a page exists, Confluence has no schema. Anyone can rename a key, delete a row or remove the label, and nothing flags it. Your only native detector is the report itself: a page that drifts simply drops out of the table or shows a blank column. So build the report first and treat an empty cell as a defect, not a gap.

2. Cross-space reporting: native, with limits.
The content properties report macro is not limited to one space. Its CQL filters include In space with OR across several spaces, plus With ancestor, Contributor, Creator and Of type. Two limits to design around: it accepts one label and one properties ID per macro, and it shows 30 rows per page with pagination. For a small number of controlled vocabularies that is enough; for a catalogue of hundreds of pages you will be paging.

3. Change tracking: there is no cross-page audit of metadata in Confluence Cloud.
This is the one to be clear-eyed about. Page property changes are recorded only in each page’s version history. The site audit log explicitly “doesn’t record information related to content edits”. Databases keep version history for 30 days only, as Arek said. If you need “who changed the Owner field on these 400 pages last quarter”, nothing native answers that today.

On the Content Manager (Premium and Enterprise), a precision on Kris’s point: its bulk actions are archive, delete, change owner, change status, run an automation flow and convert to live docs (Clean up a space with the content manager). It does not bulk-edit page property values, and databases are excluded from it. Where it helps you is governance around the pages (ownership, status, archiving stale ones), not the fields inside them.

What I would do on Cloud today, native-first:

Decide which metadata is reporting (keep it in content properties, label-driven, one report page per vocabulary) and which is relational or typed (put it in a Database and link pages to rows). Do not try to make one mechanism do both.
Put the key set in a template and in a one-page “metadata standard” that the report page links to.
Schedule a monthly check of the report page for blank cells and missing pages; that is your drift control.
If the audit question in point 3 is a compliance requirement rather than a convenience, that is where the native path ends and an app or an export-and-diff script begins. Evaluate on exactly these three boundaries.

Confluence Cloud only; Data Center behaves differently in several of these places.

All comments

Kris Klima _K15t_

Hello @Jesus Nieto

Depending on what metadata you have in mind, you can use Confluence's native Content Manager or use Databases. Depending on your Confluence tier, you can use Content Manager to actually change some page metadata en masse.

I wrote about related options here:

Use Confluence Content Manager and Create Your Personal Command Center (K15t learning hub)
Confluence admin HACK: centralize site, space, and apps settings with iframes (Atlassian Community)

Ciro

Hey! Adding to the answer above, here's how I'd tackle each of your three points:

Consistent fields: put the Page Properties table in a page template with the keys already filled in, and add a label to the template. People only fill in values, so the keys can't drift. If you need typed fields (dropdowns, dates, people), look at Databases instead: the columns enforce the type.
Reporting across spaces: one Page Properties Report can pull from several spaces at once. Filter by the template label and pick the spaces (or leave the space filter empty to search all of them). You only need one report per page type, not one per space.
Changes over time: Page Properties live in the page body, so the page's version history already tracks them, and you can compare any two versions. If you need the metadata to be machine-managed or invisible to editors, content properties via the REST API (/wiki/api/v2/pages/{id}/properties) are the next step, but then you'll need a script or an app for reporting.

My rule of thumb: Page Properties + template + label scales fine to a few hundred pages. Once you need strict types or bulk edits, move to Databases.

Hope this helps!

Arkadiusz Wroblewski

Hi @Jesus Nieto

One limitation worth knowing…. Confluence Databases only retain 30 days of version history.

For long-term auditing, you'll need probably another solution.

https://support.atlassian.com/confluence-cloud/docs/database-version-history/

Best,

Arek🤠🧙‍♂️

Mia Tamm _Simpleasyty_

Hello @Jesus Nieto, really interesting discussion here, especially the points about consistency and version history.

I'm Mia, part of the team behind Simple Metadata for Confluence, and these are exactly some of the challenges we've been working on.

One thing we've noticed is that Page Properties can work well for smaller setups, but maintaining consistent metadata across hundreds or thousands of pages becomes much harder over time.

We've been exploring a different approach using reusable metadata schemas, structured fields, reporting, and change history.

We also built a migration tool that helps convert existing Page Properties into structured metadata without having to rebuild everything manually.

Here's a short video showing the migration process in action, in case it's useful to anyone dealing with a larger Confluence setup:

https://www.youtube.com/watch?v=HVt7EV3pweM

I also agree that Confluence Databases are worth considering. I think the interesting question is when metadata should live directly on the pages themselves versus in a separate database.

Curious how others are approaching that distinction, particularly in larger environments.

Jesus Nieto

Thanks @Kris Klima _K15t_! Content Manager is definitely worth looking into.

My main concern is that bulk editing existing pages is only part of the problem. What I'm really trying to understand is how to define a consistent set of metadata fields and make sure those fields are maintained across different spaces.

For example, if we have hundreds of pages that should all follow the same metadata structure, how would you enforce that with Content Manager?

Databases are an interesting option too, although I'm not sure they solve the problem of keeping metadata directly associated with the pages themselves.

Maybe I'm missing something here?

Jesus Nieto

Thanks @Ciro, really appreciate the detailed breakdown!

Your point about using templates and labels makes sense, and I can see that working for smaller environments.

What worries me is the maintenance side as things grow. Templates help when creating new pages, but what happens when the metadata structure needs to change across hundreds or thousands of existing pages?

Also, relying on labels for reporting feels a little fragile, especially when different teams manage their own spaces.

Databases seem promising, but then we're moving the information away from the pages themselves, which isn't necessarily what we're looking for.

I guess what I'm missing is something that combines structured fields, centralized management, and reporting while keeping everything connected to the actual Confluence pages.

Jesus Nieto

That's a really important limitation, thanks for pointing it out!

I hadn't considered the 30-day version history restriction.

For teams that need to track metadata changes over longer periods, particularly for compliance or auditing, that could be a significant issue.

It also makes me wonder whether Confluence Databases are really the right place to manage page-level metadata when long-term traceability is a requirement.

Is there any native approach that provides a proper history of metadata changes without relying on external scripts or custom development?

Jesus Nieto

Thanks @Mia Tamm _Simpleasyty_, appreciate you sharing this!

The migration approach looks particularly interesting, especially for teams that already have a lot of Page Properties in place. One thing I'm curious about: how mature is Simple Metadata at this point? Is it already being used in larger Confluence environments?

Also, does the migration preserve the existing metadata and reporting setup, or would teams still need to make manual adjustments afterwards?

That would probably be one of my biggest concerns before considering a migration.

Kris Klima _K15t_

Jesus Nieto - the reason I asked about what kind of details you're after: What is often required in the page properties macro already exists somewhere and can be displayed and reviewed without forcing users to fill in a form.

Sami Shaik

What I would do on Cloud today, native-first:

Decide which metadata is reporting (keep it in content properties, label-driven, one report page per vocabulary) and which is relational or typed (put it in a Database and link pages to rows). Do not try to make one mechanism do both.
Put the key set in a template and in a one-page “metadata standard” that the report page links to.
Schedule a monthly check of the report page for blank cells and missing pages; that is your drift control.
If the audit question in point 3 is a compliance requirement rather than a convenience, that is where the native path ends and an app or an export-and-diff script begins. Evaluate on exactly these three boundaries.

Confluence Cloud only; Data Center behaves differently in several of these places.

Mia Tamm _Simpleasyty_

Hi @Jesus Nieto,

Thanks for the thoughtful questions! These are exactly the kinds of concerns we believe organizations should evaluate before migrating metadata at scale.

Let me address both points.

On product maturity and enterprise readiness

Simple Metadata is already available in production on the Atlassian Marketplace. While it's a relatively recent addition to the ecosystem, it has been designed with enterprise requirements in mind from the beginning.

Our approach focuses on several key areas:

Centralized metadata governance: Reusable schemas help organizations standardize metadata across pages, teams, and spaces, rather than relying on individually maintained Page Properties tables.
Structured data and reporting: Typed fields, consistent data models, and cross-page reporting make metadata easier to manage and analyze.
Auditability: Metadata changes can be tracked through an audit trail, supporting traceability and governance requirements.
Data residency and security: Simple Metadata is built on Atlassian Forge with Runs on Atlassian architecture, keeping app data within Atlassian's infrastructure.
Scalability: The architecture is designed to support large Confluence environments, where manually maintaining metadata across thousands of pages becomes impractical.

On migration from Page Properties

This is an area we've invested significant effort in because we recognize that existing Confluence content represents years of organizational knowledge.

Our migration tool is designed to:

Discover existing Page Properties structures across Confluence content.
Identify common fields and generate reusable metadata schemas.
Migrate existing metadata values into those schemas.
Replace Page Properties macros with Simple Metadata macros.
Migrate Page Properties Report configurations to Simple Metadata reports.

The objective is to preserve existing information and minimize manual intervention, rather than requiring organizations to rebuild their metadata infrastructure from scratch.

That said, I wouldn't claim that every migration scenario is completely automatic. Complex configurations, inconsistent metadata structures, or heavily customized environments may require additional validation or adjustments.

For larger organizations, we'd recommend starting with a representative set of spaces, validating the migrated data and reports, and then expanding the rollout progressively.

One final point: we see Simple Metadata as a complement to Confluence's native capabilities, not necessarily a replacement for everything Databases or Page Properties can do.

The distinction is that our focus is specifically on structured, governed metadata associated with Confluence pages.

And we're actively improving the product based on real-world scenarios and feedback. If you're evaluating a particularly complex environment, we'd be happy to understand the requirements and help assess the migration approach.

Hope this helps clarify things!

Jesus Nieto

Thanks @Sami Shaik, this is incredibly helpful!

You've highlighted exactly what concerns me: native Confluence features cover individual needs, but combining consistent metadata, cross-space reporting, and long-term auditing seems to require quite a bit of manual maintenance.

The lack of schema enforcement and centralized change tracking are particularly concerning at scale.

Really appreciate the detailed breakdown!

Jesus Nieto

Wow, @Mia Tamm _Simpleasyty_! This looks really promising!

The migration from Page Properties is particularly interesting. Being able to introduce structured metadata without rebuilding everything manually could make a huge difference for larger Confluence environments.

I'm definitely going to give Simple Metadata a try. If it works as demonstrated, I can see myself recommending it to other teams facing similar challenges.

Thanks for sharing this!

Levente Szabo _Midori_

@Jesus Nieto

I’d split the problem by where the values come from. A good share of what teams put into Page Properties is lifecycle metadata: owner, status, review date, when the page was last really updated. Those fields drift because someone has to type them. I think they’re better calculated than entered, and then only the business fields (product, region, customer and so on) need a schema and a form.

That lifecycle part is what Better Content Archiving and Analytics covers on Confluence Cloud:

Page status updates itself from rules you set per space, for example “Expired” after 365 days without an edit in one space and 730 in another. Owners set on a parent page apply to the whole page tree.
Status, owners, expiration, views and updates are stored as content properties on the page itself and exposed as CQL fields, so a single CQL query reports across all spaces without a label or a macro on every page.
The Content Status report shows how the status distribution changes over time, for the whole site or a single space.

For the business fields, the approaches above still apply. This just takes the lifecycle fields off that list.

I’m one of the people at Midori building this, so feel free to drop me a line at levente.szabo@midori-global.com if you want to talk through which of your fields could be calculated instead of typed.

CelesteCS

Hi, I'm Alexey 'Ce' from CelesteCS, the vendor of the app below.

On your second point, reporting: if you keep Page Properties on the pages (templates with labels, as Ciro described), the report side doesn't have to stay as limited as the Page Properties Report. Our Reporting for Confluence (Cloud and Data Center) has a Page Properties Data Provider that reads the same tables and turns them into a report that can calculate:

pages selected by labels and spaces (several spaces in one report) or by any CQL
every key becomes a column, CurrentItem.properties.Budget, with numbers, currencies and dates typed, so you can sort by them
calculated columns, footer totals and highlighted rows
filters for readers: a search box and column filters for everyone who views the page

To be clear about what it doesn't do: it doesn't enforce a schema or keep a history of the values, so for your first and third points a metadata app or Databases remain the options.

Configuration: A Page Properties report with totals, formulas and sorting. The app: CelesteCS Reporting for Confluence (free trial, Cloud and Data Center).

Monika Ambrozowicz_Seibert_

Hi @Jesus Nieto, our clients use a marketplace app called Properties. As you said, Page Properties do the job with collecting page-attached metadata that rolls up into reports, but the fields are free-text only (so no dropdowns, date pickers, or user pickers…), and keeping the schema consistent across many pages relies entirely on people not deviating from the template. And as we know, people tend to do exactly that.

With Properties you define a Property Group, which is a reusable bundle of structured typed fields (text, dropdown, multi-select, date, user picker, status, and more) built with a drag-and-drop editor.

On the reporting side, a Property Report can pull from pages across spaces in a single view, (and filtering by label, ancestor, space, or specific pages) and the report supports inline editing, so you can update a field value directly in the report without opening the source page.

For the 'tracking changes' question, Properties keeps a version log recording who changed which field and when, which is useful when the same metadata (owner, review date, status) is evolving across a large set of pages.

Let me know if you have any questions, I'd be happy to answer them or show you around. I am affiliated with the team behind Properties, and I talked to many users for whom it works much better than native macros on Confluence.

Jesus Nieto

Hi @Monika Ambrozowicz_Seibert_,

Thanks for sharing this! Properties looks really promising, especially the reusable field groups, inline editing, and version history. Those are definitely important improvements over native Page Properties.

I think what I'm looking for goes a little further, though.

It's not just about collecting structured metadata and displaying it in reports, but also about what we can actually do with that data afterwards.

For example, imagine having hundreds of project pages across different spaces. I'd love to be able to group them by department, combine different filters, calculate metrics, and identify patterns without exporting everything to Excel.

The idea is to turn metadata into something teams can actively use to make decisions, rather than just information attached to pages.

Does Properties support that kind of data analysis within Confluence?

Thanks again for sharing your approach!

CelesteCS

Hi, I'm Alexey 'Ce' from CelesteCS (the vendor of the reporting app I mentioned above).

@Jesus Nieto , on "what we can do with the data afterwards", here is how far our Reporting for Confluence goes with Page Properties today, so you can judge whether it fits:

Combine filters: one report can select pages by labels and spaces, or by any CQL (e.g. space in (PRJ, OPS) and label = project and lastmodified > now("-90d")), and then filter on the values themselves, e.g. only projects where CurrentItem.properties.Status is "At risk" and the budget is over 50,000.
Calculate metrics: calculated columns per page (budget used %, days to deadline, days since the last update), plus totals in the footer (sum, count, average).
See patterns: sort by department, budget or date, and highlight the rows that match a condition (overdue, over budget, missing owner), so the outliers stand out without exporting anything.
Let readers slice it: with filters for readers, everyone who views the page gets a search box, column filters and sorting.

What it doesn't have (yet) is a pivot or group-by with subtotals in one table. Today the per-department view is either a report sorted by department, or a few small reports on one page, one per department, each with its own totals.

Examples: A Page Properties report with totals, formulas and sorting and Filtering Page Properties: open projects by due date.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence-cloud

metadata