Conditional formatting

Rules are an ordered list, evaluated top to bottom. Each rule is condition → format, scoped to the whole row or to named columns.

Rules are data, not code — the same status templates, palettes and column sets have. A rule list is a document you can save, share and apply, not a preference buried in the application.

What a rule can set#

Every property is optional. A rule sets only what it cares about, and that is what makes the conflict rule below meaningful.

⚠ Bar properties always apply to the row, even on a rule scoped to named columns. A bar has no column to be scoped to.

The conflict rule is per property, not per rule#

⚠⚠ First matching rule wins per format property — not per rule. A rule that only sets bar dash does not block a later rule that only sets fill.

The obvious reading — first matching rule wins outright — would mean a narrow rule near the top ("dash the delayed ones") silently cancels every later rule for those rows, including ones setting entirely unrelated properties. The user sees a rule that plainly matches and plainly does nothing, and there is no way to reason about why.

Per-property resolution makes the list behave like cascading styles ordered by position, which is what anyone dragging rules up and down actually expects.

Rules read derived values#

A rule's condition reads whatever the grid can read, including values that live nowhere in a cell. The worked example the design leads with is Total Float < 5 AND Critical = false — the near-critical work that nothing else flags — and total float is derived. It is in the schedule result, never in a cell, and a rule engine that only saw cells could not express it.

Why is this row amber?#

Every resolved property records which rule supplied it. That is what turns a coloured schedule back into an explainable one: the question "why is this bar amber" has a straight answer rather than a search through the rule list for a match that may not exist.

The panel also reports shadowed properties — a rule that sets something an earlier rule already decided — so a rule that will never have an effect is visible before you spend an afternoon wondering why it does nothing.

Manual overrides#

A single bar may be hand-styled, and the override beats every rule, per property. Overriding a bar's colour does not silently discard the dash a rule gave it.

⚠ An override is flagged as an override. That flag is not decoration — it is the condition on which the feature is allowed to exist at all. On a schedule where every other colour means something, an untraceable hand-painted bar is styling nobody can reason about. The override is what the provenance records instead of a rule id, so "why is this bar amber?" still answers.

House standards#

A rule list can be saved to the workspace as a named standard and applied to another sheet.

⚠ Applying a standard adds its rules to the existing list rather than replacing it. A sheet that silently lost its own formatting on import would be the worst possible outcome of a helpful act.

⚠ A standard lives at the workspace level, not in the file. A sheet's own rules are sheet data and travel with the schedule file; a company's house style is not tied to one schedule.

Related#

• Views & filters — rules use the same condition model.
• Baselines & variance — the variance columns rules are usually written against.