# Reusing Single- and Multi-Select options? **URL:** \ **Category:** Get Help\ **Created:** [August 28, 2021, 1:40am UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952 "2021-08-28T01:40:26Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [August 28, 2021, 1:40am UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/1 "2021-08-28T01:40:26Z")
Is it possible to define the options of a Single-Select Field in one place, and have the definition instantiated/referenced/used in different Types? Example: I want to define a Single-Select Type for choosing a “Role”, such as: - Content Writer - Web Developer - Project Manger - SEO Specialist - Admin - Sales Manager Let’s assume I have four different Types in my app that each need one of these Single Select fields with these exact options. I want to be able to define this field (the options) in one place, and have this definition used (and updated, should I change it in the future) in each one of my four different Types that has this kind of field. The same question applies for Multi-Selects fields. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [August 28, 2021, 9:13am UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/2 "2021-08-28T09:13:15Z")
It sounds like you would be well-served to create a type for this purpose, and then create many-to-one or many-to-many relations (to simulate single- and multi-select respectively). Depending on which App(s) the referring types are in, you may or may not want these ‘enums’ to live in a dedicated App of their own. Note: It’s also worth thinking about permissions for these enum types. ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [August 28, 2021, 3:37pm UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/3 "2021-08-28T15:37:22Z")
> [@Chr1sG](#): > > create a type for this purpose, and then create many-to-one or many-to-many relations (to simulate single- and multi-select respectively). OK - but could we maybe get an option to display such fields as a Single- or Multi-Select in the UI? I.e., so they would show up in the right-hand side of Entity views. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [August 28, 2021, 3:46pm UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/4 "2021-08-28T15:46:53Z")
If you create a many-to-one relation, it should show up on the right hand side but many-to-many will show as collections (on the left). ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [August 28, 2021, 4:01pm UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/5 "2021-08-28T16:01:26Z")
Yeah, I have also wanted something like this. I think it’s quite similar to this previous request by Chris himself 😁 > [@Fields applicable to all types](https://community.fibery.io/t/fields-applicable-to-all-types/910): > > Can we please have the possibility to define fields that are to be available for all entities within a given app, or even all entities within the workspace pray The question I usually ask myself when considering whether to create a new Type is whether there is any actually useful data _beyond the name_ that I would want to store there. Whether there is any actual utility in having a full-on Entity for every option (of course options in multi-select _are_ basically entities already, I think, but still). Anyway, in many cases the answer is no, I just want a common set of options. There are some examples of these solutions from Fibery itself, such as the newer “World” Types, but honestly I think that’s a great example of where a Type can be overly “heavy” as a solution. The World “App” actually has tons of _maybe_ useful data in it, such as TLD, “region”, etc. But I am willing to bet that most people who want a consistent list of countries to choose from actually do not need 90% of that additional info. It’s sort of just there because, well, it had to be made as a Type to be usable in multiple other Types (because of Fibery limitations, really), so you might as well add a bunch of additional info just in case. But the reality is that for most people a simple list of countries, expressed in a single-select, would probably be _fine_. Perhaps even _preferable_. In the case of the currency “App”, at least it is pulling live rate data (I think the country list is updated too, but still), so it seems to have more reason to be an “App” with Types to me. This actually raises an idea I haven’t necessarily seen discussed yet, which is something like 1: a “data store” (“array”?) type of field or other “object” in Fibery and then 2: the ability to reference data to populate _options_ of a field. This is different than the existing “Lookup from”, although perhaps it could work similarly. The idea is that it’s not pulling the actual, selected value(s) from some other already connected Type/Entity. It’s pulling the data from a Field (or other data store?) and representing it _in one of several different ways_ (perhaps). Like let’s say you could do this, reference data somewhere from a field, then set the field data type, and the referenced data would be represented differently depending on that. So if it was a Rich Text field, it would just instantiate all the data there in markdown or plain text, I guess. If it were a multi-select, it would show all the options, and allow you to select from them. I’m kind of thinking out loud here, and realizing that it only probably applies to a limited number of field types, which may suggest it’s not a universal enough concept, or perhaps just that it would filter the list of what field types you could select… Anyway, that idea would address your need and perhaps some others. Like many things in Fibery it might be usable in creative ways. Or at least the idea could be adapted into something that could (the ability to have “data objects” that exist somehow independent of Types might be very useful for sophisticated formulae for example). I’d welcome any thoughts to refine it, it’s definitely raw… ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [August 28, 2021, 4:28pm UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/6 "2021-08-28T16:28:47Z")
> [@Chr1sG](#): > > If you create a many-to-one relation, it should show up on the right hand side but many-to-many will show as collections (on the left). This only works to emulate a “Single Select”. It doesn’t work for my current need, which is to define a “Multi-Select-like” field for specifying _Permission Groups_ (i.e., where multiple Groups can be selected). ---
**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\ **Post date:** [August 28, 2021, 4:51pm UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/7 "2021-08-28T16:51:52Z")
> [@Oshyan](#): > > reference data somewhere from a field, then set the field data type, and the referenced data would be represented differently depending on that. So if it was a Rich Text field, it would just instantiate all the data there in markdown or plain text, I guess. If it were a multi-select, it would show all the options, and allow you to select from them. Seems like _Rules_ might already be able approximate this – create a Rule on the _data source_ (i.e., some field somewhere) that triggers when it’s updated, and have the Action recreate (or update) the “translated result” as new entity(ies) in the “output type”, via a Script. If that works - Cool! 😃 \* except of course the Types are not dynamic ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [August 28, 2021, 5:05pm UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/8 "2021-08-28T17:05:08Z")
> [@Oshyan](#): > > I think it’s quite similar to this previous request by Chris himself Actually, my original request was more about laziness(!) in that I thought it would be nice to be able to define a workflow once and make it available for multiple types simultaneously, but I can see why what i wrote can be thought of as large set of cases, including this one. > [@Oshyan](#): > > a Type can be overly “heavy” as a solution Yeah, i get that. I think i might have even asked in the past if there was a technical reason why a single- or muli-select couldn’t be ‘owned’ by more than one type (and the answer was, yes, there is). > [@Oshyan](#): > > something like 1: a “data store” (“array”?) type of field or other “object” in Fibery There is actually some discussions internally about ‘global types’ or ‘app-less types’ where there may exist the need for ‘shared’ data. I don’t think it quite matches what you’re describing (and probably couldn’t be called lightweight) but there are potentially some overlapping use cases. ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [August 28, 2021, 6:35pm UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/9 "2021-08-28T18:35:29Z")
Thanks for thinking along with me guys, and Chris for your inside view. 😃 I know that all this feedback is going into the hopper and the team has to consider many angles, including what people want, and also what is feasible or works within the current back-end design, etc. It may be unlikely that any particular solution an individual user proposes actually becomes _the_ solution that meets X number of various but related needs. So to kind of sum up my sentiment just generally, and I think you and the team already know this, but it’s worth restating: Fibery is extremely powerful, but the ways to access that power sometimes feel “heavy”, not just in theory, but in practice. I think this is especially so with in the example of Types, and using them just to get certain capabilities like re-usability. You see and feel the “heaviness” in the way they clutter up your workspace, e.g. filtering of Types in general Search (do you really need your Country list in there? Probably not!), or way that Relationships affect your Entity Layouts and no doubt affect performance, and many other respects. I know many big changes are being worked on and contemplated, the move to “blocks” being most immediate I think. But I hope as well that the team is strongly considering how to meet the needs of functionality **in-between existing, simple, non-reusable Fields, and full-blown Types**. 🙏 ---
**Author:** ![Dimitri\_S](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/dimitri_s/32/1683_2.png) [@Dimitri\_S](https://community.fibery.io/u/Dimitri_S)\ **Post date:** [May 9, 2022, 8:50pm UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/10 "2022-05-09T20:50:14Z")
Bumping this as its something I am finding myself in need of now. For my use case we as an agency provide a list of Services, it would really help to have this Services list as a global collection that can be used as options in multi-select fields in various databases. ~~Almost thinking of creating a script that syncs the options between our databases Services multi-select fields but seems like it would be complicated.~~ Creating a space/database to use as a global single/multi-select works okay but has several drawbacks and I would consider it more of a workaround. **EDIT:** Created a feature request based on this thread: > [@Global single and multi-select field options](https://community.fibery.io/t/global-single-and-multi-select-field-options/2779): > > Would like the ability to define the options of a Single-Select or Multi-Select field in one place, and have the definition instantiated/referenced/used in different Types? Example: Defining a Single-Select field for choosing a “Role Type”, such as: Content Writer Web Developer Project Manger SEO Specialist Admin Sales Manager Let’s assume I have four different Databases in my app that each need one of these Single Select fields with these exact options. I want to be able to define this fie… ---
**Author:** ![Viktar\_Zhuk](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/viktar_zhuk/32/1934_2.png) [@Viktar\_Zhuk](https://community.fibery.io/u/Viktar_Zhuk)\ **Post date:** [May 11, 2022, 7:40pm UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/11 "2022-05-11T19:40:26Z")
My two cents From semantic point of view Single and Multi Selects are treated as a part of its parent Database. - when you share a Template it will be included - when you move Database to another Space it also moves As we know its specifics (e.g. Icon, color, relation to parent, security settings) - they have more rich layout on Entity view - non Creators may add (and only add) options to it if configured ---
**Author:** ![Dimitri\_S](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/dimitri_s/32/1683_2.png) [@Dimitri\_S](https://community.fibery.io/u/Dimitri_S)\ **Post date:** [May 12, 2022, 12:30pm UTC](https://community.fibery.io/t/reusing-single-and-multi-select-options/1952/12 "2022-05-12T12:30:24Z")
I agree, but the process of creating “global” single/multi-selects can be made more intuitive and less messy, I also think it would be a relatively easy feature to implement: > [@Global single and multi-select field options](https://community.fibery.io/t/global-single-and-multi-select-field-options/2779/3): > > Yeah this works very well, but there are two problem with this approach: 1) Its unintuitive - only seasoned Fibery users know that multi-select fields are secretly hidden mini-databases. Maybe having a normally off checkbox on the single/multi-select field creation modal for something like “Make these options available globally (in other databases)” which automatically does what you suggest, but creates them as “hidden” space/databases. Something like this: 2) It creates a bit of cl…