Allow the user to select from a drop down or choose other?

Couple of questions:

  • it looks like your first choice component is a multi-select. Is that deliberate? I ask, because it complicates things a little bit.
  • if a user adds a “Suggested Local Break”:
    – would this be in addition to the choices they’ve made from the first list, or instead of those choices?
    – would you want their suggestion added to the first list for the next user that comes along?

Thanks @Darren_Murphy

See answers inline below:

  • it looks like your first choice component is a multi-select. Is that deliberate? I ask, because it complicates things a little bit. // Yes multi-select is deliberate
  • if a user adds a “Suggested Local Break”:
    – would this be in addition to the choices they’ve made from the first list, or instead of those choices? // Perfect world also be addition to the choices, however it it’s a pain, we can make it Instead
    – would you want their suggestion added to the first list for the next user that comes along? // Yes must add to the list the next time

Something else to mention, is that I’m not using sheets, but Glide Tables. As I was looking at the Column Array options

Okay, this is quite tricky. And I’m not sure that can give you a good solution right now. I’ll need to think about it a bit.

But let me try and explain the challenges.

First thing - whenever you’re using multi-select it’s always best practice to write the values as RowIDs. This is because a multi-select will result in a comma-separated list, and you can never be certain that your item descriptions won’t contain commas. And this is especially true if you’re accepting values entered by users and adding them to the list.

So ideally, you would have your first choice component configured to use RowID’s for the Values, and your location descriptions as the Display As. This way, you be certain that stuff will never be broken by a rogue comma, and you can also safely change your location descriptions without fear of breaking existing relations.

So, if we are to follow my above advice, then…

This is a challenge, because we don’t yet have a RowID for the suggested item. So the only option would be add the text as entered. But then as well as running the risk that the user might include a comma, we’ll also have plain text intermingled with RowIDs in a single joined list. And that will present its own new set of challenges.

This is not too bad. We could simply add it to the list with the Submit action, and Glide will generate a RowID for it, ready for next time. But we’d still have the problem that we’re saving this as plain text, so it won’t be compatible with the RowIDs that we’d normally save.

Anyway, I hope that’s explained the challenges, and as I say I don’t have a good option off the top of my head. We could probably use a bit of funky if-then-else logic to deal with the plain text/RowID incompatibility, but I’ll need to give that some thought.

In the meantime, quite possibly somebody else will see a simple option that I’ve overlooked.


@Gary_Willmott - another question. What is the end goal here? And what I mean is, what will happen with the users choices and how will they be used?

My family is in town and I created an app so everyone can have an overview of our schedule (a calendar view of what I called “slots”), a list of possible activities (which I called “activities”), etc. Note that slots and activities are two different tables: a slot is an entry in a calendar/agenda, an activity is something to do but does not include any information as to when the activity might happen (if at all).

When adding a slot in the form screen, the user can select from a list of predefined activities or add his own description of the slot, though this will not add an activity to the activities table. The situation is similar to yours I feel.

It’s good enough for my use case. Below is how I displayed the components in the builder. There are other components in the form, in particular start and end date-times to define the slot. This screenshot though seems related to your use case.

1 Like

Working backwards, users will be able to filter the gallery by surfers that are tagged essesntially
This is critical as they want to see photos of themselves or friends and not just random people.

I’m not sure I follow. In your first screen shot, it looks like the user is being asked to select/tag locations - not surfers?

Sorry I got mixed up as I’m using a similar scenario for surfers, as they want to filter by location and by surfer, see below

Screenshot 2022-09-20 at 14.20.42

ie. Each Gallery post must have a location / surfer tagged with it.

Ah, I see.
So the context is that this selection is made when a user is uploading a photo, and so they are tagging the location where the photo was taken, yes?

1 Like

Correct, you can see it here

It’s the “Apply to be a Photographer” form, yes?

That explains the multi-select, I think. So when I submit the form, are those locations tagged to me as a user (rather than tagged to a photo)? They must be, I guess, because I don’t see anywhere in that form to upload an image.

Do these then become the Locations that I am “following”, or?

Apologies for bombarding you with questions, I’m just trying to get a clear picture in my mind.

No it’s the “upload footage” button in the top nav
I’ve approved you, so you will see it now.

hehe, we seem to have switched mid stream. Your original screen shot had a list of locations, not surfers.

But I guess it’s a similar use case in both. In one case, you’re tagging one or more locations to a photographer (I think?), and in the other you’re tagging one or more surfers to a photograph.

Alright, everything I said in my earlier reply still holds in terms of the challenges. But I have a clearer picture now. Let me think on this a bit.

Yeh correct, they are both very similar use cases:
I’ve given a breakdown to give more context

Gallery Item:

  • Created by an approved Photographer
  • Can have many surfers assigned
  • Can have 1 location assigned to it


  • Can can follow many locations
  • Gets notified (by email) once a photographer uploads to a location they followed


  • Many can be created by the Admin or photographer

Hey @Darren_Murphy what you think so far?

Do you think the Trebuchet method would work in this scenario?

Yes, I definitely think you need to be using Trebuchet or some variation of it.
But I’m still not sure about the best way to handle the mix of current values and a new (optional) value being added in the same step. I’m thinking that you probably need to be creating a row for the optional value, and then using the generated RowID in the same action sequence to update the joined list. But I’m not really sure if that would work, or how reliable it would be if it did work. I’d need to experiment with it.

Is there any chance I can get access to a copy of your app to experiment with?

Hey @Darren_Murphy , yeh happy to give you a copy, how do I give it to you?

Probably the easiest is to send me your team invite link (send it to me privately).
You can get it from your Team Members page

Thanks, sent

@Gary_Willmott - after taking a look at your App and experimenting with it a bit, I think the solution here is to essentially create a form within a form.

I’ve sent you a video privately that explains in detail, but essentially the idea is that if a User wants to add a new Surfer, we allow them to do it from within the main form. The new surfer will then appear in the multi-select and can be included when the form is submitted.

This is something that can only be done with a custom form.

1 Like