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

I am just getting started on implementing a real estate development company workflow in Fibery and I think both of these would be useful - polymorphic relations and conditional fields.


A month and a half later as my Fibery setup gets more complicated and I am seeing polymorphic relationships as being even more important. :smile: I know it may take some time, but would definitely love to hear an update from @mdubakov or someone else on the team in the near future (I know that things have been tough lately in your country btw!).


Wanted to chime in again as well. This is another pain point I would be able to really solve with Polymorphic. I have many Apps with a straight hierarchy “downward,” so if I could have just one Field to choose the result from that App, and not 3/4, it great simplifies my set up.

Likewise, I’d love to be able to see in a Collections field a list of relations from an App together, and not have to have several Collections for those.

Also wanted to point out support for @Chr1sG your commentary over at:

…and I can’t help yet again remark how the app we are using here in the forum, Discourse, does a great job of bi-directional and contextual sharing/transclusion - example right there where I could just quote from that entire thread, not reference all of it.

Cheers guys!

Do you think bi-directional links can solve this problem (at least partially)?

Not unless they can be acted on in other areas of the system, i.e. sort, filter, color, etc. Having a Relationship field lets us create Views that act on those relationships. Bi-directional links don’t do that as far as I know.

1 Like

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 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!


The other thing that’s non-ideal about bi-directional links is they are all in one place, they cannot be categorized into collections.

To hopefully make it more clear why I want polymorphic relationships (and to see if others have suggestions how to accomplish my goals in other ways), I’ll outline my data and workflow similarly to @B_Sp.

I work at a small real estate development company. We have a lot of data on Properties that we want to track - location, size, assessed value, etc. We keep property info in its own App with a Property Type.

For each property, we want to show Ownership (who/what owns the property). We track People/Companies/etc. in its own App as well. In this app we have Contacts (people), Companies, Partnerships, and Trusts. Each of these are separate Types because they each track different info. Partnerships need to track the owners (also a relation to Contacts), where Companies track employees (not owners), etc.

The alternative is to define perhaps 2 types, Contact and Company, and use a dropdown in Company to define what type of organization it is (Company, Partnership, Trust). But then we end up with a lot of fields on every one of them that are not used. On Company we have information about a Trust that will never be used, etc. So we have 4 types for these. And any one of these 4 different types can own a property!

So we have a Property Entity. We have relationships with all 4 types because any of them can own a property. And in fact some properties are owned by multiple owners. So on the Entity view for every property we have 4 different relationships shown, all of which are just there to represent ownership. We have to name them “Ownership (Company)”, “Ownership (Trust)”, and so on.

Would I would like to have is a single relationship field called “Ownership” which allows multiple entities to be selected from a specific set of Types (the 4 I mention above). Then list them all under the “Ownership” relation. This would be much cleaner than what I think I have to do now.

Maybe I’m missing a better way to do this though. If so, please let me know.

Also, while it’s off-topic for this thread, I’ll mention that another feature that could solve this particular problem (though not all situations needing polymorphic relationships) would be conditional Field sets, i.e. fields that show or hide based on the contents of some other field. So we could configure 4 different variations of the “Contact” Type, selectable with a drop-down which shows or hides fields as needed. Ideally this would also change the name of the Entity dynamically to indicate whether it’s a company, trust, etc. I want this feature too, but I’d prefer polymorphic sooner, and it seems less complicated.


Just for what it’s worth, there is a program I previously used for doing the stuff I’m now doing in fibery, and it used the concept of subtypes to achieve the result that @Oshyan is talking about
That is to say, enabling/disabling field visibility. You could choose for each subtype which type fields were to be visible/accessible. When an entity was created, you had to choose a subtype.
It was actually possible to change subtype subsequently, and a minor issue I discovered by experimenting was that, the contents of the fields/relationships that became hidden when you changed subtype were not actually affected, because it was only the visibility/editability that was enabled/disabled. This had some interesting consequences.

So in @Oshyan 's example, if I changed an entity from subtype ‘Company’ to subtype ‘Person’, the ‘employees’ field would still contain data, but just hidden, so a person would in effect take on employees(!)
I know that example is kinda weird, because why would you change from company to person?!

In my case, I would use the subtypes to distinguish between manufactured parts that were sellable products (with a ‘Product code’ field, an ‘SKU’ field and a relationship to a ‘Label’ type) and parts that were only sub-assemblies for internal referencing. In this case, an item could move from one subtype to another. It could confuse people if, for example, a product became a sub-assembly and yet appeared to still have an ‘SKU’ and be linked to a ‘Label’.

