# Fields applicable to all types **URL:** \ **Category:** Ideas & Features\ **Tags:** flexible-domain\ **Created:** [August 24, 2020, 2:06pm UTC](https://community.fibery.io/t/fields-applicable-to-all-types/910 "2020-08-24T14:06:02Z")\ **Posts on this page:** 1\ **Showing post:** 8
**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 30, 2020, 7:17pm UTC](https://community.fibery.io/t/fields-applicable-to-all-types/910/8 "2020-08-30T19:17:04Z")
Great commentary here and wanted to tag @Oshyan as well - not sure this is the best place for what I want to add here as we have a bunch of discussion around this going on right now, in particular your use case along with mine over in this main post on the subject: > [@Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type](https://community.fibery.io/t/polymorphic-relations-when-creating-relation-ability-to-have-entire-app-from-which-to-choose-and-not-just-type/425/13): > > 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/) … I think I also tried to lay out the subject around evolution of the “Collections” area within Entity views - which I think is one of the absolute shining stars of Fibery, also in this post: > [@More Capability to edit/view related entities in Collections - aka Subtables](https://community.fibery.io/t/more-capability-to-edit-view-related-entities-in-collections-aka-subtables/520): > > Hi again, I would like to suggest more capability around the Collections/Relations feature in cards. This is a great start and you are just a few steps from having available bonafide Subtables embedded within these cards, which for my use of Fibery would be a huge benefit. I used to use Confluence to run meetings. My team had a table for Agenda items, and each row was a topic. As this was nothing more than a doc, after the meeting the rows in the table were no longer useful for the team: T… So what I wanted to add to what you just wrote @Chr1sG is I think there is a lot of use of relations in exactly the way you just discussed in that last post. These are not quite handled with the existing “relate a Type to a Type” structure in Fibery. In particular, I often have within a Type one particular Entity that I want to relate to a whole other “child” Type. One example is in my Software Platform, I have one entire component, which is a Type as there are many components, which relates to another Type in another App. So I don’t really want that “child” Type In the other App to relate to every other of the Component “parent” type, but I have to right now. This also means that in the App “Map” feature (I’m talking about the visual that you get with connectors across your apps at the bottom left of Fibery, which in and of itself is a great feature unique to Fibery!), I will see this one “child” Type related to the entirety Component “parent” Type. If I could map this on the Whiteboard more accurately though, I would see all the Entities in this parent Type, but only the one particular Component linking to the “Child” Type, not the whole Type. Without this, I can only get what is really an inaccurate visual as only one Entity in the Type relates. I think this is a situation you are referring to that would be solved by what you are talking about? I wanted to bring up that we have an interesting existing feature of **Building boards to show a sort of Polymorphic View** right now, which I think might be a good way to approach a solution to this issue. So I wonder **what about implementing some of the Board view in Collections?** Boards are probably my favorite feature of Fibery. All you need is to have established relations, and you can then create a very custom view of that Entity. I have often thought that they would be more powerful if when you choose “show This type in Left Menu” in the App settings, and thus each Entity can get its own view, how great it would be if **The Board would show more of the Entity, instead of just its name at the top.** ![Image 2020-08-30 at 3.10.33 PM](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/e/e5695a0695e0e43cc83741bfbe127281cfb5f0c3.png) This would also get basically get us the same “super feature” of Notion of the ability to have any related content display in multiple ways within a Notion Page. I think this could be a fairly easy build technically as it doesn’t actually require infrastructure change to account for Polymorphism within the relation function, which as I understand may be a challenge. But you wind up able to get a view that actually includes many different Types, is filtered, represents true relations. Granted, you have to set up those relations, but if we had the ability to hide in other Entities unused fields, that would prevent other cards in the Type getting overwhelmed with empty fields. In essence, what would happen is you **relate Types to each other, but don’t have to show those relations on within specific Entities unless you want to**. And this results in a truer representation of the relations - you don’t have each and every entity forced to relate to every other one in the related Type. Hope that’s helpful and not too overwhelming of a suggestion 🙂 --- _[View the full topic](https://community.fibery.io/t/fields-applicable-to-all-types/910)._