Color tags not showing correctly on published version of app

Hey team,

Looking for a little assistance. I’ve set up a color column in a choices table to change the color of a tag in my app depending on the choice (in this case, a “store”). All works perfect in preview but the published version of the app defaults all colors to the accent. Is this a bug or have I missed something?


The color input column must be an if-then-else column.

1 Like

I just did a test and it works normally in published app for me.

It doesn’t have to be an ITE column.


Thanks, I’ll demonstrate the method without ITE. Let’s see how these conditions and color tags work, especially in the 3rd and 4th columns.

  1. I did not find a condition where a difference in values between the edit column and the data column could produce a color (see the 3rd column).
  2. How is the color defined when there is a repetition (see the 4th column)?

1 Like

And this fifth column works, but the color still needs to be defined and placed in the data column. Then, @ridelogix what does your data table look like?

1 Like

Thanks, both!

Ok, so the main table (sample output) looks like this:

With a choices table driving the store colors:

Which then seems to work in preview mode fine as it picks up the right colors (orange and purple):

But then in published mode with a user, it defaults everything to accent:

Feels weird to me that this behaves differently in preview vs. production!


1 Like

Coincidentally your store name is the same, what if it has a variant? Maybe this is generated wildly like my 4th column example. I doubt that in the 5th column example I can work with sources from different tables. Maybe this problem will go away if you define the colors again in the same table, rather than across tables.


Thanks @Himaladin! This behaves the same regardless of store name variant. I am also not sure I prefer to define the colors in the same table as that removes the relational nature of it all (i.e. I don’t want to have to nominate a colour for a store entry every time that store comes up, just to refer to the choices table).

I don’t quite understand what you mean.
How about trying the first method from the thread above, where you need to add one more ITE column to your sample_output table? This column will align the store name and color in the same table and row, so you won’t need to use your choice table anymore.

Or do you have a relation column for the store name and a lookup column to pull the color from your choice table?

1 Like

Thanks! I’ve aligned to the ITE method for now and ditched the choices table reference. It was less work than I thought to set-up the filters but i still see a scalability issue if you are dealing with 500 stores and dynamic changes to colors based on their designation. Which is why i think the separate table works better if we could get it to function properly. Wdyt? Either way, thank you for your support :slight_smile:

1 Like