Anyway, long story short, I think true polymorphism is a more elegant solution :slight_smile:


I wanted to raise the question of Polymorphic Relations again and mention another way this could really help my set up in Fibery:

I am having issue with trying to set up hierarchies that I am using to group Entities within Fibery. Since there is no folder structure, I do not know how else to do this. I am talking about the equivalent of how you would structure entities in something like ClickUp or Wrike, which have a very useful concept of “Grouping” or work around these folders.

In Fibery, the only way I can see to do this is set up an App, then create a hierarchy of Types that you “tag” across the necessary related Types to group those Types’ entities. Problems can arise though in two ways with this limited approach:

  • You don’t need to categorize an entity all the way down your existing hierarchy

  • You need an extra level of hierarchy for just one or a few Entities, and the only way to do that is to create an extra level of Type just for those entities.

In Wrike, you can create unlimited hierarchy, and nest at any level. That is very useful and avoids this problem. Without this capability that Polymorphic would solve, you can get into this situation:

I have an App I am using to categorize business functions. One area looks like this:

Top Level Type - Business Area

Entity: HR

Next Level Type: Function

Entity: Recruiting

Entity: Benefits

However, I need to break down Benefits further. Into things like Healthcare, Retirement, Payroll. In order to this, I need a new Type, call it “Sub-function”

However, back on the “Function” level, the “Recruitment” type doesn’t need further breakdown.

So I’ll wind up with either having to relate to both levels in this App, Function and Sub-Function, and if I want to see the Function where I have to use a Sub-Function (the 3rd level), I’ll also need a LookUp. And, even using that LookUp, I don’t have an actual direct relation. What I mean is, if I want to show that an Entity that is related to “Retirement’ on the third level, also relates to “Benefits” on the 2nd level, and I use a lookup to avoid having manually tag both “Retirement” and “Benefits,” I still need a direct relation to the “Function” level to tag “Benefits” so my boards can work at that level. This gets to be a cumbersome set up that Polymorphic solves completely.

I hope that makes sense. It’s a big need of mine as I need to group my work, and unless Apps and Types otherwise behave more like Folders in the future, or we get conditional drop-downs so you could create “levels” that way, I don’t know how else to do this. So I am really hoping for movement on Polymorphic soon!


Just wanted to check on this again as I haven’t seen it mentioned in an age - here in the Community, Twitter, blog, anywhere. Really hope it hasn’t been relegated to a deep backlog as it’s something I am really counting on to take my Fibery to another level of usefulness. @Chr1sG and @Oshyan, you guys still seeing a big need, too?


1 Like

Oh yes, all the time, hah. I just live with the relation proliferation, I’ve gotten used to it. But certainly it would be nice to have this in place sooner than later… And would be yet another powerful differentiator vs. e.g. Notion, etc.

1 Like

Ok great to hear that, yes it really would be huge!

Really hoping @mdubakov and team will pick this thread up at some point and give us an update re: their latest plans around this. Would you agree it’s been a long while since we’ve heard anything about the progress on this? In fact since you joined circa July, I’m not sure there have been any tangible updates!


Well, the most recent relevant discussion is above, I think, from August. So yes, it’s been a bit, but we know the were focusing on their “2.0” launch, Product Teams stuff, etc. Looking at the other things we know they’re working on, I would say we probably won’t see this for 4-5 months, realistically. Maybe by summer? :man_shrugging:

Ok thanks for responding! I don’t think that’s a “relevant” discussion - it’s a quick question asking if your needs can be met another way. I really don’t see any guidance around this since the original response by Michael in Nov. ‘19 - by the way, he changed the subject to “Polymorphic” from my original request, so that gave me hope that this was a real feature they were focused on and wanted to develop. The thing is, since Nov. ‘19 I really can’t pin down any subsequent mention of the feature, so my fear is it’s gone way out of the priorities, if even planned at all!

Summer would be great, and I hope we get some indication it’s at least still planned! Would make me, for one, very more confident about my future activity in Fibery. You are right it’s a huge feature that could really solve some of the issue that Notion and other no codes don’t deal well with. Part of my hope here is that due to Michael’s discussion of this, I actually thought Fibery may be the first with such a feature, since I have actually never seen the likes of Coda, Airtable, Zenkit, etc. even acknowledge that they’d consider such a useful feature in the first place!

Thanks again for the commentary!

1 Like

