Task report filtering based on page label is no longer working

[Jo-Lee Bertrand]

We extensively use the task report and filter by page labels. At around 9:30am today (August 13th, 2026), this just stopped working altogether. This has happened across multiple spaces. Anyone else experiencing this?

[Mia Tamm _Simpleasyty_]

Hi @Jo-Lee Bertrand that definitely sounds like something that may have changed on the Confluence side if it stopped working across multiple spaces at exactly the same time.

Out of curiosity, are you mainly using the Task Report to:

• find tasks contained in pages with a specific label, or

• use the page label itself as the main way of building the report?

I'm asking because we've been working on alternative ways of building Confluence reports based on Confluence content and page metadata, and your use case sounds very interesting.

If you can share a little more about what the final report normally looks like, I'd be happy to see whether there is another way to reproduce it while this issue is being investigated.

[Jo-Lee Bertrand]

we label pages and then use that label to pull items from those pages using the label filter so we have action items captured (so for a series of meetings). All of our meeting actions now across a large project are broken. It's a major issue. 

[Mia Tamm _Simpleasyty_]

Thanks again for explaining the workflow, @Jo-Lee Bertrand  The more I think about your use case, the more I wonder whether there may be a more powerful way of structuring this than relying entirely on Task Report.

This is actually very close to an integration we're currently finalising between Simple Tables and Confluence Page Properties, and I wanted to show you the approach because it may be useful for the type of project and meeting reporting you described.

The core idea is quite simple:

Your individual Confluence pages remain the source of truth, but the important information inside those pages becomes structured data that can be reused in consolidated reports.

Start with a consistent page structure

One of the most powerful parts of this approach is that you can use Confluence templates.

For example, every new project page could be created from the same template and automatically include a standard Page Properties section with fields such as:

• Owner
• Program
• Team
• Plant
• Stage
• Status
• Priority
• Risk
• Progress
• Target date
• Budget
• Last review

For meeting pages, the structure could be different and more aligned with the way you work:

• Meeting date
• Project
• Meeting owner
• Overall status
• Next action
• Action owner
• Due date
• Priority
• Risk
• Last reviewed

The advantage is that people don't have to remember how reporting should be structured every time they create a page. The template establishes that structure from the beginning.

One source of truth, multiple views: teams maintain their individual project pages as usual, while Simple Tables can consolidate their structured Page Properties into dedicated reporting pages such as the Engineering Portfolio.

The page structure itself can remain very simple.

In the example I'm attaching, the engineering team has several independent pages under Projects:

• Battery Cooling System
• Vision Sensor Platform
• Factory Line Automation
• Energy Optimization

And separately, under Reports, there is an Engineering Portfolio page.

The project teams continue maintaining their individual pages as normal, while the Portfolio page becomes the consolidated operational view.

There is no need to manually duplicate all of that project information into a separate spreadsheet or reporting page.

Each page keeps its normal Confluence content

For example, one of those project pages is Battery Cooling System.

The page still contains the normal content you would expect from a Confluence project page:

• overview
• current status
• milestones
• latest updates
• decisions
• supporting documentation

But it also contains a structured Page Properties section.

In this example, the Page Properties contain:

• Owner: Ana Keller
• Program: EV Platform
• Team: Thermal Systems
• Plant: Stuttgart
• Stage: Validation
• Status: At Risk
• Priority: P0
• Risk: High
• Progress: 68%
• Target date: Oct 8, 2026
• Budget: 490000
• Last review: Aug 4, 2026

This is important because the Page Properties don't replace the page.

The project page is still where people work and document the project.

The properties simply expose the pieces of information that are useful for reporting in a consistent, structured way.

Then Simple Tables can bring those pages together

This is where the approach becomes much more powerful.

Simple Tables can take the Page Properties from multiple Confluence pages and consolidate them into a single table.

In the example I'm attaching, the Engineering Portfolio brings together the information from:

• Factory Line Automation
• Energy Optimization
• Battery Cooling System
• Vision Sensor Platform

Each row represents an individual Confluence page.

