Boolean List Hierarchy

Plain Boolean List gives you a pile of independent switches. Boolean List Hierarchy gives you switches that depend on each other - up to 64 booleans arranged in a three-level tree (Root → child → grandchild), where a parent can cascade its state down to its children, siblings can exclude each other, and branches can require something from another branch before they're allowed on. If your workflow's logic looks like "if the upscale pass is on, then the detailer under it can also be on, but only if the LoRA group isn't", this is the node that makes that readable instead of a diagram of your own confusion.

The practical framing: this is for when a flat list of toggles stops matching the structure of your workflow. A flat list can't express "this switch only makes sense when that one is on." The hierarchy can - and it can enforce it at the front-end level, so the UI dims or forces a child's state based on its ancestors, keeps one member of an exclusive group selected at a time, and holds cross-branch AND dependencies so a downstream branch only activates when every prerequisite is true.

How it works

The backend reads the whole tree from a config_json input (a socketless, hidden field that the front-end editor writes to the workflow), applies the hierarchy constraints, and emits one BOOLEAN per item on the fixed 64 outputs. The front-end (web/boolean_list_hierarchy.js and its model) owns the editing: it gives each entry a stable ID so your wires survive reordering - you can sort the tree, indent a child, promote it up a level, or delete a whole subtree recursively without the connected outputs going to the wrong socket. That stable-ID wire persistence is the difference between "rearrange my switches" and "re-wire my entire graph."

The inputs and outputs that matter

• config_json - internal tree state. Socketless and hidden; you'll normally never touch it directly, though you can inspect it to see what the editor saved. Defaults to a single Boolean 1 root item.
• The 64 BOOLEAN outputs - wired to whatever consumes the switches, exactly like the flat Boolean List.

Reach for this over plain Boolean List when two things are true: you have more than a handful of switches, and those switches have parent/child or mutual-exclusion relationships you're currently papering over with manual discipline.

How to install it

Part of the DAELab pack. ComfyUI Manager, search "ComfyUI-DAELab-Custom-Nodes-Library", or:

cd ComfyUI/custom_nodes
git clone https://github.com/TeutonicMepheles/ComfyUI-DAELab-Custom-Nodes-Library

then restart. No models, no extra deps. It's a V3 node, so keep ComfyUI Core reasonably current (No module named 'comfy_api' in the log means update ComfyUI, not pip). And since the editing UI is front-end code, install the whole repo - the web/ directory is what makes the tree editor exist.

Common issues & troubleshooting

"I reordered my tree and the wires flipped." The stable-ID system is supposed to prevent exactly this, but it depends on the IDs being saved into the workflow. If you built the tree, then loaded the workflow in something that stripped node properties, the IDs regenerate and wires can land on different sockets. Save after editing.

"A child switch is stuck." That's the cascade working as intended: a parent's off-state forces its descendants off, and an exclusive group locks out its other members. Check the ancestor's state and the group's exclusivity before assuming it's a bug.

"I don't see the tree editor." This node's editor is front-end. If you cloned only the nodes/ directory instead of the whole repo, you'd get a backend node with no panel - install the full pack.