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:
“Food”
Choices:
Meat
Vegetable
Fruit
Values in 2nd Dropdown:
Beef
Pork
Spinach
Lettuce
Broccoli
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:
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
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
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.
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?
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.
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.
I think this is not quite enough as these are not intuitive to set up, I am frequently surprised to see them popping up when I have set up my relations a certain way. It seems @Eugene_Vabishchevich would like to see this feature too, and I’m guessing @Oshyan given his expansion of my original request into an even more well-written one. Not to beat a dead horse that I’ve commented on already a few times tonight, but none of us are able to vote for this request (unless Eugene still has a vote), but we all presumably have a need. I have a big need and have had it since I wrote this request 1 1/2 years ago.
Are you talking about types or fields? I don’t want to create additional types for dependent dropdown lists. For instance, if I have a dropdown field I want to add the second dropdown but display its values dynamically based on the State.
Yes I second this around this request. It would be great to be able to simply create drop downs that can dynamically relate to results in other drop downs. Very important for categorizing data in Fibery. In fact, with this functionality I could vastly reduce both the amount of Types/Db’s in Fibery - simplifying my instance. I could also remove some very LONG single-selects I’ve had to concoct to allow me to categorize Entities, when if I could use dependent drop downs, which basically provide a sort of “sub folder” functionality, I’d have a much more elegantly organized set of data in Fibery.
I would really like such a feature, especially the conditional relationship evoked by @Chr1sG
We are currently trying to leverage Fibery as a framework for Holacracy. I think it can work (which is already incredible) but we are sometimes pushing the limits
We have plenty of use cases where conditional relationship would be useful: a User takes on a task as one of its role in Holacracy so would like to restrict the Role relationship to only the Roles of this user. When dealing with a Circle, only suggest the Roles available in this Circle.
The auto-suggest feature does help a lot but it is too limited somehow.
Well relations are sometimes indirect and not easy to infer by the auto-suggest engine.
For instance, a Task as one Owner (a user), a Owner as many Roles. I would like, once a Task as a Owner, that the suggested Roles are the one filled by the Owner. Unfortunately, it does not happen
Thanks for the extra info.
Indeed the current auto-suggest relies on the relations following a specific structure, and it’s a pattern your use case doesn’t fit.
I hope there will be some good news for you soon
