Skip to content

Boolean validators

Boolean parameters in Revit are tri-state: Yes, No, and Unset. That matters. A lot.

Boolean — Is

Used for

A Boolean validator checks only for:

true or false

Nothing else.

How it works

  • Reads the boolean value from the filter output
  • Compares it to the expected boolean state

What this means in practice

When you use a Boolean validator, you are asserting:

  • The parameter exists
  • The parameter is of boolean type
  • The value resolves to true or false

That’s it.

What a Boolean validator does not interpret

A Boolean validator does not understand:

  • "Yes" / "No" as text
  • 1 / 0 as numbers
  • Empty values
  • Missing parameters

Those are separate decisions and must be handled explicitly with:

  • Property validators (exist / not exist)
  • Null validators (should be null / not null)

Important Revit-specific reality (state this clearly)

In Revit, a Boolean parameter can be:

  • True
  • False
  • Unset

But for the Boolean validator:

  • Only true and false are valid inputs
  • Unset is not true and not false → it must be handled before or around the Boolean check

This ties directly back to your checklist:

  1. Does the parameter exist?
  2. Is it set?
  3. Only then: is it true or false?

Boolean — Is not

Is not Used for

Ensuring a boolean parameter is not set to a specific value.

Is not How it works

  • Reads the boolean value
  • Fails if it equals the forbidden value

What it will find

  • The opposite boolean value
  • Unset values (depending on context)

What it will not find

  • Missing parameters
  • Implicit false assumptions

⚠️ Revit Boolean pitfall — Unset is not False

In Revit, a Boolean parameter added ad Project Parameter has three possible states:

  • True
  • False
  • Unset

This is not theoretical — it happens in real models.

Why this matters for validation

A Boolean validator only evaluates:

  • true
  • false

If a Boolean parameter is Unset:

  • It is not true
  • It is not false
  • It does not automatically fail
  • It does not automatically pass

From the validator’s perspective, the value is simply not usable.

In Revit, for a Yes/No parameter:

  • ✅ Checked = True
  • ✅ Unchecked = False
  • ✅ Greyed out (often shown as indeterminate) = Unset / no value

⚠️ Revit Boolean pitfall — Greyed out (Unset) is not False

In Revit, a Yes/No (Boolean) parameter can be in three UI states:

  • Checked → True
  • Unchecked → False
  • Greyed out → Unset (no value)

Why this matters for validation

A Boolean validator evaluates only:

  • true
  • false

But Revit can also deliver an unset state, which DAQS exposes via the parameter wrapper (for shared parameters this is typically visible as hasValue = false).

So two elements can both look “not checked” at a glance in reporting, while their data meaning differs:

  • False → explicitly set
  • Unset → never set / no value

Common mistake

“If it isn’t checked, it’s fine.”

Wrong if the parameter is mandatory.

If a parameter is required, greyed out must fail, even though it is not “true”.

Correct validation pattern

If a Boolean parameter is mandatory, validate both:

  1. The parameter exists (or the property exists in your filter output)
  2. The parameter has a value (hasValue = true)
  3. Then validate the boolean value (true or false) as required

This is why DAQS often uses hasValue for shared parameters.

Rule of thumb

✅ Decide explicitly what Unset (greyed out) means for this rule. ❌ Never treat Unset as False.