Guide
A self-relation is simply a relation that has been configured to link a Database to itself.
It behaves just like other Relations, in that
it is created using + New field or via the Relations menu on the database configuration page
the relation will show up as two fields (one for each end)
you can choose the cardinality (one-to-one, one-to-many, many-to-many)
you can use filters (for the to-one field)
you can use auto-linking
Typical use cases
Tasks with subtasks, which have subtasks, …
There can be a temptation to create a database of Tasks, and then another database for Subtasks, and link the two databases.
However, if you want to create a hierarchy of Tasks, so that a Task can have sub-tasks (which themselves can have sub-sub-tasks, and so on) then self-relations are the way to go.
After you create a one-to-many self-relation in the Task database, each Task will get a collection of linked Tasks (representing the sub-tasks), and will also get a simple Task field (representing the 'parent' Task).
By default, these fields will be named Tasks and Task respectively, but you may want to rename them as SubTasks and Parent Task.
A self-relation like this allows for multi-level nesting, which can be enabled on Table view and Board view by choosing the Group by … Parent Task (recursive) option.
Blockers
If you have a Deliverables database, and each Deliverable may be dependent on the completion of certain other Deliverables, you might want to make a many-to-many self-relation where the two collection fields represent the other Deliverables that are 'blockers' and 'being blocked' for any given Deliverable.
Daisy-chaining
If your Sprints run one after each other, you might want to use a one-to-one self-relation to achieve 'daisy chaining'. Each Sprint will then have two fields: one links to the previous Sprint, the other to the next Sprint.
You might even consider using auto-linking so that you don't need to manually connect them, but instead let Fibery do the work. For example, if you have a date range field, you can do matching of the end date to the start date.
Check out how date range formulas work for why this works, when the end date of one sprint is actually a day before the start of the next one.
Wikis
Guess what? The user guide that you are reading now is made using entities that are self-related (one-to-many). This makes it possible to create a nesting hierarchy of topics - you'll notice a list of Sub-guides at the bottom of each Guide.
Also, within the the User Guide space, there are a number of Smart Folders in the left menu.
Each smart folder is set up with 'self-relations' enabled …
… and has a filter for the Section and Published status.
Using self-relations in formulas
Having self-relations means that it is possible to have recursive formulas, i.e. formulas that refer to themselves (via self-related entity/entities).
For example, you could create a 'breadcrumb' formula on a Task that shows the names of all the Tasks that are higher up in the hierarchy.
The Breadcrumb formula would look like this:
If(IsEmpty([Parent Task]), Name, [Parent Task].Breadcrumb + " > " + Name)
However, it is not possible to create a recursive formula in one go. That's because in order for the formula to refer to itself, it needs to already exist 🤪
To create a recursive formula, first create a formula field with the correct name, containing a 'dummy' formula that gives the correct data type. Then after it has been saved once, you can edit the formula field to make use of recursion.
In the above example, you would create a formula field called Breadcrumb, where the formula is something simple like "xxx" which ensures that Fibery recognises it as a text field. After saving it, you can go back and update this field to the correct formula (above).
Another use of self-recursive formulas might be to count the total number of subtasks, sub-subtasks, etc.
SubTasks.Count() + SubTasks.Sum([Count of subtasks])