Regression in usability: Custom fields grouped by project break cross-project workflows

Hi all,

I’d like to raise a concern about the recent change where custom fields are now grouped strictly by project.

In our workflow, tasks frequently belong to multiple projects, each with its own set of fields. Previously, we had a unified view of all relevant fields in one place, which made it easy to understand the full context of a task across boards.

With the current behavior, fields are segmented by project, forcing us to open and navigate into each project individually to access its data. This introduces several issues:

  • Significant loss of visibility across projects

  • Increased cognitive load when analyzing tasks

  • More time spent navigating instead of working

  • Higher risk of missing critical information

Importantly, duplicating fields across projects is not a viable workaround. These fields are intentionally scoped to specific teams or contexts, and replicating them would create governance and data consistency issues.

For teams that rely on cross-project workflows, this change feels like a clear regression in usability and efficiency.

Is this the intended long-term direction? And are there any plans to restore a unified view of fields or provide an aggregated option for multi-project tasks?

Would love to hear if others are experiencing the same impact.

2 Likes

4 posts were merged into an existing topic: Updated view of projects and custom fields within tasks needs improving