Trigger Word

Let's be honest about what this node is: you type a word in, the same word comes out. It does not load the LoRA, does not check the trigger is real, does not do anything to the value at all.

So why does it exist? Because in a workflow with forty nodes, a labelled box matters.

What it does

One input, one output, no processing:

• word (STRING) - the trigger token, e.g. ch9ractername.
• trigger (STRING) - the identical string.

That's the whole node. The pack's own description calls it a "pass-through STRING labeled as a LoRA trigger word for workflow readability," and that's an accurate self-assessment rather than a sales pitch.

The actual argument for it

Two real ones.

It converts a widget into a socket. You could type the trigger into the prompt template's text box directly. But then it's baked into one node, and every other node that wants the same token - a filename builder, a status summary, a second prompt template - needs its own copy. Change the trigger and you now have three places to edit, and the first time you forget one you get a filename that doesn't match what you actually generated. The plumbing principle in this ecosystem is blunt and correct: one authoritative source, many consumers. This node is that source for the one string most workflows hardcode in four places.

It documents itself. When someone opens your workflow and sees a node labeled "Trigger Word," they don't have to reverse-engineer whether that ohwx in the prompt box is load-bearing. Rename the node title and it's self-explanatory at a glance.

Where it plugs in

The socket is a plain STRING, so it goes anywhere text goes. In this pack it pairs directly with Prompt Template, which replaces its {TRIGGER} placeholder with whatever this node emits. Chain them:

Trigger Word (ch9ractername) → Prompt Template → CLIP Text Encode
                            ↘ Filename Builder
                            ↘ Workflow Status

One edit, and the prompt, the filename and the run summary all agree.

About picking the token

Worth repeating because it's still the most common LoRA mistake: the trigger should be a rare alphanumeric string that isn't a real word. ch9ractername, styl3name, ohwx - the established convention. Something like "portrait" or "cinematic" collides with tokens the base model already knows and you end up fighting your own LoRA over a word that means twelve other things.

And a hard limit the node can't warn you about: LoRAs are architecture-locked. A Flux.2 Klein LoRA will not run on SDXL, and vice versa. No amount of correct trigger wording saves you from loading the wrong file into the wrong base model.

Install

Manager → search Orel's Nodes → Install → restart → hard-refresh the browser.

cd ComfyUI/custom_nodes
git clone https://github.com/DarkOrel/Orels-Nodes.git orels-nodes
python -m pip install -r orels-nodes/requirements.txt

Restart, hard-refresh. This node needs nothing from that requirements file - it's stdlib Python, and it loads even on a bare install with none of the pack's optional dependencies present.

Gotchas

No trimming, no validation. If you paste a trigger with a trailing space, you get a trailing space, and it travels into your prompt and your filename unchanged. Look closely at a filename that looks right but doesn't behave.

Empty is a valid value. word defaults to empty, so an unconfigured node passes an empty string downstream rather than failing. In Prompt Template that means {TRIGGER} gets replaced with nothing and your prompt silently starts with a bare comma.

It's not linked to the LoRA loader. There's no data path from LoRA Loader + Name back to this node. If you select a different LoRA, the trigger doesn't update itself. That's a workflow you build by hand - and honestly, an easy thing to get wrong at 2am.