Hello @HaydenWright and welcome to the forum…try take a look into archilab there some nodes for schedules, not sure if you can format cells that way, but try take a look
Unfortunately I have already been down that path. From what I can see, the archilab nodes relate to conditional formatting in excel schedules, not Revit schedules.
Row was my hang up. I do not believe this feature will do rows - only fields in a column, or at least not that I have seen. I also do not believe that conditional formatting API is exposed. Assuming both are true this is a wishlist item for first Revit and then Revit API.
(Warning: Probably not a good idea but maybe worth trying just for fun…)
You could try mapping schedule values to sheet schedule locations and place color-coded “fill regions” to replicate the conditional formatting feature. Unfortunately, sheets don’t allow fill regions, so you’d have to translate this to a view first which will make things even messier. Or you could draw detail lines directly on the sheet as a hatch pattern. Neither one of these is a particularly “good” solution and would be heavily reliant on your schedule formatting and change management but they are technically options.
Before it can be added to the API it needs to be added to the application; often (usually) the API will follow, but it is two separate asks.
To get the first you need to post to the Revit Ideas forum.
Some things to keep in mind when making a feature request for any tool:
Make a business case for why a majority of users would benefit from this change, or why new users would adopt the platform by adding the feature. Remove your singular context from the language and speak on behalf of EVERYONE who might ever use the tool.
Put value metrics ($, hours, etc.) into the post if you can, as accurate metrics are indisputable and help justify effort ($) to build the feature as it suddenly is easier to sell.
The level of difficulty to produce and maintain a feature, staff availability, and other proposals will be taken into account when trying to decide what features to build; a full overhaul is more expensive than a slight tweak and therefore less likely to be undertaken.
Think about the impact on other users in other industries before you submit. If the feature will break another aspect of the tool it is less likely to progress than a feature that has no impact or positive impact to other users.
The level of effort to build a feature is multiple orders of magnitude more than what you likely think it is, and some things will take years worth of releases to be successfully released.
Disruptive ideas are viewed differently as they open the doors for more business.
Decision makers often only know what you tell them - be clear and communicate with common language and illustrations when possible.
So with that in mind, here is a generic review of posts to consider. Bad: Our firm always did it this way in the old tool. Ok: Teams would be able to add emphasis to convey intent. Good: Firms would be able to spot QA issues instantly which will reduce rework while saving an estimated 4 hours of review time and providing better outcomes downstream by more clearly indicating design intent.