InvokeAI Node Pack: Workflow Chaining

[shrewd pendant]

This node pack introduces workflow chaining. That is, using nodes in a workflow to populate fields in the linear UI form of another workflow, then executing it. This lets you build focused, reusable "black box" workflows that enable:

• Modular Workflow Design: Break down huge graphs into smaller, self-contained units.
• Improved UI Responsiveness: Avoid UI slowdowns (and mental fatigue!) by keeping the number of nodes smaller within a given workflow.
• Direct Reproducibility: Generation parameters from an output image of a child workflow are baked into its linear UI form, allowing you to reproduce or remix specific results with a single click.
• Sequential Callback Chains: Child workflows can enqueue further workflows for multi-stage processing or conditional branching.

This pack provides the Enqueue Workflow Batch and Enqueue Image Workflow Batch nodes, alongside Field List Builder nodes for each UI type. The two Enqueue Batch versions load workflows from saved .json files ("Save as File" from InvokeAI's workflow editor) or directly from those embedded in images, respectively.

To obtain the node pack and get a detailed breakdown, installation instructions, and examples, visit the repository on GitHub!
Link: https://github.com/dwringer/workflow-processor-node/

[Example of sending a single prompt through three different workflows, contained in three different images from the gallery, from a single parent workflow.]

[oak hound]

wild

[summer pagoda]

Cant wait to try this

[brave stream]

I tried it unless i did something wrong the for nodes don't or won't let me produce anything I get the workflow error as nothing is there

the four nodes

[shrewd pendant]

I'd need to see the actual error message to help debug, if you could pull it from the console. A screenshot with the error showing in the Invoke UI could also help and will in most cases indicate the problem

Possible there's some issues with one of the examples but the error message should help specify what's wrong

I tested all the examples on 6.2 locally and they work here so idk

(if anyone else runs into any issues, please let me know!)

[shrewd pendant]

If you're trying the example of image-embedded workflows, the workflows in those images have to be designed already with the correct forms. I recommend going through the provided example workflow files in order to see how that works. Basically, a target workflow has to have a form-builder UI panel filled in on the left, containing any fields you wish to be able to modify. In my examples I also renamed the fields from their defaults to things like "Prompt", "Width", "Height", "Seed", but this isn't strictly necessary; you can also just keep the default names and send them in the same order they appear in the form.

[brave stream]

I use 6.3.0 right now, but have to wait till I’m home to redo the error. Might be easier to show a full set example with those new nodes, I’m still new at node work.

[shrewd pendant]

There are some example workflows in the workflow_payloads folder that you can load up in invoke and check them out. For Flux the two to look at would be parent_example_flux_workflow.json and example_flux_payload_1.json. There are also versions for SD1.5 and SDXL in there. The parent_example shows how to use the Field Builder Nodes and send them to a target workflow. The payload workflow is what it actually uses for a target and has all the generation params set up.

This image shows a workflow that's set up to send model fields, prompt, and seed to a target workflow (specified in the rightmost node as example_flux_payload_1.json)

And this second image shows that example_flux_payload_1.json workflow itself, set up to receive those values. Note how all the fields that are intended to be filled in appear in the panel on the left. You can drag them there. They have been renamed in some cases, like "width", "height" and "steps", so those names can be used from the other workflow to send values specifically to those fields. (Otherwise you'd just have to call them all 'value' and make sure the order of them matched exactly)

You may also note there are more fields there than what actually get sent to it by the other workflow. You typically don't have to fill them in unless they were left blank in the target workflow, which I don't recommend anyway because it may cause issues (I was forced to leave model blank for example compatibility purposes).

[brave stream]

I’ve played with workflows but since you made more nodes I can experiment more. Still new to it.

[shrewd pendant]

experimenting is the great thing about nodes hehe

[green snow]

Is there a way to grab an image result of an enqueue workflow batch so I can pass it along to another?

[shrewd pendant]

There's a Field List Builder - Image that you can put in the child workflow.. you'd have to call the third workflow from the second workflow basically. I made this image the other day as I was thinking through that process. However I haven't ever done it where I pass an image from a second workflow to a third one; only from a first workflow to a second one.

It should be possible to do in this way though

[green snow]

I was hoping to find a way to use existing workflows. For example one for t2i generating and another for face detailing, without having to maintain multiple versions of them that are 99% similar.

[shrewd pendant]

Yeah, you can send the image from the first one to the second one for sure

As long as you have the form ui of the second workflow set up with an image field in it

you can send an image to that field from the first workflow

[green snow]

The bit I'm tripping on is grabbing the result from the first enqueue

[shrewd pendant]

Ah well, yeah, if you're enqueuing the t2i workflow and then trying to pass its result to the face detailer, the t2i workflow would indeed have to be edited to include an Enqueue Workflow Batch node itself, and send the image field to the third workflow. And any other fields you wanted to send on

[green snow]

Yeah. Right now I have an SDXL t2i generation workflow and a face detailer workflow and I can make one workflow that does both but if I then decide that I always want something in my t2i gens, I have to edit both workflows. I was hoping this would be a nice way around that but I guess not. Ah well.

Still pretty neat.

[shrewd pendant]

You can provide the workflow name (of the third workflow) as an input to the second workflow

And if it's not provided, the second one will just terminate

So from the first one you can decide whether or not the second one calls the third one by whether or not you include that filename

But it would really be nice if we could have a workflow pause itself and yield the queue to another one, and then resume execution when it finished...

[green snow]

Ah I get it. The workflow is queued and runs after the parent workflow. So that wouldn't be possible. Should have figured that out by the fact that it says "enqueue" lol

I think I'm following you said above so I'll see if I can get something like that working.

[shrewd pendant]

I also should try to implement it since I never got around to actually trying it so I will try to come up with an example at some point

[green snow]

I got it. Works great but the workflow has to be loaded from JSON so you can not include it. If you try it with enqueue from image, the interface doesn't like the image value not being populated.

Would be really nice to be able to load the workflows from the workflow library as well as from JSON and images.

Can use my String Toggle node to just have an on/off for the child workflow. 🙌

[shrewd pendant]

I have been meaning to take a look at that. Unfortunately a preset list of them would have to be loaded only at invoke startup I think. Not sure how to handle ones that are added after it's running

I did an undocumented addition where it searches the system default user downloads folder for the json if it isn't found in the node's own folder though to hopefully minimize pain when people are running it on the same machine

[green snow]

Feels like something that should be available through context, like the model manager is. Although I guess this would be the only use for it.

[green snow]

For some reason, a node set to Save to Gallery in the child workflow doesn't get saved to the current Auto board but is just getting dropped into Uncategorized instead.

[shrewd pendant]

Ah yeah, that is a known issue called out on the github... basically auto board only works if you include board as a field in the child workflow's linear ui, and send the board field (auto) from the parent workflow to it

as when auto board is selected and a batch is enqueued normally from the ui, the board id gets filled in then and there

It should work though if you include the board on the linear ui of the target workflow and send that field through

[green snow]

Ah, good. As long as it's known. It's not a big deal as long as you know it's happening. Was pretty confused for a while.

[shrewd pendant]

i spent quite a long time trying to figure out a way to understand and get the board behavior working and this is unfortunately the best i could come up with for that haha

As it seems to be the auto board is part of the ui state only and can't really be determined from backend code afaik

maybe now it can though as I know there was some work done recently on state preservation... will look into it later for sure