Create Field nested/Dependency for Single Select Options (e.g., Categories and Subcategories)
S
Saul Coronado
I would like to propose a valuable enhancement to the solution by introducing the capability of nested fields or field dependency for single select options. Specifically, I envision this feature being highly beneficial for establishing a hierarchical relationship between categories and subcategories within the system.
Currently, our organization utilizes single select options to categorize and organize various data. However, we often encounter scenarios where there is a need to create a structured and dependent relationship between these categories and their corresponding subcategories. By introducing nested fields or field dependencies, we can significantly enhance data management and streamline workflows.
The suggested functionality would allow users to create a parent-child relationship between the category field and subcategory field. When a specific category is selected, the system would dynamically display the relevant subcategories associated with that category, creating a seamless and intuitive user experience. This nested field structure would enable users to navigate and select options in a more organized and efficient manner.
Furthermore, it is essential to have the flexibility to customize and modify these field dependencies. Administrators should have the capability to easily add, edit, or remove categories and subcategories, with all dependent fields automatically updated to reflect the changes made. This versatility would ensure that the system remains adaptable to evolving organizational needs.
By incorporating nested fields or field dependency for single select options, we can empower users to effectively manage and analyze data while maintaining a structured and interconnected data model.
Canny AI
Merged in a post:
Limit Selection Based on Other Field's Selection
R
Robert DeBergh
I'd like to "Limit selection to specific options" in the form but define which options are shown based on the criteria of what was selected in another field.
For example:
if Field 1: Option A
Then limit options in Field 2 to: a, b, c
or
if Field 2: Option B
Then limit options in Field 2 to: d, e, f
The current workflow makes me create and hide fields to achieve this but that unnecessarily increases the number of fields used in our records. If we could filter the list of options based on another field's selection, then we could condense the option list into one field but only display the options we want the user to select based on the category defined in the previous field.
Feel free to reach out to me at robert@terraytx.com if you have any questions or need further explanation!
Jon Darbyshire
Great to hear your perspective, Robert DeBergh! I have a few more questions for you:
- Could you provide a few more examples of how you would like the field options to be limited based on the selection in another field?
- Are there any specific fields where this feature is most needed or would be most beneficial?
- Would you find it useful to have an option to manually override the automatic selection limitation in certain scenarios?
R
Robert DeBergh
Thanks for following up, Jon Darbyshire!
- I think it'd be best to show you what I'm trying to accomplish with my current solution. We are creating a work request solution for team members to report errors that occur within a process. Each work request will have a "Failure Type" that will be used to identify the process the error occurred within. Currently, once the "Failure Type" is selected, a multi-select section for that failure type is shown that lists the potential errors that occur within that failure type (see screenshots).
Instead of having to make a separate "X Failure" field for each "Failure Type" (eg. Camera Failure, Drip System Failure, etc. as seen in the first screenshot), it'd be ideal to have all of the failures listed in one field "Failure" but filtered based on the "Failure Type."
- Yes, for our case, the multi-select field would be most beneficial.
- Not sure if I'm understanding the question. Are you asking about the ability to manually override the feature by someone filling out the form or a solution manager creating the form?
Nate Montgomery @ SmartSuite
Merged in a post:
Cascading Selects
T
Tim Klug
A powerful and key feature would be the ability to display a specific list of select items based on the selected value of another select list. Traditionally known as cascading dropdowns.
An implementation example might be:
- The selection of a dependent select field would occur on the Manage List detail view. This is the same view include choice descriptions or values.
- Add another checkbox under List Options to select Create Select Dependency.
- Upon checking the list option, display a section titled Select Dependent Field. This would be a dropdown listing the other Select fields in the current app (or better, a select field from any app in the solution).
- Upon selecting an item from the Select Dependency list, a set of drop downs would display next to each select item. Similar to how values or choice descriptions are displayed dynamically.
- The new select box for each select row would contain all the values from the selected dependency field.
- A value is chosen for each item which, during runtime, is displayed in the available list only if the given value from the dependent field is selected.
Nate Montgomery @ SmartSuite
Merged in a post:
Field dependencies
M
Matteo Spaggiari
I need to have a relation between two different fields depending on each other. An example: we would like the values of a single choice field called "Province" to be based on the selection of another single choice field named "Region".
Is it possible to implement this relationship soon?
M
Matteo Spaggiari
Hi Jon, an answer to your questions:
You asked how the system shuold behave, in question number 2, it must empty the 'Province' field and refilter based on the new "Region" selected, as it did before.
To start do a Region named "Emilia Romagna" and one named "Lombardia".
In "Emilia Romagna" put the following Provinces: Piacenza, Parma, Reggio Emilia, Modena, Bologna, Ravenna, Ferrara, Forlì-Cesena, Rimini.
In "Lombardia" put the following Provinces: Sondrio, Milano, Cremona, Mantova, Pavia, Bergamo, Brescia, Como, Lecco, Lodi, Varese, Monza.
You start with those, when you are done write me back and we will see.
Thanks.
Jon Darbyshire
Hey Matteo Spaggiari, thanks for your feedback! I have a few more questions for you:
- Can you provide more examples of the fields and their dependencies?
- How should the system behave if a user changes their selection in the 'Region' field after they've already selected a 'Province'?
- Are there any specific regions and provinces you want to start with for this feature?
Y
YES Integrations
We can currently do something quite similar to this with two linked record fields and a dynamic filter
T
Tim Klug
YES Integrations: Interesting. I'd love to see your workaround. Would you be willing to share a copy of a solution that demonstrates this? Scrubbed of any confidential data of course.
To SmartSuite: I still think having it native to the multi-select field would have the most impact on the various use cases out there.
Y
YES Integrations
Tim Klug: Hi Tim - I'll describe the workaround here to save having to create a new solution.
Each option in your two proposed select fields would need to be an individual record in two new apps. The independent field becomes app A and the dependant field (the one displaying "a specific list of select items based on the selected value of another select list") becomes app B.
Record in app B are linked to appropriate records in app A. Disable linking to multiple records if you want.
You can then set up two linked record fields to replace the original select fields, and set to a dynamic filter in link to app B, filtering based on the link to app A.