It would be great if at some point there was a common conditional formatting feature that could be applied throughout the platform on different UI elements including fields, tables, cards, boards, etc. I am not sure if having a uniform formatting feature for the UI components is feasible but I think that would be quite interesting.
@cannibalflea Can you give some examples?
Hey @mdubakov, would love to see this too. Sorry to invoke Coda, but they give you the option whether a certain status of an entity will give it a strikethrough or not - I really would like to be able to choose this myself. Jira forces the strikethrough once an item resolves, and other apps donāt have any strikethrough where Iād thought it would be useful.
Hope that helps, and I vote for this feature!
I think some option like this would be great for visual clearance. if for example a task is linked somewhere but is marked as done it would be nice to have it striked through or some other visual representation that it is done. (faded grey or other options) also for subtasks linked to other tasks.
or maybe i am missing that this is already possible?
When you mention an entity, you can choose which fields should be displayed for entities of this type, so you could choose to always show the status field for tasks.
Hover over the database icon, click the three dots and choose which fields to show.
thanks @Chr1sG i do this - but its not āobviousā on first sight BUT , in one of your videos (Meeting Notes - YouTube @ 0:18) there is a task that is done and marked with a strike through ā¦ how would i do this?? is this some kind of automation or something? i simply cant find it
thanks, cheers, arne
This was functionality that was removed last year, sorry!
why? this is standard in so many (todo) apps and would make it visually extremely easy to grasp what needs to be done in documents (without the need to put progress and other details in the file as well - and without clicking on itā¦ (in a big document with lots of tasks spread out across the document for example)
or give the ability to make conditional formatting available in documents too. or best even throughout as a general setting that can be overwritten in separate lists if needed
Bring it back! I love strikethroughs! 
On the topic of conditional formatting just adding something I would find useful and use: Once a formula is executed and the numeric result is added to an empty field I would like to see that field color coded.
I would love to be able to color a row when comparing two numbers in fields that are not the same. For example, if the ātotal invoiceā is not equal to the āamount received in the bankā, then display it in red.
Hi all. Are there plans to implement āattributeā or āfieldā level conditional formatting at any point? Iāve migrated from Coda - and really missing this feature. I use it for so many use cases!
Can you give an example of what you want to see. Do you want individual field values to be formatted differently based on their value, or do you want an entity in a data view (list, table, board) to appear differently based on one (or more) of its field values?
Hi Chris, no worries sorry if my previous post was unclear. The following screenshot should clear it up.
This contains multiple examples:
- Column 2 is being highlighted based on the value of column 1.
- Column 3 is being highlighted if the value is null
- Column 4 - a bit more advanced, is applying a dynamic colour scale for a number type field. Users can choose the type of colour gradient and apply min, mid, and max values for it to apply.
Crucially, in all examples users have complete granular control over:
- the rule (which can also be a user written formula)
- how that rule is applied - either to all columns (the entire row / entity) or just to one or more columns as required.
Hopefully that makes sense.
Thanks for the elaboration.
Do you see these conditional formatting options as being definable per view, or are they attached to the database, implying that they manifest everywhere the entities show up?
I assume the formerā¦
Are the conditions always based on values for fields on the same entity, or could it be needed for them to depend on field values from related entities?
Good questions. Iāve seen it implemented in different ways in different platforms.
The best (in my view) is again when the user has the choice and saves re-work. Sorry to keep referencing Coda (I promise there are things I donāt like about it too!) but I think they have nailed this feature well. In their case you have the option to āinherit from the databaseā. You can toggle this on or off and then build more rules just for that view over the top if you want.
Here is a screenshot of the configuration window of a separate view to the table I already posted above - you can see Iāve chosen to inherit my previous 3 rules above and then add my own specific conditional formatting custom formula for this specific view, flagging all rows where the value in a specific column is less than 4.
Regarding your other question updating from related entities - definitely useful, but probably a ācould have / should haveā rather than a āmust haveā.