Forum Academy Marketplace Showcase Pricing Features

New behavior for "contains" vs "contains keyword(s)"

Thank you. I see

I’m using “contains” in a rg search for a text typed into a text field.

It works for a few seconds, but a second or so after the user stops typing the search results in the RG disappear. Why would this be?

I think the issue is that is case-senstive. How can I make the contains search ignore case?

1 Like

Did you find a solution to this? I am facing this currently.

As a solution, you can create a new field called query where you save data in a lower case format that you would like to use for searching purposes.
query = Input First Name's value:lowercase:trimmed Input Last Name's value:lowercase:trimmed Input Phone's value:trimmed

1 Like

where is the “contains keyword(s)” thing? All I see is “contains” and “doesn’t contain”…

Hey @allenyang, I’m wondering if this is “contains keywords(s)” intended behavior because I’m still not able to use this feature (it would make my list filter so much cleaner):

It doesn’t match with words that have any punctuation. So words at the end of a sentence, before a comma, or before a semicolon are not matched.

For example, I’m trying to do a search for text in my database. The text:

A new web app.

Wouldn’t match a search for “a new web app” because app has a period (.)

Let me know if this makes sense.

We aren’t able to repro that on our end; could you please submit a formal bug report with more details?

It works in a way I don’t understand.

I created a bug report #14883

Is it possible to add a “case-insensitive” version of the “contains” operation?


This would be so incredibly helpful. Very frustrating that currently it’s so difficult to create a decent search (and we’re not even talking sophisticated fuzzy search) when the :contains operator is case-sensitive.


Agreed. The search for text capabilities are greatly lacking without preloading all of the data client-side.

@allenyang - Is there a reason why the contains and contains keyword functions are not both case-insensitive? These were so close to allowing the flexibility that most users need, but JUST missed the mark. Any input would be helpful since doubling up the database just doesn’t make any sense.