Conditional fields in apps

This seems like such a no-brainer I’m wondering if somebody already asked it and I missed it (sorry if that’s the case).

It would be great to have a way to make fields invisible unless another field has value X or Y, otherwise apps have a tendency to quickly get bloated.

Congrats for all the good work and wish you all the best. Keep your sense of humor

Hi, Raphael!
Thanks for the request, noted :slight_smile:

Not sure that is coming soon, so for now, you can use DnD - fields, that are rarely used can be moved down. This workaround is not sexy at all, but for now that is the only way to avoid mess.

P.S. thanks for the kind words :hugs::sparkling_heart:

Thanks for the reply. In my humble opinion, this should rank high in your priorities because I do believe this to be a very important feature in many sectors.

For instance in real estate, there is a lot of data to collect for listings. A lot of it is conditional, i.e if it’s a house, we’re gonna need to fill field A and B, if it’s an apartment we need to fill C and D, and so on.

If your business has any kind of complexity with many data points, you end up with potentially dozens of fields. Having a string of empty, irrelevant fields makes it very bothersome for users to input data. And when a crm is bothersome it slows adoption.

You could find workarounds, like an option to hide a field if it’s empty, or allow users to fill simplified webforms with only a few select fields to create items, but it’s still going to be a problem in the long run.

Just my 2 cents

1 Like

@Raphael_Mizrahi agreed, I was thinking the same with this request Some customizations of entity view, hiding unused fields

Even with @Polina_Zenevich suggestion to move unused fields “down,” which is a good temporary solution, the Entiryy will start to look bloated with the unused fields always showing up.

Another item of hope here are Polymorphic Relationships:

Where you can at least limit relation fields to a whole app, and not need a field for each type in an app. This would help me where I need to relate one Entity to multiple types in another app. Now I need a field for wash type. With Polymorphic I’ll need just 1.

I think that Fibery promotes another approach to this. Instead of the “Property” type which represents a generic item in your inventory, you should have the “House” and “Apartment” types. You can have a single select field called “Property Type” in each of the above, but each property variation will have a different value in there.

As you know you can mix different types in the Timeline, Board views, etc.

And whenever you need to “join” these entities in a chart, you can query the data from both collections, and given you have common fields, the type denominator (“Property Type”), you will be able to treat them uniformly.

Hi Sergey,

I’m not 100% sure I understood your solution. When you say “type”, you mean “app”, right? So I’d basically create different apps for every subset of property and mix them in a single view (which is an amazing feature btw). If I understand correctly, I’d have :

  • Houses App with specific fields related to houses
  • Apartments App with specific fields related to apartments

If that’s the case, it would only solve the problem on a superficial level because customization needs to go waaay beyond that, it’s like a tree. You see, if you tick the box “my house has exterior gardens”, then I will need to display a number field with the surface in square meters. Then if you have a multiple-storey house, I need to input the surface of each additional floor in your house.

Which means I’d need an unbelievable amount of apps to build this with Fibery :

  • Single-storey houses with gardens
  • Multiple-storey houses with gardens
  • Single-storey houses without gardens
  • Multiple-storey houses with gardens
    -Etc.

And I haven’t even mentioned all the different heating options, each with their own conditional “trees”.

Having multiple apps just doesn’t work. Which means I’ll have to settle for having a single App with dozens of fields, and only half of them would be relevant to the house I’m currently working on.

It’s not just for real estate either, virtually every business I’ve worked in has dozens of data points that only need to be filled for specific subsets of customers / entities.

I’d like to stress this again : if Fibery supported automations workflows AND conditional logic as explained above, I’d jump ship in a heartbeat and subscribe for my entire company, and I would also actively recommend it to any client I’m working with. It’s a key feature.

Full disclosure - I am a client, not a member on the Fibery team.

I am not saying it’s a 100% solution. Let me clarify. First, all this is part of one single app. Let’s call it Property Management. So in your Property Management app you can have two types:

  • House with fields like Location, Owner Email, Floor Count (how many floors in the house)
  • Apartment with fields like Location, Owner Email, Floor No (which floor the apt is on)

Then you can add one more field to each of the above types, Property Type

  • House -> Property Type = House
  • Apartment --> Property Type = Apartment

Now you can query the two datasources in the Chart module and build a single table that has rows from both Houses and Apartments.

Then, if you need to be able to attach some sort of “optional feature” of a property, like Garden. This sounds like another type which has a one-to-one (if each garden is unique to a house), or a one to many relationship when each garden is like a template which you assign to more than one house.

Hope this makes sense.

Having conditional logic will be a great feature. I believe they will get to this one they start working on custom configurable views (@mdubakov :wink: )

Hi Sergey,

Thanks for taking the time to elaborate. Haha sorry, you were being so helpful I thought you were on the team :wink:

Also, I got confused with the Fibery terminology : my current CRM calls an “app” what Fibery calls a “type”. So my post above should read “Type” every time I wrote “App”.

Yes you made perfect sense, I understand your solution now. I guess it would be a decent work-around, although it would still involve creating many different Types which is not great in terms of data architecture.

I’ll definitely give it a try though, and see how it works out.

1 Like

@Raphael_Mizrahi no problem. Glad I was able to help. I am flexing my Fibery muscle here :slight_smile: I think NoCode has great potential.

Take a look here: https://www.martinfowler.com/eaaCatalog/index.html

I believe Fibery promotes the Concrete Table Inheritance pattern, while initially you’ve suggested Single Table Inheritance.