# \[APPROVED\] Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type **URL:** \ **Category:** Ideas & Features\ **Tags:** flexible-domain\ **Created:** [November 22, 2019, 12:14am UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425 "2019-11-22T00:14:24Z")\ **Posts on this page:** 17\ **Page:** 4
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [November 14, 2023, 9:22pm UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/62 "2023-11-14T21:22:34Z")
It is theoretically possible, but I’d not recommend it. Extracting references from rich text is a PITA. References are great for adhoc relations where you don’t need to leverage them elsewhere. As soon as you want to build upon them (formulas, automations, lookups) they become less useful. Anything you built might get superseded by genuine polymorphism at some point 😉 so your work would be wasted. For the time being, if you must have links to many dbs, it’s probably better to just use multiple relations and optimise the UX/UI with thoughtful relation views and field hiding. If you can afford to wait a while, that’s probably going to yield the best result 😊 ---
**Author:** ![Lod](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/lod/32/8358_2.png) [@Lod](https://community.fibery.io/u/Lod)\ **Post date:** [January 7, 2024, 3:55pm UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/63 "2024-01-07T15:55:07Z")
Wow, can you share the link of the item in Roadmap. Thanks. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [January 7, 2024, 4:05pm UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/64 "2024-01-07T16:05:33Z")
It may not look like it, but this item is the first of several that may be helpful for you [https://the.fibery.io/@public/Public\_Roadmap/Roadmap-Board-5974#Roadmap\_Item/Highlight-Creation-212](https://the.fibery.io/@public/Public_Roadmap/Roadmap-Board-5974#Roadmap_Item/Highlight-Creation-212) ---
**Author:** ![jbreichel](https://avatars.discourse-cdn.com/v4/letter/j/cc9497/32.png) [@jbreichel](https://community.fibery.io/u/jbreichel)\ **Post date:** [January 7, 2024, 10:43pm UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/65 "2024-01-07T22:43:46Z")
I, too, wonder if the concept of ‘tags’ wouldn’t accomplish a lot here. Creating a new entity type and then associating it with lots of other entity types (if I understand that’s what’s being suggested) seems a little like overkill for many use cases, if a person could just create some tags that can be applied all over the place in Fibery. ---
**Author:** ![interr0bangr](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/interr0bangr/32/8089_2.png) [@interr0bangr](https://community.fibery.io/u/interr0bangr)\ **Post date:** [April 11, 2024, 12:58pm UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/66 "2024-04-11T12:58:41Z")
Have been running into some use cases recently where this feature would be very helpful. How’s the development coming along? ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [April 11, 2024, 1:34pm UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/67 "2024-04-11T13:34:39Z")
True polymorphic relations are some way away, sorry. ---
**Author:** ![Lod](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/lod/32/8358_2.png) [@Lod](https://community.fibery.io/u/Lod)\ **Post date:** [May 30, 2024, 4:28pm UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/68 "2024-05-30T16:28:52Z")
@Chr1sG Hi, is there some relationship between Highlights and Polymorphic? ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [May 30, 2024, 4:50pm UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/69 "2024-05-30T16:50:44Z")
> [@Lod](#): > > is there some relationship between Highlights and Polymorphic? What do you think? 😉 Under the hood, ‘highlights’ is a special kind of database which supports what we call ‘multi-relations’, that is the ability to link to a single entity from any of several databases. So a highlight has a ‘source’ multi-relation and a ‘target’ multi-relation, and the configuration of highlights determines which dbs are available for each of these. i.e. Source 1:n Highlight n:1 Target The result is the ability to link (indirectly) from any source-db entities to any target-db entities. At the moment, the source dbs have to have a rich text field, because the ‘highlight’ is bound to a specific snippet of text. On the source entity, the highlight shows as a selected piece of text, and on the target it shows as a feed-view like relation field. In the long-term, the same underlying tech could allow entities to be linked via multi-relations in a less restricted way. So you could say, that highlights is a v specific (and limited) form of polymorphism, but we do have plans to make it more powerful… just no ETA 🤷 ---
**Author:** ![AdVhPkgKad](https://avatars.discourse-cdn.com/v4/letter/a/7993a0/32.png) [@AdVhPkgKad](https://community.fibery.io/u/AdVhPkgKad)\ **Post date:** [November 4, 2025, 10:52pm UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/70 "2025-11-04T22:52:32Z")
Any word on this? Still in the backlog? ---
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [November 5, 2025, 7:34am UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/71 "2025-11-05T07:34:06Z")
You may expect it no earlier than Q1-Q2 2026 ---
**Author:** ![interr0bangr](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/interr0bangr/32/8089_2.png) [@interr0bangr](https://community.fibery.io/u/interr0bangr)\ **Post date:** [November 5, 2025, 7:02pm UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/72 "2025-11-05T19:02:20Z")
When you say “expect”, are you confirming this is on the nearish-future roadmap then? ---
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [November 6, 2025, 7:52am UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/73 "2025-11-06T07:52:10Z")
It is a part of 2026 strategic plan. I hope we will share it in November or early December ---
**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\ **Post date:** [December 11, 2025, 6:26am UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/74 "2025-12-11T06:26:14Z")
This is great to hear. Still have a huge need for this. More recent use case: Trying to set up a system for tracking traffic to a range of websites of my clients. Would like to list out in a table in a new db types of user actions on this app. Each of the sites in question has a breakdown in Fibery similar to some of the structures I’ve seen you posting about such as: Site → Experience Area → Master Feature → Feature For the purpose of quickly adding in the activity types in the table, which are going to relate ultimately to one of those 4 areas on the site hierarchy, it would be great to have a relation that could draw from any of the options in that hierarchy. Then as these fast entries are made in the table, I could simply choose the “site” at the top level, and come back later as the system is developed and change to a Master Feature or Feature. Without polymorphic, I have to have a relation to “site” at the top level so I can at least enter which of the sites these user actions relate to, then as I build them, have a second relation that will relate to the lower level Master Features or Features that are actually in that Site - so I wind up with a redundancy of relations here. Hope that was useful and really hoping to see Polymorphic soon! Nobody else out there has solved this, although I did realize in my accounting software I can add a category of expense at an unlimited level of subcategory, all from one field - so possibly unknowingly that vendor has implemented a sort of polymorphic set up that is actually very useful! ---
**Author:** ![gasby](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/gasby/32/11429_2.png) [@gasby](https://community.fibery.io/u/gasby)\ **Post date:** [August 31, 2026, 11:43am UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/75 "2026-08-31T11:43:26Z")
Is there any movement on this topic? We are building a solution that would really need this ---
**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\ **Post date:** [August 31, 2026, 11:50am UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/76 "2026-08-31T11:50:27Z")
Unfortunately it is extremely unlikely it will be done this year, hope in 2027 ---
**Author:** ![Sev](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Sev](https://community.fibery.io/u/Sev)\ **Post date:** [September 1, 2026, 11:59am UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/77 "2026-09-01T11:59:36Z")
### Junction table (imperfect) workaround Since I have used Polymorphic models for decades, I was unable to wait, so I have many junction/join tables (similar to helper [databases described here](https://community.fibery.io/t/helper-databases/7499)) in the form of **subject relation fields** and **object relation fields** , enabling the following: 1. To connect a subject entity to any object entity, within the same field, i.e. the junction table relation field on the subject entity. 2. To keep polymorphic relations modelled in the same way, to allow migration to the feature when it is finally launched. 3. To add Formula fields on the junction table to roll-up a field from across the different objects, to then be used by the Subject entity. 4. To have multiple subjects sharing the junction table. 5. This has the added benefit of allowing [relationship attributes](https://community.fibery.io/t/relationship-properties/887). ### Accessing fields from the junction table With the possibility to [add the fields of a relation to the UI without the need for lookups](https://community.fibery.io/t/april-2-2026-show-fields-from-relation-without-lookup-ai-integration-agent/10679#p-41143-show-fields-from-relation-without-lookup-1), this junction table approach, becomes slightly less cumbersome. ### Example I had Claude whip up a quick diagram below with the example junction table `Workables`, meaning a `Task`would have a `Workables` relation field, but would mostly use things such as `Workables.Sum([Rollup of some data from across objects, e.g. effort, cost, etc.])` ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/b/b9329b5210e29463b659b0457ba60b85d9a397a1.png) ---
**Author:** ![CharlesP](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/charlesp/32/15039_2.png) [@CharlesP](https://community.fibery.io/u/CharlesP)\ **Post date:** [September 15, 2026, 4:35am UTC](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425/78 "2026-09-15T04:35:34Z")
According to my friends at Deepseek: “PostgreSQL 19’s SQL/PGQ (still in beta as of mid-2026) **removes a major technical barrier** to implementing polymorphic relations in Fibery. It provides the right primitives—heterogeneous graphs over existing tables—without requiring a separate graph database or a fundamental rewrite of Fibery’s storage model. The feature is no longer blocked by database limitations; it is now a matter of **prioritization, product design, and engineering effort** on Fibery’s side”! [Previous page](https://community.fibery.io/t/approved-polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425.md?page=3)