Hi again, As I get into Fibery, I am seeing that it could be useful for my use case to be able to choose amongst all types in a given App when creating a related field in another type. What I mean here is let’s say I have a type I’ve created in an App “Counterparties” called “vendor”. In this App I also have “partners” and “customers.” My vendors in turn provide 5 key services, which I have in another App. I’d like to link each service to the vendor. These services play a role in my Fibery set-up, and I want to make each its own type, instead of using each Vendor to link around Fibery. One reason for this is that I have other vendors, such as utilities, lawyers, etc. that are not associated with any of these 5 services in the Services App. So I am trying to keep all Vendors separately tracked. When I link the vendors to the respective services, it would be very useful if I could choose the App as the relation, and not the type. With this ability, when I create a new vendor, I can simply choose the service from a drop down that would be named after the app, and not the Type. In the current set up, I’ll have to create 5 relation fields (one for each type, since a new Vendor may belong to any), and only fill in the one that is actually the particular service the Vendor is providing. I hope this makes sense and look forward to your feedback, thanks once more!

Wanted to bump this, and @Oshyan brought it up in another thread before I had a chance to! I’m going to leave my hastily written use case for Polymorphic in the other thread, but here’s a link to it for reference: https://community.fibery.io/t/seeing-closed-entities-grayed-out-in-search-dialog/1298/10?u=b_sp

Ah yes, Polymorphic…funny I was thinking the last week how to add in some additional use case stuff to try to move that along. You’ll recall @mdubakov mentioned here that the work involved isn’t too complex: [image] mdubakov: Polymorphic relations are not so hard to implement, it maybe take ~2 months for 1 person. The problem is that it is not a priority. First we will focus on better permissions and other pressing things that customer asks MUCH more often. In an effort to paraphrase what I wanted to explain as a much more detailed post, I am seeing an increased need for Polymorphic around creating hierarchical “grouping” style Apps. A situation where I would use an app and a series of child Types to group other Types, much like you’d use Folders in an old-school file system. The key is that in some cases you need just one level of hierarchy, in others say 4 or 5. Without Polymorphic, you have to always have the bottom level used , otherwise you would need to create extra relations to have something grouped on a higher level than the bottom. So say you have something like this: Function → Subfunction → Specialization → Area This would be used in categorizing some work in a business, such as: Marketing → SEO…in this case, you would not need to go down further to level 3 and 4, but you might have: Marketing → Paid Campaigns → SEM → Google Ads…in this case the four levels are essential, as you could have another one here after “SEM” of “Facebook Ads” right? With Polymorphic, I can choose at which level I relate to the entire App described here. That is just like if I’m creating a file folder in, say, Google Docs, for my Company functions. I can create folders on more than one level, and that works nicely. Let’s hope Polymorphic continues to gain support - I’m glad to see it’s so popular now with Votes, although not sure if that’s giving it enough weight on the overall points scheme within the entire feedback system on the Fibery Roadmap!

Thank you for the comment, it indeed describes the value well. Some comments from me: With blocks we gave this feature more priority, since there are things that can’t be done without polymorphic relations I seriously underestimated effort, it is much harder to do and it’s a significant technical challenge. I hope we’ll do a spike in the next months to see how hard it is to implement.

I wanted to just let you know that I moved my vote here over to the request here: [image] Next iteration of Comments - Commenting when Resolving & assigning as tasks/reminders Ideas & Features Hi once more, I wanted to make some suggestions for comments as you guys evolve them. This is coming mainly from my extended use of a ton of apps in the last several years, and none seem to be able to pull all the best methods for implementing comments all in one place. You guys have a good chance to do that now! Resolving Comments I’ve seen a great way to close out comment resolutions in some apps where they will prompt an extra comment around the “resolve” action. In most cases, you can… Right now I need that above request more than Polymorphic, but it’s hard for me to quantify to what degree having said that… I would really like to also point out that I don’t understand the 5 vote limitation. In particular for many of us veterans of the forum, it would be nice to be able to vote on more posts. I think Team Fibery could give us some good faith that we won’t go voting willy nilly. I think it’s odd and artificial that I have to remove a vote here because I don’t have enough. I’d also like to pose the question to @mdubakov around this point, and @Oshyan eager to get your 2 cents too, that do you guys limit feedback in your back channel to just 5 votes per user? So if a user writes in a request a 6th time, how would you figure out where to remove the vote? I’m asking because you’ve generously shared your backlog and votes around features in the past, often showing that requests you get directly from users have far more “weight” in votes - and that’s how you showed them, with actual numerical value - than requests here in the forum. I recall that Polymorphic barely showed up in the chart here: [image] Most Requested Product Areas Report by Fibery yet it’s the top category now that we have votes. Hope that’s useful. Would really like more votes, because without them I think we have a skewed view of requests. And would really like to know if you impose this limit on the “internal” tracking of users. Thanks!

