Dynamic Select Field Options

App Development
1

Dynamic Select Field Options – Can users create/manage options from the front-end?

Hi everyone,

I have a question about Select Fields and dynamic options in Tadabase.

Currently, when I create a field with the Select field type, I have to manually add each option in the field configuration/database. This works, but it requires me, as the developer/admin, to manage the options.

What I would like to achieve is:

  • I create a Select Field (for example, “Collection”).

  • The client/user uses the application through the front-end/web interface.

  • The client should be able to create a new option directly from the application, without accessing the Tadabase Builder.

  • Once the client creates a new option, that option should automatically become available in the Select Field.

I know that one possible solution is to create a separate table (for example, Collections) and then use a Connection between the main table and the Collections table.

However, I would prefer not to use a Connection field for this particular case because it changes the behavior of the field, especially when using Filters and Search components.

So my question is:

Is there any way to dynamically add/manage the options of a native Tadabase Select Field from the front-end, using an action, automation, JavaScript, or another Tadabase feature, while keeping it as a native Select Field?

For example:

User clicks “Add Collection” → enters “Summer Collection” → submits → “Summer Collection” becomes a new option in the existing Select Field.

Is this possible in Tadabase, or is using a Connection/related table currently the only way to achieve something like this?

Any ideas or workarounds would be greatly appreciated!

Thanks!

2

Hi Biner — you’ve basically answered your own question, and it’s the right answer: this is what connection fields are for.

Select fields are static by design — the option list lives in the field config, so only an admin can touch it. When you want users to create options from the front end, the pattern is:

  1. Create a Collections table (one text field is enough to start).
  2. On your main table, replace the select field with a connection to Collections.
  3. In the app, add a form component for Collections (or allow adding a connected record from your main form) so users can create options without ever seeing the builder.

New records show up as options immediately. And you get things a select can never do: extra fields on each option (color, sort order, “active” flag), role-based control over who can add or edit options, and filtered dropdowns so different users see different option sets.

One thing to decide early: whether duplicates matter. If “Collection” names must be unique, add a validation rule on the form, because users will absolutely create “Summer” and “summer”.

What’s the Collection driving downstream — filtering, reporting, something else? Happy to suggest how to structure it if you share a bit more.