Guide
A Relation is a connection between two Databases that is visible from both ends, e.g. you want to connect Features to Releases, Opportunities, Quarters, etc.
It doesn't matter if the Databases are in different Spaces since Relations can be cross-Space.
What is a Relation?
Imagine you have two Databases: Product and Component. You want to link Components to Products and see all linked Components in a Product. A Relation is what you need.
In a Component, you'll see a Relation to a specific Project.
In a Product, you see a list of related Components.
Relations in Fibery are always two-way. It means when you add a Relation between Components and Products, the Relation will be visible from both ends. It also means that if you delete a Relation, all connections between two Databases will be lost.
How to add a Relation?
A Relation is shown as a Field. You can add a relation from an Entity or from the Relations tab on the Database screen.
From an Entity:
Open any Entity and find + New field in the bottom right corner.
Click Relation to… option.
Select the related Database.
Select Relation cardinality (one-to-one, one-to-many, many-to-many).
Click Add Field button.
You can also create new Relations on the Database setup screen.
Show databases for Space and expand a Database.
Click Relations menu item.
Add a new Relation from this screen (ensure you set the correct cardinality).
Relation cardinality
Relation cardinality refers to the type of Relation between Entities. You specify whether or not multiple Entities (aka records, rows) can be linked — this is called picking relation's cardinality.
There are three options to define a Relation type.
One-to-many
This is probably the most common Relation, where you have a Collection of Entities related to one Entity: Product → Components → Features → Subfeatures.
A Collection is a set of Entities that appear as a result of building many-to-many or one-to-many Relations.
Many-to-many
This Relation is required when you have Collections on both sides. For example, Products ←→ Teams, which means that a Team can work on many Products, and a Product can have many Teams.
If you create this Relation, you will see Collections in both Entities.
One-to-one
This Relation is a rare one and is needed when you have a strong bond between Entities. For example, User—Employee reflects that a single User relates to exactly one Employee.
This relation is represented as a single Field on both ends.
How to name a Relation?
The general recommendation is:
Since to-one and to-relation Fields behave differently throughout a no-code tool, it's great when you can distinguish them without thinking. The default name for a relation Field is usually OK 🙂
Relate a Database to itself
You may create nested structures in Fibery by relating a Database to itself. For example, you may nest Features using a one-to-many Relation to create a Features hierarchy.
Just add a Relation and select the same Database. As a result, you will have a collection of nested Entities and a reference to a parent Entity.
See Self-relations for more info.
Relations overview
You can see all Relations in a single View. Click on the Workspace name in the top left and then click Workspace Map (Admins only).
Here you see all Spaces, Databases, and their Relations.
Note that Relations can link within a single Space (Product has many Components) or cross-Space (Product has many Releases).
Relation Filters
Use Relation Filters and Sorts to make it easier for users to pick a correct related Entity:
Automatic Relations
Automatic Relation, also known as auto-linking, enables the automatic linking of Entities from two different Databases based on specific rules.
Check out Auto-linking (Set Relations Automatically) to learn how to do it.
FAQ
How to structure Features for multiple Products?
We have several products and some features are shared between them. One feature must be implemented for two or more products. It is still conceptually the same feature, but implementation details (dates, assignees) may differ for each product.
How should we structure this in Fibery?
Solution 1: Many-to-Many relation between Feature and product
Approach
Create a many-to-many (m2m) relation directly between Feature and Product.
Store global data (feature name, description, overall priority) in the Feature entity and it's field.
Track specific implementation notes (per product) inside the Feature description or additional fields.
Pros
Simple setup, minimal database overhead.
Easy to see all products linked to one feature in one place.
Good for early-stage teams with few features/products.
Cons
Hard to track different dates or assignees per product.
Risk of clutter in feature fields if product-specific details grow.
No granular reporting on per-product implementation status.
When to choose
Solution 2: One-to-Many Relation (Feature per Product) and self-relation (Feature and it's Sub-features)
Approach
Pros
Allows different timelines, assignees, statuses per Feature.
Still keeps global feature overview via parent feature.
Flexible for both shared and product-specific features.
Cons
More entities to manage (duplicates at first glance).
Requires consistent naming or hierarchy to avoid confusion.
Parent-child reporting will need setup and more attentive views management
When to choose
Solution 3: Separate Database for Implementations
Approach
Pros
Clean separation of concept vs execution.
Full flexibility: different timelines, statuses, and resources per product.
Scales well for multiple products and complex features.
Cons
Slightly more complex structure (extra database to maintain).
Requires users to understand three entities: Feature, Product, Implementation.
More setup effort (relations, views, automations).
When to choose
When multi-product features are a core part of your workflow.
When you need robust per-product reporting without duplicating features.
Ideal for scaling teams or product portfolios with overlapping roadmaps.