[image] B_Sp: Polymorphic barely showed up in the chart here: https://vizydrop-svc.fibery.io/svc/vizydrop/shared/drop/5f92f75b7f92dd2c10305d92 yet it’s the top category now that we have votes. I don’t see anything about Polymorphism in the chart at all.

I accidentally posted a reply here, when I meant to move it to a new thread. And although there is mention of it above, I wanted to just make a new reply here to make sure @B_Sp saw it was a reply to this topic. Will be more careful about which thread I am replying to in the future. :joy: [image] Matt_Blais: I don’t see anything about Polymorphism in the chart at all. It is there at least on the “List” view: https://vizydrop-svc.fibery.io/svc/vizydrop/shared/drop/5f92fb44c717c161b4e48265?authkey=34f99b058d01e0b41a96

Would love to get an update here guys. My team has come up on this again as we build out new areas with multiple levels. We are building some multi-level structures in a software system. Basically, three apps, One has 4 levels, the other 3. There structures are in turn connected to a couple of types of Dev work items in other apps: We have multiple story types (Technical, User) and related tasks and bugs. As we build it out, we are seeing that in some cases, structures don’t all have four levels. There are items on level three, or two even, that are the end of that particular “tree.” The stories need to link to the item that is being built, though. So without Polymorphic, in order to have the relation of a story to all levels I need, I have to have three Types in the hierarchy relate to the Story Type in the other App. This is getting very unwieldy. Or, I have to artificially create items in my structures down to the bottom level of each app, even though in reality this may not reflect how my structure looks. This is basically a repeated instance of multiple examples I already posted in this thread, but just wanted to add yet another use case here. Glad to see we’re up to 10 votes here, really hoping for some movement on this soon!

I don’t mean to be the primary torch holder of those of us really eager for this feature, but since it is about 1/2 year since @mdubakov weighed in here, would love to get another update on the team’s thoughts around this. I’m aware we have a good deal of visibility into what you are working on right now, such as blocks and new Entity View - both of which I eagerly anticipate. But my team still has a bunch of big things we want to do in Fibery, mainly around hierarchies we need to represent, that are blocked by the lack of Polymorhpic. Would even be happy to hear if you guys think this might be addressed in the next 1/2 year, or not till 2023, etc. In closing I’ll just add that if you can get this live, it will be one of Fibery’s truly differentiating features in the market and I think you guys should leverage it when completed to pick up some of the networked-thought folks flocking to Roam/Notion etc. as those tools have nothing like this. And I’m sure they don’t even have it thought through and on the dev radar yet, you guys have a leg up here! Thanks!

I notice in the schema lots of fields related to “Mixins”. I assume that’s not something that could be leveraged for this purpose, or it would already have been done.

[image] Matt_Blais: I assume that’s not something that could be leveraged for this purpose, or it would already have been done. 'fraid not, sorry.

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

Ideas & Features

Topic		Replies	Views
Fields applicable to all types Ideas & Features flexible-domain	13	3553	September 7, 2020
🌰 Fibery major conceptual (yet) unsolved problems News & Announcements	33	1413	October 8, 2026
🐠 Fibery product report: February 2026 News & Announcements	14	420	March 13, 2026
Relationship properties Ideas & Features flexible-domain	42	3520	March 10, 2026
Video game studio hoping that Fibery is the solution! Get Help	47	4520	June 7, 2021

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

Related topics