When adding different rules with colors for columns there is an issue.
The result shows a different behaviour between coloring only selected columns vs. coloring the whole row.
See rules in screenshots.
Can only upload one screenshot 
Can you try changing the order of the conditional formatting rules?
or could you give me access to that doc?
The order of the conditions does not change the effect.
How can I change the doc with you?
Thanks in advance.
top right, share with removed my email after problem was solved
I shared the doc with you. Thanks for helping me out.
that should have fixed it? Your rules were all accepted as ātrueā, thus it would color renamed and moved both yellow and green. I am not sure which rule took priority.
Iām aware that I can change the conditions. But I wondered why the chosing of different columns to be coloured in the same rule leads to two different effects?
Also the processing of the rules should follow a fixed order, e.g. bottom to top. Otherwise this will lead to inconsistencies like this one.
Iām aware that I can change the conditions. But I wondered why the chosing of different columns to be coloured in the same rule leads to two different effects?
as I said, all three rules were considered to be true. it has nothing to do with the fact that you chose different columns.
here all cells should be both green and yellow. In your previous example, moved and renamed are supposed to be both green and yellow as well.
Also the processing of the rules should follow a fixed order, e.g. bottom to top. Otherwise this will lead to inconsistencies like this one.
I agree, but I believe that there are more urgent issues then the order of conditional formatting. The fact that you are not able to change the order via drag-and-drop gives you an indication that they have not put any time into the prioritization and ordering yet.
Yes, but as you say. All rules are true: Both columns āmovedā and ārenamedā should have the same colours, regardless what columns I chose in the format rules, wouldnāt you agree?
Also drag and drop usually works, you can try with conditions like āsomevalue>3.0ā vs. āsomevalue>5.0ā. When the value is ā7.0ā both are true and by shifting the rules in priority you can see the effect accordingly.
That is why I consider this more a bug and brought it to attention.
I just realized that there is a drag -and-drop for conditional formatting, so screw my earlier point 
so I agree, there has been put some thought into it.
But I could not reproduce a single example where āmovedā and ārenamedā had the same formula but different results?
You might be right with the other rules you talked about (conditions like āsomevalue>3.0ā vs. āsomevalue>5.0ā), I have not checked that.
When you see my existing example from the data section. Both columns are correctly filled with green. When you select āAll columnsā the row will be green, but not the two fields āmovedā and ārenamedā.
This happens although no other conditions were changed. Imho the fields should either be always become orange (because result is true as well) or green, but not this mix of āorange over greenā.
ok, now I see.
agreed, its bugged; however the ordering of the different rules appear to work when not all columns are selected.
As long as at least one column is not included for for all filters, everything works fine (as far as I can tell?). The ordering however does not work when one conditional format is applied to all columns simultaneously and another is applied only to some columns.
Yes, this perfectly describes the issue here. Maybe I was too unclear before.
Hi there, Iām a software developer at Coda.
The confusion here is likely because we donāt have any clear explanations of the priority of conditional formats in our tables, so hopefully I can help. There are really just two rules:
- Per-column formatting takes precedence over whole-row formatting.
- Otherwise, items higher up in the list of conditional formats take precedence over items lower in the list.
Thus, if you have two per-column formats competing, the one that is higher on the list will win, but if you have per-column vs. whole-row formatting, the per-column will win, even if itās lower on the list.
I can see how this can be confusing, so Iāll check in with our product team to see if it would make sense to have the priorities solely based on order instead of having two levels of priorities.
I hope this helps!
1 Like
Ah, that makes sense!
Thanks for explaining.
Maybe this should somehow be mentioned in the settings.
The per-column formatting taking precedence over the ordering of the formats in the list was also confusing to me. Seems like just the order in the list should suffice?
Hi Tim. Thanks for this.
While this explanation is clear (thanks) Iād like to make the case that this current implementation is perhaps sub-optimal for some common use cases. The current approach means that per column formatting takes precedence over whole row formatting as you say - whereas I would argue that this is unnecessary and only the ordering of the rules on the list is what should matter.
If you take a typical to do / task list for example, and you want to mark an item as completed and have it struck through and greyed out. Individual column formatting (perhaps a red amber green for a priority or importance column) will still show - when really that colour should be greyed out. As it stands, no matter whether you place that rule above or below, you canāt stop this from happening - and personally I feel that should be in the users control.
Working around this is possible, but finicky. Whereas if you implement it where the user decides the rules priority based on its position in the list - then the user can choose the behaviour - which is better surely?
100%ā¦ this needs to change!
Could you add your vote?