The columns come from the Page Properties maintained on those pages.

So instead of opening four different pages to understand the current situation, you can have one operational view containing:

• Title
• Program
• Owner
• Stage
• Status
• Priority
• Risk
• Progress
• Target date
• Last review
• Budget

And this is where it starts to become much more than a standard Page Properties report.

Simple Tables can add a reporting layer on top

Once those properties are inside Simple Tables, you can use the normal capabilities of the table to analyse and explore the information.

For example:

• search across all projects
• sort by status, owner, risk or target date
• filter the information
• focus only on At Risk or Blocked projects
• compare teams or programs
• create management views
• create operational views
• aggregate numerical data

You are no longer limited to simply displaying the values that exist in Page Properties.

You can also derive new information from them.

For example, in the screenshot there is a Days to target column.

That value doesn't have to be maintained manually on every project page.

The individual page only needs to contain the Target date.

Simple Tables can calculate the remaining number of days automatically.

• Aug 21 becomes 7 days remaining
• Sep 4 becomes 21 days
• Oct 8 becomes 55 days
• Nov 12 becomes 90 days

The same idea could be applied to other calculated information, depending on the use case:

• days overdue
• time since last review
• budget remaining
• budget variance
• completion indicators
• SLA windows
• project ageing
• review deadlines

You can also aggregate the information

The report doesn't only need to work at row level.

In our example, each individual project maintains its own Budget value.

Simple Tables can aggregate that information and show the total portfolio budget.

In the screenshot, the four individual projects produce a consolidated total of €2.7M.

That means the same information maintained by individual teams can also become useful at portfolio or management level without maintaining another dataset.

The same source pages can support different reports

This is probably one of the most interesting parts of the approach.

You don't necessarily need one single report.

The same Page Properties could feed different views for different audiences.

For example, a management report could focus on:

• Status
• Risk
• Progress
• Target date
• Budget

A team lead report could focus on:

• Owner
• Priority
• Status
• Due date
• Last review

A risk review could show only:

• At Risk projects
• Blocked projects
• High / Critical risk
• upcoming target dates

And another report could concentrate on one specific program, team or owner.

The underlying project pages remain exactly the same.

You are simply creating different reporting views over the same structured information.

This changes the reporting model quite a lot

Instead of thinking only in terms of:

• meeting pages → native tasks → Task Report

you can start thinking in terms of:

• templates → consistent Confluence pages → Page Properties → Simple Tables → operational reports

The individual Confluence pages become the place where information is created and maintained.

Page Properties provide the structure.

Simple Tables becomes the reporting and analysis layer on top.

That also reduces the need to make the entire reporting process depend on one specific native macro.

There is one important difference with your current Task Report workflow

I don't want to suggest that this is a 1:1 replacement for what Task Report is currently doing for you.

If every meeting page contains several native Confluence action items and your requirement is specifically to extract every individual checkbox/task from those pages as separate rows, that is a different scenario.

Page Properties are particularly powerful for structured information associated with the page itself.

But if a significant part of what you're trying to achieve is maintaining a reliable project or meeting reporting layer across a large number of pages, I think this model could give you considerably more control.

In fact, looking at the workflow you described, one question I would genuinely ask is:

Does all of the reporting need to depend on Task Report, or could some of the information you're currently extracting from meeting pages be better represented as structured Page Properties?

That would allow the underlying information to remain available even if you decide to change how the final report is presented later.

The screenshots I'm attaching show the approach we're currently finalising in Simple Tables.

The Page Properties integration is not publicly available yet, but this is coming shortly.

Your use case is particularly interesting to us because it is exactly the type of Confluence reporting problem we're trying to make much easier.

[Jo-Lee Bertrand]

This won't work for us. As a public entity, we cannot buy add-ons. We need the broken thing fixed.

[Mia Tamm _Simpleasyty_]

Hey @Jo-Lee Bertrand Simple Tables is free. 

[Jo-Lee Bertrand]

Hello - cost is not the issue. For every add on we need intense approvals and it won't happen quickly. What needs to happen is for the broken thing to be fixed.