Confluence Page Properties Report Multiple Rows -

The need to display multiple rows from a Page Properties Report is one of Confluence’s most frequent power-user requests. While the native tool isn’t built for this, you have several viable paths:

| Method | Best For | Native? | Complexity | |--------|----------|---------|-------------| | One page per row | Scalable, clean data | Yes | Low | | Multiple macros per page | Small, fixed datasets | Yes | Medium | | Confluence Databases (Premium) | Modern teams, large data | Yes (new) | Low | | Marketplace add-ons | Legacy Confluence without Premium | No | Medium |

Final recommendation:

Don’t force Confluence to be Excel. Instead, understand its page-based architecture and work with it – not against it. Once you master these patterns, you’ll build dynamic, multi-row dashboards that impress your team and simplify your workflows.

Next steps:
Try the “one page per row” method today. Create a template, build three child pages, and run a Page Properties Report. Then, explore Confluence Databases if available. You’ll never ask “how do I get multiple rows?” again.

Have a unique use case? Share it in the Atlassian Community forums – the collective wisdom of Confluence admins is unmatched.

In Confluence, the Page Properties Report macro is designed to display one row per page.

If you insert a table with multiple data rows inside a single Page Properties

macro, the report will generally only display the first row of that table Atlassian Community

To successfully report on multiple sets of data from one or more pages, use the following methods: 1. The "Multiple Macros" Approach

If you need to report on multiple distinct items from a single page (e.g., three different project milestones), you can use multiple Page Properties macros on that page. Atlassian Community : Place each data set in its own Page Properties Assign IDs : In the macro settings for each, assign a unique Page Properties ID Page Properties Report

macro, you can choose to show all properties with a specific label, or filter by a specific ID to isolate certain rows. Atlassian Documentation 2. Restructuring for Key/Value Pairs

Duplicated rows in page properties report - Atlassian Community confluence page properties report multiple rows

In Confluence, the Page Properties Report macro is designed to display exactly one row per source page

. If a table inside a Page Properties macro has multiple data rows, the report will only pull the first one by default. Atlassian Community

Depending on your goal, here is how to handle or fix "multiple rows": 1. How to get multiple rows from one page

If you need to report on multiple distinct items from a single page, you must use a workaround:

Page Properties Report Not Showing All - Atlassian Community

The simplest native solution is counterintuitive: Don’t put multiple rows on one page. Create one page per row, and then use labels and the Page Properties Report to group them.

If you absolutely must use the native Page Properties macro and cannot flatten your data, some users employ visual cheats, though these are unstable.

One method involves formatting the cell data. Instead of using multiple table rows, users use line breaks (<br>) or bullet lists within a single table cell.

Example:

The report will pull this as one massive text block. While it keeps the data together, it destroys your ability to sort or filter by individual skills.

Summary

Why multiple rows is requested

Behavior and constraints

Workarounds and patterns

Implementation checklist (one-per-child approach)

Tips and best practices

Recommended next steps

Before we solve the problem, let’s clarify the default behavior.

Example of the limitation:
You have a page called “Q1 Goals.” Inside the Page Properties macro, you list three goals in three separate rows. When you run a report from another page, Confluence will only show one row (the first one) from the “Q1 Goals” page. The other two are invisible to the report.

This is by design. Confluence treats each page as a single entity, not a spreadsheet. The need to display multiple rows from a

These add-ons generally cost $10–$50/year for small teams and are worth it if you run operational dashboards.

Inside the single “value” cell, you can write:

- Item 1
- Item 2
- Item 3

In list mode, the Page Properties Report will render these as a bullet list for that page. It’s still one row per page, but the row contains multiple lines.

Use case: Good for notes, comments, or bullet-point lists. Bad for structured data you want to sort or filter (e.g., by priority or date).

The standard Page Properties Report is an exercise in reductionism. It takes the complex, messy narrative of a wiki page—a tapestry of prose, images, and threaded comments—and flattens it into a single row. One page, one row. This is the "Sovereign Row."

The chaos of "multiple rows" emerges when we attempt to defy this sovereignty. This manifests in two distinct dimensions, each revealing a flaw in our digital metaphysics.

1. The Unwillingness of the Mirror (Data Duplication) Often, the user desires a single row to represent a project, a team, or a component. Yet, the report multiplies. A single page spawns three, four, ten rows. Why? Because the underlying data structure is mocking our desire for cleanliness.

When a Page Properties Report pulls from multiple macros on a single page, or when it detects a list within a property cell that it cannot aggregate, the "One-to-One" covenant is broken. The report does not summarize; it explodes. The page loses its integrity as a unit of measure. The "Project Alpha" page is no longer a singular entity; it is fragmented into "Project Alpha (Status: Red)," "Project Alpha (Status: Yellow)," and "Project Alpha (Status: Green)"—a Schrödinger's project existing in all states simultaneously across the rows. The user sees not a summary, but a stuttering echo of their own data entry errors or structural indecision.

2. The Desire for the Relational (The Phantom Row) Conversely, users often want multiple rows from a single page. They wish to treat a Confluence page not as a document, but as a database table. They want the "Meeting Notes" page to spawn five rows in a report—one for each action item, one for each attendee.

Here, the Page Properties Report reveals its rigidity. It is a tool built for documents, not databases. Unlike a true relational database where a parent record can spawn child records in a view, the Page Properties macro is bound by the page boundary. To achieve "multiple rows" here, one must fracture the knowledge base itself—creating five separate "dummy" pages just to satisfy the report's hunger for single-row inputs. We destroy the cohesion of the narrative to feed the machine the rows it demands. Don’t force Confluence to be Excel