Applying a large number of properties to features?

Hi @Chris, I think it makes a lot of sense to centralize as much as possible into Confluence. Atlassian's focus seems to be bringing Jira and Confluence closer together, especially thanks to Rovo; and finally there are marketplace apps that create links and fill the gaps in native capabilities. 

Confluence databases are definitely worth exploring. They can handle structured, tabular data with typed fields (text, number, date, user, etc.), and you can create multiple views with different column sets and filters. They're definitely a very good alternative to spreadsheets.

For 30-50 properties per feature, however, you'll hit a few practical limits worth knowing about up front. Database views are defined globally on the database itself, so if you embed the same database on multiple pages and want each page to show a different filtered slice of the data, that's not currently possible - every embed reflects the same view with the same filters. 

If you're open to a Marketplace app, I'd recommend taking a look at Properties. The approach Properties takes is slightly different from Databases: instead of a standalone data table, you define a "Property Group", a reusable schema of typed fields (text, dropdown, multi-select, user picker, date, status), and attach it directly to your Confluence pages, one page per feature or module. Your property groups can be displayed on Confluence pages or live behind the byline item - that is completely up to you. 

Each page then carries its own structured metadata. You then pull that metadata into Property Reports, which are filterable, sortable table views that aggregate data from across any set of pages - by space, by label, by ancestor page, or across completely different spaces. It is worth noting that each report is independently configured, so you can have one report showing only permissions-related columns filtered to a specific module, and another showing feature flag properties for a different team, all reading from the same underlying page data.

For your 30-50 property use case, this means you'd define the full schema once in a Property Group, apply it to a page template, and every feature page created from that template inherits the same fields.

I work with the team behind the app so if you have any questions or if you'd like to have a personalized demo, please don't hesitate to reach out. 

So an update - i found databases to be pretty slow and not fully fledged enough to work well. I experimented with Page properties and labels but these approaches have too many drawbacks. So for now we will stick with the spreadsheet and link there where we need to. 

Hey @Chris ,

As others pointed out, when looking natively, databases would be the 'best bet.'

Depending on the details of the use case, did you maybe think about using Assets to store values/data such as permissions, feature flags, etc.? We do have/know a couple of clients who extensively use Assets for pretty much everything. Although it's debatable if they're maybe overdoing it or not 😅

Cheers,
Tobi

Hi @Chris, both of the things you floated exist. They're different features though, and they don't compose, so it's one or the other.

The second one is what I'd build. One database, then a saved view per audience, each carrying its own layout, filters, sorts and Hide fields selection, and you switch by clicking the view's tab. 30-50 columns is less of a problem than you'd think: Atlassian's wording is "a database's fields or entries are not limited", with the caveat that large ones "can take longer to load and quickly become very complex".

Your permissions grid does survive, but only on the Board layout. Click Group in the header, between Filter and Sort, set the primary Group by field for the columns, then Add subgroup to pick a second field, and you get swimlanes, which is a genuine two-dimensional board. That came with the Spring 2026 drop and the rollout has been patchy, so look for the Group button on your own site before you plan round it. The Table layout stays one row per entry, so that shape only works as a board.

The first thing you floated is the content properties report macro, which was called the page properties report macro until the rename. It takes a Columns to show parameter, so several reports pointed at the same labelled pages give you several column subsets, which is exactly what you described. Its ceiling is 30 rows a page and you can't raise it. The page-derived fields a database offers are the page link, its content status, its labels, and a details field limited to created and updated metadata plus the first excerpt macro, so nothing on that side reads a properties table. That's why picking one of the two matters.

There's no per-row calculated field though, only column-footer aggregates like sum and count. CONFCLOUD-78459, "Add support for math expressions and formulas in Confluence Databases", is Under Consideration with 80 votes. And database version history only reaches back 30 days, and a restore doesn't overwrite anything, it drops the old version into a separate new database, so your embeds keep showing the current one and you re-point them by hand.

You said the properties are set out in different groupings depending on the data. Whether that means the same 30-50 fields everywhere or a different set per grouping is what decides one database or several joined with Entry link.

Hi @Chris 

Welcome to the community.

You could look at this article on using Databases in combination with Rovo.

https://community.atlassian.com/forums/Confluence-User-Group-articles/Stop-Using-Page-Properties-Confluence-Databases-Rovo-Are-Better/ba-p/3253217