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

Ideas & Features
1

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!

10 Likes
2

@B_Sp I got the problem and we are going to solve it via Polymorphic relation in future. It will work this way. When you will create a relation, you will be able to select ALL types from some App as a reference. In this case you will have 1 relation field, but will be able to select various types in it.

9 Likes
3

Really great to hear this is in the plans @mdubakov, thanks again!

4

Hi Michael,

I just wanted to resurface this and I’m wondering if you guys have any update on your plans re: Polymorphic, if nothing else just to confirm it is still on your Roadmap, as I am seeing increasing benefit from it as I build out my Fibery instance.

On particular use is a “Work” app I have that I’m housing types of “tasks” in. I have about 7 types of Tasks now, and could add some still as the need arises, things like:

  • Dev Task
  • QA Task
  • Meeting
  • “Regular” task (ie “take out the trash”)
  • Incident
  • Conversation (used in CRM & Feedback Mgmt)

I have all these tasks in one app as they all represent “work.” However, each has somewhat different attributes, so its very useful to have them in different types to be able to configure each individually. This is a huge benefit of Fibery.

However, I frequently want to relate these to my “Execution” app where “Projects” live. Each type can be part of a project. In order do do this though, I have to have a one-to-many “Connections” Type relation to each Type in my Project. So that is 7 relation fields. With Polymorphic, this would be beautifully simplified:

  • I only need the one field to have all types of “work” related;
  • I could see in just one “Connections” area all the types of work with their various colors, type icons, etc. This would be a masterful view within Fibery!

So just wanted to mention this and find out if you guys are able, can you share anything about your plans re: Polymorphic.

Thanks!

5

@B_Sp Your problem can be “partially” resolved when we will release bi-directional links. In this case you can mention related project in Dev Task description and this Dev Task will appear in this project’s Links section. Maybe not very useful, but might work as a workaround.

2 Likes
6

Michael, and thanks for that explanation on this one, too.

If you have a moment, could you clarify if Polymorphic is still in your plans, even if unknown when you guys will get to it? I think it was a big differentiator vs. Notion, Airtable, Coda, Zenkit as they all force you to choose one table when creating a lookup. Oftentimes in those apps, a “table” (or “collection”) may equate to one entity type with you guys. However, as you can have many entities in Fibery in one App, you can essentially relate multiple types of information more readily, like my example. Another one I see frequently in those aforementioned apps is two tables for CRM - “Companies” and “Contacts.” But in Fibery, it’s logical to hold these in one Fibery App.

Thanks again for all the responses!

2 Likes
7

Sorry for posting in this thread again, but this is a big want of mine from Fibery, and wanted to reach out to a few of the newcomers @Jean as well as @chris.burchartz and @Raphael_Mizrahi, who we talked together around this request:

I have done a lot of work in Notion and Coda, and they both have the major limitation of being able to relate just one table to another. Here in Fibery, Types are grouped in Apps, but we still can only relate one type to another. So I find myself making some “mini” hierarchies within Apps, let’s say I have one for Development like “epic - > feature - > User story”. If I want to create another Type for an “Engineering Meeting,” I’d like to be able to reference anything out of this App in one field, and potentially see multiple types in that field, too.

I wanted to bring this to your guys’ attention and get your thoughts, as Michael is weighing in here that the team has this on the radar. I personally can’t wait for it! I am curious mainly of any sentiment about how badly it is needed among others using Fibery, or are there any workarounds? I haven’t found any, and simply am waiting impatiently so I can get my Entities into a much more compact state with far fewer fields.

Thanks!

2 Likes
8

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.

2 Likes
9

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

3 Likes
10

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!

11

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

12

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

2 Likes
14

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.

2 Likes
15

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:

5 Likes
16

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!

Thanks!

17

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?

Cheers!

1 Like
18

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
19

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!

Cheers!

20

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: