# \[APPROVED\] Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type

**URL:** 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
**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:** 1
**Showing post:** 77

<div class="post-metadata">

### 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")

</div>

### 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)

---

_[View the full topic](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)._