Files
twenty/packages/twenty-docs/user-guide/data-model/capabilities/relation-fields.mdx
T
StephanieJoly4GitHubcubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>github-actionsAbdul RahmanFélix Malfait
183d034716 User guide structure update (#16705)
Reorganizing by Feature sections

Capabilities folders to give an overview of each feature

How-Tos folders to give guidance for advanced customizations

Reorganized the Developers section as well, moving the API sub section
there

added some new visuals and videos to illustrate the How-Tos articles

checked the typos, the links and added a section at the end of the
doc.json file to redirect existing links to the new ones (SEO purpose +
continuity of the user experience)

What I have not updated is the "l" folder that, per my understanding,
contains the translation of the User Guide - that I only edited in
English

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> <sup>[Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) is
generating a summary for commit
5301502a32. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Co-authored-by: github-actions <github-actions@twenty.com>
Co-authored-by: Abdul Rahman <ar5438376@gmail.com>
Co-authored-by: Félix Malfait <felix.malfait@gmail.com>
2025-12-22 09:07:06 +01:00

87 lines
3.0 KiB
Plaintext

---
title: Relation Fields
description: Connect records across different objects using relation fields.
---
## Types of Relations
### One-to-Many
One record in Object A can be linked to many records in Object B.
**Example:** One Company can have many People (employees).
### Many-to-One
Many records in Object A can be linked to one record in Object B.
**Example:** Many People can belong to one Company.
### Relations to Multiple Object Types
Some objects can link to multiple object types on one side of the relation.
**Example:** A Note can be attached to one Person AND one Company AND one Opportunity simultaneously. The Note is on the "many" side, connecting to multiple "one" sides.
<img src="/images/user-guide/fields/many-to-one-morph.png" style={{width:'100%'}}/>
Similarly, a Project (on the "one" side) could receive links from multiple People, multiple Companies, and multiple Notes.
<img src="/images/user-guide/fields/one-to-many-morph.png" style={{width:'100%'}}/>
<Warning>
**Import/Export limitation**: Relations pointing to multiple object types are not yet supported for CSV import/export. This is on our roadmap.
</Warning>
### Many-to-Many
Many records in Object A can be linked to many records in Object B.
**Example:** Many People can be linked to many Projects, and vice versa.
<Warning>
**Many-to-Many is not yet supported.**
This relation type is planned for H1 2026. As a workaround, create an intermediate "junction" object (e.g., "Project Assignments") that has Many-to-One relations to both objects.
</Warning>
## Creating a Relation Field
1. Go to **Settings → Data Model**
2. Select the object where you want to add the relation
3. Click **+ Add Field**
4. Select **Relation** as the field type
5. Choose the target object(s) to relate to
6. Configure the relation settings:
- **Field name on source object**: The name of the relation field on the object you're editing
- **Field name on destination object**: The name of the relation field that will appear on the target object
- Relation type (one-to-many, many-to-one)
7. Click **Save**
## Standard Relations
Twenty comes with pre-built relations between standard objects:
| From Object | To Object | Relation Type |
|-------------|-----------|---------------|
| People | Companies | Many-to-One |
| Opportunities | Companies | Many-to-One |
| Opportunities | People | Many-to-One |
## Best Practices
### Planning Relations
- **Map your data model**: Plan relations before creating them
- **Consider direction**: Think about which object "owns" the relationship
- **Avoid circular dependencies**: Keep your data model clean
### Naming Relations
- **Use clear names**: Make it obvious what the relation represents
- **Be consistent**: Use similar naming patterns across relations
- **Consider both sides**: Name both sides of the relation appropriately
### Performance
- **Don't over-relate**: Too many relations can slow down your workspace
## Limitations
- **Deleting relations** removes the link but not the related records
- **Circular relations** should be avoided for data integrity