Yes, that’s a fair enough point. I guess I took @mdubakov 's response as an acknowledgement that they’re still thinking about the problem, which although it was not a “yes we’re going to implement this” response, was still a cautiously positive sign to my mind.

We’re all pretty clear in this thread that bidirectional links and other things are not going to address the core need. I imagine the implementation may be challenging for them, so I’m sure it takes some more thought, but hopefully they are doing that. I agree that an update on whether that’s even the case would be good.

In fact if they are really not planning to implement it that would be important to know. Certainly it would be disappointing, but I’d rather them share that news now. I don’t think it would drive me away on its own, depending on other things they may implement (like field groups and tabs) it may be workable for me.

1 Like

All great points here.

No question this is a big piece and I can’t think of any other app that is based around relational database type linking of entities/rows has figure this out. They all wind up with some sort of another of “field proliferation” if you want to relate one item in a Table to many, many others. Notion and Coda have nice solutions now to hide fields so you can limit this somewhat, but it’s not useful if you need to relate to those fields from time to time. So if the Fibery team can solve this, it will be huge, and I think worth the work they’ll need to put into it. But that’s right, it would be very useful to know if it’s still planned given how little info we have of late.

As I move forward in Fibery I am really plagued by this issue I described above, about being able to group big parts of my Fibery:

Thanks to Fibery being set up by grouping its data tables in Apps, if Polymorphic does come along, this issue would be completely solved and it would make building in Fibery very intuitive and much more flexible than right now. So I just want to call attention to this particular need yet again!

Thanks again!

1 Like

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.

I do think that eventually we will get to it, but you should not expect this feature in the next 6 months.

@B_Sp Not sure why you constantly complain about lack of transparency, I write monthly posts about all the plans on our blog. https://fibery.io/blog/startup-diary

You should understand that we can’t create plans for more than 2-3 months ahead, since we are a startup and things change quite often when we discover new information.


Michael, it’s a shock to me to read your message. You are the CEO of a startup who created an online community to illicit feedback about your product, and you are here publicly embarrassing me, the author of more liked posts by any other member, and a paying customer, calling me a “complainer”. It’s amazing to me you’d allow yourself to do such name calling in the public forum, without taking this up privately at least and putting in effort not to humiliate me this way.

You yourself marked up this post with the title “Polymorphic Relations,” for over 14 months with any guidance around the actual plans on this feature. You guys actively ask for “unsweetened” feedback, so when I point out this fact, I get labeled as “complaining.” Are you sure you can handle blunt, accurate feedback? It appears judging by your response to me that I’ve made you uncomfortable by stating the facts.

You know well I read every single piece of information you publish about your roadmap. Your monthly posts bypass most of the requests in the community that you guys don’t respond to. It is hard to find anywhere what actually guides your decision making about your roadmap. The Vizydrop chart you published isn’t exactly easy to read, and if you can show me where you’ve published information about how it ties into your WIP, I’d like to see that. That would solve a lot of my concern that I am simply candidly expressing, feedback you guys eagerly request all the time!

I won’t bother yet again to list all the requests in this community that are poorly addressed. I have taken time to document many of them before, and you guys didn’t respond. If you are satisfied with the way you are handling feedback in here, then I get the message and will not spend any more of my time trying to point out areas I think you can improve.

In closing, I will say that I’m active and vocal in a lot of other communities of competing products, but I have never been close to insulted like this. I wonder if you’re aware of the message you’re sending at this fragile stage of your growth re: how you handle when you are called out legitimately. You own this forum and I guess you can do whatever you want in here. I can tell you that you have just gone a long way to permanently damage my view of Fibery.

And @Oshyan and @Chr1sG, judging by you both “hearting” end endorsing that comment, I assume you also think I’m a complainer. Borderline painful to see that…

I think you are drawing too dramatic a conclusion from my “heart” reaction. Michael shared what I view to be useful information and I appreciate that he did, that is all. I do not need to endorse the entirety of his - or anyone’s - message to feel it is worth expressing some appreciation for.

It is unfortunate that there is difficulty between you, and I can understand you feeling hurt by his comment, but it’s neither my place nor my wish to comment or take sides beyond that. It certainly saddens me to see conflict though, and I hope the two of you can resolve it.

1 Like

For the avoidance of doubt, I will state that I too did not intend my heart to indicate endorsement of all that was contained in Michael’s post.
I would also add that having worked in several countries, with people of varying backgrounds, who didn’t necessarily share a common native language, I have found it useful to follow the adage ‘assume positive intent’. From what I have seen on this forum, I believe that both Michael and B_Sp have good intentions.

1 Like