Forum Documentation Showcase Pricing Learn more

Repeating group 'in' constraint rather than '='


Hi guys.

I am trying to filter the content of a repeating group based on the unique id’s of the source list being a part of another thing’s list of texts.

RG needs to show a selection of questions from a master question set.
Master question set [Unique ID], [Question]
Questionaire [Questionare name],[Questions (list of master q set unique ID’s)]

RG needs to show a selection of questions from a master question set, based on a drop-down selecting the questionaire.

In the RG constraint it seems to allow only for ‘Unique ID =’ rather than ‘Unique ID in

Any suggestions? Many thanks,


Hi @andrewmackers :slight_smile: Can you compare both lists of Questions using the intersect with operator (instead of filtering using a constraint), in order to bring back the Questions that are the same in both lists?

For example, the data source of the RG could be:

Master Question Set list of Questions **intersect with** Questionnaire's list of Questions

Or is the data structured differently?


Thanks Faye…

So, the Master question set, each question has a unique ID. In the questionaires, each questionaire is a single item with a unique ID, and a field which contains question ID’s comma separated (list of texts).

I’m almost sure there is a simple solution staring me in the face with ‘contains list’ or something…



I sent this feature request to Bubble a few weeks ago (as I also thought it would be hugely beneficial) and they confirmed me that they have added it to their backlog list. No estimated time of completion though…



So, the real answer here is: Your data model is a little whack-a-doodle. Fix that.

You are trying to present a list of Questions, right? Questions should be a Thing.

A list of Questions that you want to present is modeled by a Thing of type Questionnaire, whose function is to hold a List of Questions.

Your Repeating Group content is now simply: Some_Questionnaire's Question List.

(Aside: Is “Master question set” actually a Question? Or is that really a thing with two lists on it? I can’t tell. Is your [Question] object a Thing already? Or is it just a field??)

You can fix this by creating proper data types and then executing a couple of Bulk operations (maybe even just one).

Note that we never need to model something like a “Master Question List”. The list of all Questions in the database is simply Do a search for Questions (constraints: none). Similarly, all Questionnaires in the universe is Do a search for Questionnaire (constraints: none).

That being said, we still need to understand the transform to get from a list of UIDs to a list of questions as you have them now.

That’s going to be something like the following (I can’t be sure as are description of your objects is a bit vague):

You can use :filtered with the Advanced condition.

Master question set:filtered where the Advanced filter is something like “Questionnaire’s Questions contains This Master question set’s Unique ID”

(The Advanced filter condition loops over a list of things.)


But it seems to me that what you have named “Master question set” is actually just a Question, right?

In that case, the mistake that’s been made is defining Questionnaire’s Questions as a list of texts. Questionnaire’s Questions should be a list of Questions.


Thanks for this Keith, I’ll take some time to digest. In the meantime, maybe this explains things better:


This could be one of those examples of where Bubble data operations are counter-intuitive to relational DB / SQL thinkers like myself.


Yeah… don’t do that. What you’ve done here is built your own database inside of the database.

What you actually have here are Questions. Make Question a Thing. Questions have a text on them (the actual question body if you will – to type out “What is your name?”) and a Category or perhaps a Type (some are “About the User” some are “About your pet”).

Just as a Question is not a text, a Category is not a text. A Category is a thing. It has a Name (a unique human-readable name for how we shall refer to it) and a Label (that we can use in dropdowns as you want to do).

But this is kind of a whack-a-doodle way to do onboarding, which is obviously what you’re trying to do, right? The RG is not the appropriate interface. Though Category is helpful.

I’ve created exactly the answer you’ve requested in my example – just to show it can be done. But a couple of other onboarding examples are also presented:

Editor (anyone can view):


BTW, when you examine that project, you’ll see that the subtext of what I’m telling you is that what you’re trying to do is fairly clever (have kind of a dynamic list of onboarding questions), but that isn’t really a timesaver in this case.

The kinds of info you are trying to collect should not all be submitted as free text fields. Each thing you you need to collect to onboard a User or a Pet has specific user interface requirements and so it doesn’t make your life easier.

What does make your life easier is doing things like controlling the options that a user can select (you’ll see how I did that with Eye Color and Species, for example). You might want to do something similar for Breed – which I left as free text in my quick example.

Also, I was just playing with some ideas here in this example, and even the “better” onboarding experience is not really right (but then, I’m not trying to build your site for you). But there are some kind of interesting dynamic things I’ve done there just to give you an idea of things you might try.

For example, on the “better onboarding” page, once the User fills in the user-specific questions, you’ll see that that group disappears and the text in the headline changes, based on that. But that’s NOT an ideal thing to do in onboarding, either, as what if the user typed their name wrong or selected the wrong eye color.

It’s really not a good idea to hide those inputs automagically like that (you’ll also note I was doing those with autobinding – if I were doing them without that, there would be a confirm button of course that would kick off a save action – which we do anyway when “Let’s Go!” is clicked).

But that kind of experimentation is kind of fun to do and helps us hone in on things that might improve the onboarding experience.

But the idea of having a dropdown to select the User questions vs. Pet questions is just not helpful and makes for a confusing (and more time-consuming) experience than it needs to be, for a variety of reasons.


Keith, thank you so much for all of the thinking and effort you have put into this.

One thing which I think you have assumed is that onboarding is at the heart of my use case - which it isn’t.

Think of it more as a subscription.

A question set is comprised of a number of questions from a single bank of questions.

When creating / editing a question set I can add / subtract questions in the master bank.

There can be multiple question sets that include the same questions.

QS1: Q1, Q2,Q3
QS2; Q2,Q3, Q4


Then you can totally do this, just as shown on index page and data tabs.

I did not create a Questionnaire data type (with a list of Question type on it) but that’s all you’d need to add!

Note that the “type” concept is still useful as you could use that idea to programmatically set an input type in the RG (if indeed you are collecting answers to Questions).

(A Question might have data about the nature of its Answer — free text, boolean, multiple choice, etc.)