Dependent Dropdown Field Type

Hi Guys,

Sorry if this is a detailed request, but I’ve seen a lot of times I could use a “Dependent Dropdown” capability with fields in Entities.

What I mean is if I have one dropdown that I’m using, the options would lead to a 2nd related dropdown that would have dependent results based on the choice of the first:

Let’s say we want to categorize a “Recipe” Entity type:

First Dropdown:



  1. Meat
  2. Vegetable
  3. Fruit

Values in 2nd Dropdown:

  1. Beef
  2. Pork
  3. Spinach
  4. Lettuce
  5. Broccoli
  6. Apple

Depending on the choice of the first, you’d be presented with a filtered view on the 2nd that would be limited by the choice on the first.

This can be achieved right now I think if you use an entity to relate to the “Recipe” entity called “Type of Food.” If in the food App, you have a top level type “Food group” and sub-type “Type of Food,” then I believe back in the recipe app, if you set a relation to both types, they will pre-filter based on the relations in the Food app. So if you set up in the Food App that Food Group “Meat” relates to sub group “Beef” or “Pork,” then when creating a Recipe Entity, you’d only be able to choose “Beef” or “Pork” if you first select “Meat.” However, in this case, it seems a bit “heavy” to me to go to the extent of creating a whole app just to sub-categorize these recipes, when a drop-down would do the trick.

Thanks guys and eager for any thoughts you have about whether you think this makes sense!


Hi, I wanted to revisit this as I am seeing increasing need for this ability as I build out my Fibery Instance. I think this is also a useful capability that would complement Fibery strong relations features vs. the "Big 3 " of Notion/Coda/Airtable. Although I do believe right now through Formula Filters you can achieve this in Coda. So perhaps Formula Filters should actually be the request to achieve this?

Another thing I’d like to point out is that I noticed in the Fibery published Roadmap in Vizydrop, there is traction on a Form View. So if I think about this, when you publish a form publicly for users to fill out, often there is a drop down that might appear only if the value of a previous one is “x.” Such as if you choose “country” and the result is “United States,” you’d then be offered “State”

@Chr1sG and @Oshyan, as we often do, curious to get your thoughts on this:

  • have I explained it well?
  • You guys have any use of this?


1 Like

Yes, I would definitely like to see dependent field visibility. I see everything you’ve mentioned here, along with Field Groups, being a collection of overlapping and mutually supportive features.

  • Field visibility that depends on the value of one or more other fields (visibility as handled by a formula, simple or complex)
  • Collapsible field groups with group visibility likewise dependent on one or more field values
  • Form view, with dependent fields and groups making for much better, more easily navigated forms
1 Like

Hey, as you tend to provide, great follow-up and clarifying what I was trying to say!

This is a great point I forgot about:

Ability to have the dependent fields actually not even appear without the condition being met in the “predecessor” Field is a great benefit of this. By the way, I think you have discussed this elsewhere in fact, but I couldn’t off hand find and link that here.

I certainly like the idea of conditional field visibility, but I think there’s a feature which isn’t mentioned in @Oshyan’s interpretation, and is potentially the original (Apr 18) request: limiting options based on conditions.
This seems to be around determining which choices (single-select, multi-select or relations*) are available based on the selection made in other fields (or maybe some other formula).
This is indeed a useful feature, but the implementation can be tricky. For example, if a user chooses ‘downstream’ options and the ‘upstream’ selection is subsequently changed, making the downstream options invalid, what should happen? Should those choices be deleted/unlinked?

So to be clear, I think the two feature requests (conditional field visibility vs conditional options) can and should be discussed separately. For me, the latter is more valuable than the former.

*given that a single-/multi-select fields are basically the same as relations, I think it doesn’t make much difference to distinguish them in practice

1 Like

Interesting. Unless I’m misunderstanding you though, the only way I can imagine to do this would be by hiding/showing fields based on value of other fields. You could not literally “transform” e.g. a single select into a multi or relation. So it would have to simply be showing or hiding these different versions of the field. Perhaps the added functionality to support the request would be to somehow translate the selections from one field to the other, i.e. some kind of “sync” perhaps, but I really don’t see how this could work at all with relations anyway… Am I missing something?

I guess I expressed myself badly.
Here’s an example of what i mean: say the Project type has a single select field, with the options ‘Not started’, ‘In progress’ and ‘Completed’, and is associated with tasks that themselves have a boolean field that is ‘Done’, it might be desirable to only allow the user to choose ‘Completed’ if all related tasks have ‘Done’ = true. Otherwise, that option is greyed out.
Or another (random) example: you have a family tree app, with the type ‘Person’ and they can be related to an other Person via a relationship ‘Marriage’. You could limit the possibilities based on characteristics of the Person, e.g. only allow Person to be linked to an other Person (via Marriage) if both Persons have age > 16 (or whatever is culturally appropriate!)
By talking about single select, mutli select and relations, I was just emphasising that they are all in fact types under the hood.
It wasn’t really about transformation or anything more complicated, and yet it is not the same as field visibility being conditional.

1 Like

Interesting, yeah. So thinking about this more holistically, what I think I’m seeing is a system that:

  • Can be applied to both fields and groups
  • Can control either visibility or “locking” (user can see but not change data)
  • Uses formulas to determine these states based on values of 1 or more other fields

If you want 1 field to be influenced by another field, you probably edit the field to be influenced. Multiple fields could be referenced in the “visible or locked if” formula, e.g. “if both Field X and Field Y are empty, hide Field Z”. The same could be applied to groups, i.e. edit the group, and apply a formula in “visible or locked if”. Perhaps the formulae could be made more sophisticated if there are other properties one might want to control?

Anyway, does that make match your concept?

To be honest, the thing I would probably like to see the most is an iteration of the current auto-relations whereby instead of having matching rules being used to determine which relationships will exist, the rules (or even better, a formula) are used to define which relationships could be chosen from by the user.

1 Like

Good Commentary guys and @Oshyan! I wanted to respond on this last point - Chris, you helped me earlier understand the auto-relations and your Test Case usage of them is very nice. But in my day-to-day I haven’t found any use yet, although I continue to try. While I use extensively all other Fields, including lookups in both directions, as part of what makes Fibery so helpful to my needs.

Would love to see continued development as a priority of variations of all this, and hopefully integrating Formula Filters and Automations, and perhaps Conditional Formatting (“When Entity is “closed,” change color to “green” etc.) soon.

Thanks again!

1 Like