+1 on this. Right now Relationship fields can only be created at the List level, which forces me to manually recreate the same field in every List where I need it. The bigger issue isn't just the extra setup work — each recreated field is isolated, so they're not actually the "same" shared field, just separate ones with no connection to each other. That breaks consistency across tasks in related projects.

It would help a lot if Relationship fields worked more like Notion's relations: defined once and reusable across any List/Space in the Workspace, keeping a real link between tasks no matter where the field is used. That would remove the duplicate setup, keep reporting consistent, and make the feature genuinely usable for anyone managing multiple connected projects.

Can we get an update on this? It's essential. Our use case—running an arts organisation where we need to be able to link artists, partners, venues and suppliers across the whole workspace through relationship fields. Hugely messy and basically impossible with single-list relationship fields.

I manage a portfolio of industrial refrigeration equipment manufacturing projects. For each new sale, I create a Subfolder (called "Activation") containing two separate lists — one for the Factory team and one for the Infrastructure team — so each team only sees their own tasks.

Both lists need a Relationship field pointing to the same Installation record (a master list that tracks each unique equipment + client combination). Right now, I have to manually create a separate Relationship field in each list, for every single Activation. With 10+ simultaneous projects, that means 20+ Relationship fields created by hand — each isolated, inconsistent, and impossible to manage cleanly in Dashboards.

If Relationship fields could be defined at the Space or Folder level and inherited by all lists underneath, this entire problem disappears. One field, one source of truth, consistent Dashboard reporting across the whole portfolio.

This is not a edge case — it's a fundamental pattern for any operation that runs parallel workstreams under a single project umbrella. Please prioritize this.

That’s a smart way to structure data, having relationship fields at higher levels would definitely streamline workflows and avoid repetitive setup, much like how organized systems (even niche ones like dog relocation services canada https://pearllemonpets.ca/services/dog-relocation/) rely on centralized control for consistency. It would make scaling and maintaining these connections far more intuitive.

Hi everyone,

I’d like to reinforce this request with a concrete use case.

We’re building a “Lessons Learned” database and need to link each lesson to its corresponding project. In our setup, projects are structured at the Folder level, but Relationships only allow linking to tasks.

This forces us to use workarounds (dropdowns, URLs, proxy tasks), which don’t scale and don’t reflect the real structure.

In tools like Notion, relations make it much easier to connect knowledge with higher-level entities like projects.

It would be extremely valuable to allow Relationship fields to reference:

I’m sure we are all suffering from the same issue.

I’d like to add a concrete real-world use case to this request, as I’m currently facing this limitation in production.

In our setup, a List represents a Project, while tasks and subtasks represent the WBS. This is a very common project management model, especially when projects are imported or synchronized from an external system (ERP / internal portal).

Attributes such as Client, Project ownership, or other portfolio-level metadata logically belong to the Project itself, not to every single task.

Today, because Relationship fields can only be constrained to a specific list at task level, users are forced to:

• recreate the same relationship field on every project list

• introduce artificial “project tasks” only to host metadata

• or duplicate data purely for reporting purposes

Allowing custom fields and relationship fields at Space / Folder / Workspace level, or directly at List level as a first-class entity, would dramatically improve:

• portfolio reporting

• client-based project views

• governance and data consistency

This would enable ClickUp to better support project-centric models without forcing structural workarounds that don’t reflect how projects actually work.