# \[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:** 13

<div class="post-metadata">

**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:** [August 26, 2020, 6: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/13 "2020-08-26T18:43:35Z")

</div>

I agree @mdubakov with Oshyan in that I think there are some good instances when Polymorphic, which I have to say was one of the features that excited me the most when I started with Fibery, is more useful than bi-directional.

Say you have a “Software Dev” app, and you have various types of “work” in there as different Types:

- “Dev Task” - standard work on an issue or software component
- “Bug” - has its own attributes different from “Dev Task.” I have thought a lot about your [Fibery v. Notion](https://blog.fibery.io/fibery-vs-notion/) example where you mentioned that if you want two types of software dev work in Notion, you can’t have each with different attributes. So in this App in Fibery we’d have that, and…
- “Acceptance Criteria” - this is also a useful Type I have created and is really helpful
- “QA”
- “Review”

Thanks to Fibery, I am getting much more depth to my dev work by having these different types inside the same App.

That said, I have differing relations among them all. It is not a straight hierarchy.

So it follows that it would be terrific if I am going to do a “Meeting” Type, or a “Sprint” Type, or a “Build” Type, I’d like to see all 5 of these Types together in a Collection, instead of having 5 separate Collections _that are not related in any way_ to handle this.

Very curious about your thoughts @Oshyan and in particular @Chr1sG as you are clearly engineering-minded, even @Jean if you’re out there!

Cheers guys!

---

_[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)._