Confluence Databases: Column-level permissions / sharing limited views with broader audience

Question

Hi everyone,

I have a specific use case regarding the new Confluence Databases feature in Confluence Cloud, and I am hitting a major roadblock regarding permissions.

My Use Case:

I have a master database with 5 columns located on a page within our space. This page and the database contain sensitive data, so access is strictly restricted to a specific group of users (e.g., HR / Management).

I want to display only 3 of those columns on another page within the same space and share it with a broader audience (all users in the space). The wider audience should only see the non-sensitive data, and any updates made to the master database should automatically reflect in this public view.

The Issue:

I noticed that Confluence Databases allow us to create custom views and hide columns. However, this is purely cosmetic. If a user does not have permission to access the original master database page, the embedded view on the public page throws a permission error and loads nothing.

On the other hand, if I grant them access to the database so they can see the embedded view, they can easily modify the view settings, unhide the restricted columns, or just navigate to the master page.

This completely defeats the purpose of hiding columns for security or privacy reasons. It seems impossible to share a restricted/filtered dataset natively without exposing the entire database.

My Questions:

* Is there any native way to enforce column-level permissions or safely share a "read-only filtered mirror" of a database with users who don't have access to the source?
* Are there any plans on the Atlassian roadmap to support decoupling view permissions from the master database permissions?
* If this is not natively possible, is there an official workaround that doesn't involve buying third-party Marketplace apps?

Any advice or workarounds from the community or the Atlassian product team would be highly appreciated!

Thanks!

Daniel Brooks · Answer

Adding one practical test and one workflow we use for this exact pattern.

The test: before trusting any embed or view trick, log in as a test user who only has access to the shared page and try to reach the two hidden columns outside the view — through search, through printing or exporting the page, and by opening the database from the embedded view. In our experience the data is still reachable by at least one of those routes, because the permission sits on the database and page, not on the fields. So treat hidden columns as fully visible to that audience, even for mildly sensitive data like personal email addresses or internal costs.

The workflow: if the three shared columns change slowly, publish a snapshot instead of a live view. Keep the master database restricted, and keep a second, public database that only ever contains the safe fields. When you update the master, refresh the public copy (export the master, delete the two sensitive columns from the file, then import it into the public database) and stamp the public page with a line like "Data as of 12 October — owner: Scha" so readers know it is a snapshot, not live data. It is a bit manual, but there is no moment where the sensitive columns are exposed, which the live embed cannot promise.

If the data changes daily, that manual step quickly becomes the real cost, and at that point I would move the sensitive fields out into their own restricted database and let the shared database be the live one, rather than the other way round.

Mia Tamm _Simpleasyty_ · Answer

Hey @Scha Rowo vave you considered whether you actually need a Confluence Database for this use case?

Mia here from Simpleasyty. Depending on how you manage the information, there are two approaches worth considering.

If your main goal is to present tabular data with configurable columns and views, Simple Tables might be a simpler alternative.

If you need structured information that can be maintained over time, Simple Metadata could be a better fit. It supports reusable schemas, reporting across pages, and an audit history of changes, which can be particularly useful when you need to track who changed what and when.

One important caveat: hiding fields in a view is not the same as enforcing field-level security. If those two columns contain genuinely restricted information, the underlying access permissions still need to be addressed.

It really comes down to whether you're primarily looking for a filtered view or a structured way to manage and track the information over time.

Scha Rowo · Answer

Thank you for the insights! After a technical deep dive (inspecting the DOM and trying to build a Forge app), I can confirm that Confluence Databases are encapsulated inside an <iframe>. The rows don't exist in the page storage format, and the REST API returns empty arrays for rows. Secure filtering at the server level is technically impossible.

Databases are great, but the lack of granular permission management makes them useless when sensitive data is involved.

It would be great if at least a simple option was available as a workaround, like generating a read-only flat table snapshot from selected database columns.