If you’ve ever wished you could connect tasks across Lists to track clients, deals, delivery projects, or billing, ClickUp offers two powerful features: Relationships and Related Items. While they sound similar, they serve different purposes and can transform how you organize, report, and navigate your workspace.
In this guide, we’ll explain what each feature is, when to use them, how to set them up, and how to avoid common pitfalls, using real-world examples.
What’s the Difference? Relationships vs Related Items
Relationships in ClickUp are structured, database-style links between tasks (often across different Lists). They’re best for building repeatable, reportable connections. For example:
- linking every Deal to an Organization
- linking every Project to an Organization
- linking Invoices to an Organization or Project
You create these as Relationship custom fields, and they support powerful extras like Rollups, which let you display or aggregate data from those linked items.
Related Items (in the Related area of the task) are designed for quick, flexible connections, not data modeling. With them you can:
- link to other tasks or docs for context
- link external URLs (e.g., client portal, Figma file)
- add dependencies (blockers / waiting on) between tasks
They’re great for navigation and context, but not for structured reporting or Rollups.
Relationships vs Related Items: Quick Comparison
| Feature | Relationships (Custom Field) | Related Items / Dependencies |
| Structured, database-style | ✅ | ❌ (ad hoc, unstructured) |
| Can display data (Rollups) | ✅ | ❌ |
| Good for reporting & dashboards | ✅ | ❌ |
| Quick, one-off linking | ⚠️ Possible, but not its strength | ✅ |
| Supports external URLs | ❌ | ✅ (via Links) |
| Can create task dependencies | ❌ (separate feature) | ✅ (Dependencies live alongside Related) |
| Best for | Data model, reporting, aggregation | References, blockers, extra context |
When to Use Relationships vs Related Items
Use Relationships when:
- You need repeatable patterns like one-to-one, one-to-many, or many-to-many
- e.g. one Organization → many Deals
- one Organization → many Projects
- one Project → many Tickets
- Tasks live in separate Lists/Spaces but must be consistently linked
- e.g. Invoices linked to the right Organization or Project
- You want to aggregate or display fields from linked items via Rollups
- e.g. total Deal value per Organization; total Invoiced amount per Project
- You want clean reporting, filters, and dashboards based on those links.
Use Related Items / Dependencies when:
- You want to quickly reference another task or doc for additional context.
- You need to set up a dependency (this task is blocking / waiting on another).
- You’re linking items for a one-off use case, not as part of your core data model.
- You don’t need to report or roll up data through that connection.
IT Visionists Example Structure
Let’s anchor everything to a simple structure.
ClickUp Lists in Our Setup:
- Organizations (companies / clients)
- Deals (sales opportunities linked to Organizations)
- Projects (delivery work per Organization)
- Invoices (billing linked to Organizations or Projects)
- Tickets (support or change requests linked to Projects)
The key design decision here:
- Projects are linked to Organizations, not to Deals.
- A Deal, when won, effectively becomes a Project but the long-term relationship is always with the Organization.
- Invoices are linked to the Organization or the Project (depending on how you bill).
- Tickets relate to the Project they’re affecting (and indirectly to the Organization via that Project).
If you are looking for a full ClickUp Guide to start with, read our full blog article on ClickUp Tutorial for Beginners.
Types of Connections (and How We Use Them)
1. Ad Hoc Links via Related Items
Example: Link a high-priority Ticket to another related Ticket, a decision log Doc, or a quick reference task.
- How: Open the Ticket → go to the Related / Links area →
- add a Task link for context, or
- add a Doc or URL link.
Best for:
- One-off connections
- Extra context (“see this spec”, “see this previous bug”)
- Dependencies like “waiting on this bug to be fixed first”
This is not meant to drive Rollups or formal reporting.
2. Relationship Custom Field (List-to-List)
Example: An “Organization” Relationship field on Deals, so each Deal is linked to exactly one Organization.
- How: Go to the Deals List → Custom Fields → Add field → Relationship
- Related List: Organizations
- Choose cardinality (one Organization per Deal, many Deals per Organization)
- Name the field “Organization”
Best for:
- Standardized, repeatable linking patterns across a whole List
- Rollups (e.g., total deal value per Organization)
- Filters and reporting (e.g., “show all Deals for this Organization”)
You can use the same pattern for:
- Projects → Organization
- Tickets → Project
- Invoices → Organization and/or Project
Are Relationships Bidirectional?
Ad hoc task links (via Related / Links):
- When you link Task A to Task B, both tasks will show the connection.
Relationship Custom Fields (List-to-List):
- When you link a Deal to an Organization using a Relationship field on Deals,
- the Deal shows its Organization field, and
- the Organization shows a reverse table of all linked Deals (e.g. “Deals”).
This reverse visibility is what makes reporting and navigation so powerful.
How to Create a Relationship: Step-by-Step
Example 1: Link Deals to Organizations
Goal: One Organization can have many Deals; each Deal links to one Organization.
- Go to the Deals List.
- Add column → Relationship → choose Organizations.
- Set it so each Deal has one Organization.
- Name the field “Organization”.
- Bulk-link existing Deals by filling in the Organization column.
Now, on any Organization task, you’ll see all its Deals in a Relationship table.
Example 2: Link Organizations to Projects
Goal: Each Project belongs to an Organization; an Organization can have multiple Projects.
- Go to the Projects List.
- Add column → Relationship → choose Organizations.
- Name it “Organization” (keep naming consistent).
On any Organization, you’ll see a list of its Projects.
Example 3: Link Invoices to Organizations and/or Projects
Goal: Track billing by client and/or by project.
- Go to the Invoices List.
- Add column → Relationship → choose Organizations.
- Name it “Organization”.
- (Optional) Add another Relationship → choose Projects.
- Name it “Project”.
- This lets you report:
- total invoiced per Organization
- total invoiced per Project
Real-World Relationship Patterns That Work
- Organization ↔ Deals (one-to-many):
View all Deals per Organization; Rollup total Deal value, expected close, etc.
- Organization ↔ Projects (one-to-many):
See all active and completed Projects per client.
- Project ↔ Tickets (one-to-many):
Track support / changes against each delivery project; Rollup time tracked.
- Organization / Project ↔ Invoices (one-to-many):
Track billed vs booked work at client and project level.
Notice:
- Deals are primarily linked to Organizations.
- Projects are linked to Organizations (and can optionally relate back to the closing Deal if needed, but not as the main relationship).
Common Pitfalls (and Fixes)
Pitfall 1: Using subtasks to model cross-list relationships.
- e.g. making Projects subtasks of Deals, or Invoices subtasks of Projects.
Fix:
- Use Relationship fields for cross-list connections.
- Keep subtasks for work breakdown inside a single task or project.
Pitfall 2: Duplicating the same data field everywhere.
- e.g. copying “Deal Value” to Projects, Invoices, etc.
Fix:
- Store the source of truth once (e.g. Deal Value on the Deal).
- Use Rollups on related items (e.g. show total Deal value on the Organization).
Pitfall 3: No standards for how things are linked.
- Every team member links things differently, often via ad hoc “Related” links only.
Fix:
- Use Relationship custom fields for your core model
- (Organization, Deal, Project, Invoice, Ticket).
- Reserve Related Items for context only.
Pitfall 4: Wrong cardinality.
- Treating something as one-to-one when it’s really one-to-many, or vice versa.
Fix:
- Decide your business rules first.
- Can a Project belong to more than one Organization? Usually no.
- Can an Organization have many Projects? Usually yes.
- Configure your Relationship field accordingly.
Governance & Access Tips
- Permissions:
Make sure Lists used in Relationships (e.g. Organizations, Deals) are visible to the right people; otherwise the Relationship field will feel “empty” or broken.
- Naming:
Standardize field names across Lists:
- always call it “Organization”, not “Client” in one place and “Account” in another (unless intentional).
- Auditing:
Create saved views with filters like “Organization is empty” or “Project is empty” on key Lists to catch orphaned tasks that aren’t linked properly.
What Relationships Unlock Next: Rollups
Once your Relationship fields are in place, you can:
- Sum Deal Value per Organization
- Show the latest close date across an Organization’s Deals
- Sum Invoice Amount per Project or Organization
- Aggregate Ticket time tracked per Project
Rollups turn your ClickUp workspace into a lightweight reporting database.
Conclusion
Relationships and Related Items are what make ClickUp truly relational and flexible.
- Use Relationships for your structured, reportable links and Rollups.
- Use Related Items & Dependencies for quick context, references, and task sequencing.
With the right setup, you’ll keep your workspace organized, your data clean, and your reporting reliable, without drowning in manual updates.