Subworkflow Input

Subworkflow Input (class SWF_SubworkflowInput) is the boundary marker that says "external values enter the workflow here." It's not a processing node - it's the front door. Drop it inside a workflow, and when that workflow is used as an inner workflow by a Subworkflow node, this becomes one of the outer node's input slots. Run the same workflow standalone and it behaves as a transparent passthrough.

The clever bit is how flexible it is. The type isn't declared - it's inferred from whatever connects to the node's output. Plug a model into it and the slot on the outer Subworkflow node accepts models; plug a conditioning in and it accepts conditioning. That inference is the whole reason the outer node can grow correct-looking slots without you reconfiguring anything.

The two things you set

• slot_name - the label shown on the outer Subworkflow node. Defaults to input; set it to something meaningful (prompt, model, seed) or you'll be decoding input/input_1 forever.
• value - the optional input. This is where the flexibility lives. When the workflow runs standalone, this must be linked, or the node throws: "Subworkflow Input must have its value input linked when executed directly." When the workflow is used as an inner workflow, the outer slot's value replaces it - and if the outer slot is left unlinked, the inner linked node is used as a fallback. That fallback is what makes optional inputs work: give it a default in the inner workflow, and only override it from outside when you want to.

Output: a single value output that passes the boundary value onward.

One nice 2026 addition

Since v1.2.0, if the input ends up being a primitive number type (INT or FLOAT), you can set the value directly as a widget on the outer Subworkflow node - no separate node and wire needed. A linked node still takes precedence over the widget, and you can disable the value input entirely so the inner workflow's own fallback is used. It's the difference between a tidy compact workflow and a rat's nest of Primitive nodes feeding a reusable block.

Where it trips people up

The standalone-linking error is the #1 stumble: you save a workflow that uses Subworkflow Input, test it on its own with the value unlinked, and it errors. Link a value when running it directly - that's expected behavior, not a bug. Inside a Subworkflow node the requirement disappears, which catches people the other way when they assume the inner workflow "should" validate the same.

Install is the same as the rest of the pack: ComfyUI Manager (search "Subworkflow (reuseable workflows)") or clone https://github.com/eniewold/ComfyUI-Subworkflow.git into ComfyUI/custom_nodes, restart, hard-refresh. No extra dependencies, just a ComfyUI recent enough for the V3 node API (0.18.x). One known limitation worth knowing: a Subworkflow Input placed inside a subgraph won't be detected as a boundary and won't appear on the outer node.