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 
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 
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
@Raphael_Mizrahi agreed, I was thinking the same with this request https://community.fibery.io/t/some-customizations-of-entity-view-hiding-unused-fields/452
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 :
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 :
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:
Then you can add one more field to each of the above types, Property Type
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 
)
Hi Sergey,
Thanks for taking the time to elaborate. Haha sorry, you were being so helpful I thought you were on the team
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.
@Raphael_Mizrahi no problem. Glad I was able to help. I am flexing my Fibery muscle here 
I think NoCode has great potential.
Take a look here: Catalog of Patterns of Enterprise Application Architecture
I believe Fibery promotes the Concrete Table Inheritance pattern, while initially you’ve suggested Single Table Inheritance.
hi there. Were there any progress regarding that request? I too think it’s really important to be able to have conditional fields. Thanks
Hi, Claude!
No progress and not sure we would have it in the nearest future
But feel free to ping us on intercom - based on the use case you have, we have some nice solutions and workarounds to suggest!
Hi Polina,
What work-arounds would you suggest? It would be interesting for many users to have them on the forum.
Also, I hope you don’t mind me asking what makes this feature so complex? I noticed that many other softwares also shy away from dependent fields so I’m assuming there is some hidden complexity that I am not aware of. Just curious.
If we speak just about UI (show field X when field Y has value Z), then it is not super-hard to implement. It’s just a matter of priorities. This feature is quite complex and not so many people requested it. So it lives somewhere deep in our huge backlog.
Since the platform is more geared towards organizing processes, I really miss conditional logics for fields. It is quite common to need a field to appear in a certain phase or that it be filled in just before completing the task, for example.
With that, the platform would become amazing
Is it the same idea as this:
?
Yea! Exactly. If this doesn’t exist, we’ll end up with several fields created, making usability very difficult, as each one of them is only used in a certain mode or obeying a condition.
Other platforms bring this along with their automation rules, adding only the options of:
Seems like a merge of those two topics is in order.
Would really love to get conditional fields at some point, so want to add another voice of support…
Hi, I voted this as well, in complex scenarios allowing editing/usage of a field can even break the workflow, for example where I have a button field that cannot be pressed when the entity is in a certain condition and that is now not possible.
Is there a planned date for this request?
Thanks a lot
Giuse
