Computed 'Conflict' columns (built from a Users→Allergies relation and lookup) don't appear as filter options on the Recipes screen, even though they calculate correctly in the Data tab

“I built ‘Conflict’ columns (If-Then-Else type, checking a User Profile lookup against a recipe allergen column) — they calculate correctly in the Data tab (Y/N), but they don’t appear as filterable options on the Recipes screen’s Filter Data. Only the raw ‘Contains X’ and ‘Current User X Allergic’ columns show up. Is there a column-type restriction here, or a different pattern I should use to filter a list by a computed comparison?”

Is the table a Big Table?
This sounds like one of the limitations of Big Tables.

Thanks for checking! It’s a regular table with only 20 rows, so I don’t think it’s a Big Table. Any other ideas what might cause this? Happy to share more screenshots of my setup if helpful, otherwise how do i check for sure whether its a big table?

You can tell by the icon next to the table name. If you show me a screen shot I can tell you.


here is a screenshot, thank you for your response

Of the 4 tables shown in your screenshot, the Allergies table is a Big Table, and the other 3 are regular Glide Tables.

Does your if-then-else column reference the Allergies table, either directly or indirectly?
Easy way to confirm that is to look at the values in that column. If they all show the word “Query”, that means that the Allergies table is being referenced.

![Screenshot 2026-07-07 134934|690x323](upload://

Hi Darren, thanks for the pointer! I checked and confirmed — all my conflict columns (Dairy, Gluten, Nuts, Eggs, Soy, Shellfish) show “Query” across every row in the Recipes table. So yes, they’re referencing the Allergies table (which you flagged as a Big Table).

Screenshot attached showing this. What would you recommend as the best path to fix this so the conflict values actually show up as filter options in the Recipes layout? I’m open to restructuring if needed — my Allergies table is a fairly small, fixed list (not thousands of rows), so happy to convert it to a regular Table if that’s the simplest fix.czb8S0JIaS2zj5kkQvg6SRA8mAH.jpeg)

Yes, that’s the best way to address it. You only really need a Big Table if you expect several thousand rows.

Here is what I suggest:

  • Create a new (regular) Glide table.
  • Export the data from your existing Allergies table
  • Import it into the new table (columns will automatically be created)
  • Go through each column in your existing Allergies table one by one, using Find Uses, and reconfigure as necessary to use the same columns in your new table.
  • Once you’re done, test to make sure nothing is broken, and then you can safely delete/unlink the existing table.

Hi Darren, thank you so much for the detailed steps! This makes complete sense. I’m going to work through it now:

  1. Create a new regular Glide table for Allergies
  2. Export the data from the existing Big Table
  3. Import it into the new table
  4. Go through each column with Find Uses to reconfigure references
  5. Test everything before deleting the old table

I’ll update this thread once I’ve completed the migration and let you know if the conflict columns start showing proper values in the Recipes filter. Really appreciate you taking the time to walk through this — huge help!