From Page Properties to a real reporting workspace in Confluence

[#1]

Hi, I'm Mia Tamm from Simpleasyty, the team behind Simple Tables for Confluence. In this article I want to show a practical way to get considerably more value from existing Page Properties without changing the way teams maintain their Confluence content.

If your organization has been using Confluence for a while, there is a good chance that a significant amount of structured information already lives across your pages. Owners, statuses, teams, priorities, risks, target dates, budgets, regions and other operational attributes are often maintained directly alongside the content they describe.

For many teams, Page Properties have been one of the simplest ways to create that structure. A project page contains the project information, a system page describes the system, and a policy page contains the properties associated with that policy. That model is useful because the information stays close to the content and remains owned by the teams that maintain it.

The interesting question is what happens next. What if the Page Properties you already have could become an interactive reporting layer without migrating the information, rebuilding existing pages or introducing another dataset for users to maintain?

That is one of the use cases we have been building into Simple Tables for Confluence.

Start with the structure you already have

In this example, Northstar Engineering manages each engineering initiative on its own Confluence page. The project teams maintain information such as owner, program, team, plant, delivery stage, status, priority, risk, progress, target date and budget directly on the page using Page Properties.

The important point is that this workflow does not need to change. Each team can continue owning and updating its project page exactly as before. The structured information already exists, the conventions are already understood, and the organization may already have years of templates and processes built around them.

Here we are simply looking at an existing project page and the Page Properties it already contains. The label provides the common structure that allows related project pages to be identified together.

Turn those pages into a portfolio

Now create a new Confluence page, insert Simple Tables, open the integrations section and choose Page Properties. Select the same label and Simple Tables immediately discovers the matching pages and brings their properties together into a single table.

There is no intermediate spreadsheet, no CSV import and no second copy of the information to synchronize. The individual Confluence pages remain the source of truth; the portfolio is simply another way of looking at them.

That distinction matters in larger environments. A new reporting capability is much easier to introduce when it does not also require a migration programme, a new authoring model or retraining hundreds of users.

At this point, we have intentionally done almost nothing to the presentation. The goal is to show how quickly existing Page Properties can become a working dataset before any styling or reporting logic is added.

The source stays the same. The presentation does not have to.

Once the data is available, each column can be configured independently. A raw Page Properties report often contains information that is technically correct but not particularly easy to scan. Status, risk, priority and team information become much more useful when they are presented consistently and visually.

Simple Tables lets the author define how individual values should appear without changing the data on the original project pages. In this example, enum values are given clear visual treatments so that delivery states, priorities and risk levels can be understood at a glance.

This is particularly useful in operational reviews, where users should be able to identify an At Risk or Blocked initiative immediately rather than reading every cell individually.

Make dense enterprise data easier to read

Presentation becomes increasingly important as the number of columns grows. Not every field needs the same width or alignment, and an enterprise portfolio can quickly become difficult to consume if every column is treated identically.

Columns can therefore be resized, aligned and formatted to fit the information they contain. Narrow identifiers and compact status fields can take less space, while descriptive or numerical columns can be given the room they need. The result is a much denser portfolio without sacrificing readability.

The underlying Page Properties have not changed. Only the way the portfolio presents them has.

A report users can actually interrogate

A portfolio becomes much more useful when viewers can ask questions of it directly. Instead of creating another report page every time someone wants a slightly different answer, users can filter the information themselves from the published Confluence page.

For example, an engineering lead may want to see all projects where Status = At Risk and then narrow the result further to Risk = High. Another user might combine different conditions depending on the review they are running.

This changes the nature of the report. It no longer needs to anticipate every possible question in advance; the reader can explore the dataset according to the context of the conversation.

Derive information without asking every page owner to maintain another field

Some of the most useful operational information does not need to exist as another Page Property at all. A project page may already contain a target date, for example, while the real management question is how many days remain until that date.

Calculated columns allow that information to be created at the reporting layer. In this example, a new Days Remaining column is calculated from the existing target date and then formatted so that the resulting values are easier to interpret.

The original project pages remain untouched. The source continues to describe the project, while the portfolio derives additional information that is useful specifically for reporting and decision-making.

This pattern can be applied beyond dates. Existing fields can be combined into operational indicators, variances or other derived values without adding more manual maintenance to every source page.

From a list of projects to a portfolio

Once dozens or hundreds of initiatives are brought together, grouping becomes one of the simplest ways to understand the structure of the dataset. Projects can be grouped by status, program, team, plant, region or any other relevant field.

In this example, grouping is enabled from the display configuration and then applied directly to the project portfolio. The same set of Page Properties immediately becomes easier to navigate as a portfolio rather than a flat list.

The important idea is that grouping does not create another report or another dataset. It is simply a different way of asking a question of the same information.

When numbers start behaving like numbers

Budget is another good example of how Page Properties can become much more valuable when the reporting layer understands the type of information it contains. Displaying a budget value on each project page is useful, but aggregating those values at portfolio level answers a different class of question.

Once the portfolio is grouped, the Budget column can calculate totals and averages for each group. An engineering portfolio can therefore answer questions such as how much investment sits within a program, what the average project budget is, or how financial exposure is distributed across different parts of the organization.

This is where a collection of Page Properties begins to behave much more like operational reporting. The information is still maintained on individual Confluence pages, but the portfolio can now perform calculations across the entire set.

Different audiences do not need to see the same thing

An enterprise portfolio often contains information that is useful to one audience but unnecessary or sensitive for another. A detailed engineering workspace might expose every operational field, while an executive or external-facing view may only need a subset.

Columns can be hidden from the final view without removing them from the source. Sensitive numerical information can also be protected using confidential or incognito-style presentation, allowing the author to control how values such as budgets appear to viewers.

This separation between source information and presentation is particularly important in enterprise environments, where the same underlying dataset may need to support multiple audiences with different levels of detail.

Control what viewers can do with the final portfolio

The last step is deciding how the published table should behave. The author can expose only the capabilities that make sense for that page, including search, filtering, sorting, grouping, full-screen exploration and export.

Simple Tables also supports a confidential indicator for sensitive datasets, and the resulting portfolio can be downloaded as XLSX when the information needs to continue into another business workflow.

Once configured, the complexity largely disappears for the viewer. They simply open the Confluence page and work with the portfolio that has been designed for them.

Why this becomes interesting at enterprise scale

With ten project pages, Page Properties are a useful convenience. With hundreds or thousands of consistently structured pages, something much more interesting happens: the organization has effectively created a distributed information layer across Confluence.

Projects are only one example. The same pattern can apply to applications, systems, products, vendors, policies, controls, risks, architecture decisions, security reviews and many other types of content already maintained in Confluence.

If those pages contain consistent properties, the information can be aggregated. Once aggregated, it can be searched, filtered, formatted, calculated, grouped and summarized without moving the source information somewhere else.

This can help reduce a familiar enterprise problem. When structured information becomes difficult to work with inside its original system, copies start appearing elsewhere: spreadsheets, exported snapshots, parallel dashboards and manually maintained reports. Before long, several versions of the same information exist.

Keep Confluence as the source. Make the information more useful where it already lives.

That is the principle behind this approach. The teams that own the information continue maintaining it on the pages where it belongs, while reporting pages can provide richer and more specialized views over the same data.

Why this is also interesting for Atlassian partners

Partners frequently encounter customers with years of Confluence content, established templates and deeply embedded internal processes. In those environments, replacing the content model can be technically possible but organizationally expensive. A reporting improvement can quickly turn into a migration project involving retraining, documentation changes and adoption work.

Working with existing Page Properties creates a different starting point. Rather than beginning with “we need to move your information”, the conversation can begin with a much more useful question: “Show us how your teams are using Confluence today.”

If the structure already exists, partners can build portfolio views, governance reports, financial overviews, risk reviews and other customer-specific experiences on top of the customer's existing information. That makes it possible to deliver new reporting value without requiring the customer to start again.

For organizations with years of Page Properties already in production, this can unlock a considerable amount of existing investment.

The bigger idea

We have focused on Page Properties here because they make the pattern particularly easy to understand, but the broader idea behind Simple Tables is that structured information inside Confluence should be something users can work with, not something they can only display.

If your organization already uses Page Properties, one useful exercise is to take an existing reporting use case and ask three questions: what information do we already have, what questions do different audiences need to answer, and how much of that can be achieved without changing the original content model?

You may find that the information needed for a much richer reporting experience is already there.

Disclosure: I'm Mia Tamm from Simpleasyty, the team that develops Simple Tables for Confluence.

If you'd like to explore the app used in the examples above, you can find Simple Tables for Confluence on the Atlassian Marketplace.