Wizard Form vs Chained User Input Tasks for a user form flow

I've found for very large wizards, we were often better off splitting the workflow into several chained nodes. A very large wizard can be very complex to debug, with local variables getting passed up and down a large number of rules.

Right. I'm leaning towards chained user input task because it seems easier to debug and see the flow visually since each part of the flow will be another node. I would even say I'd prefer that for even simple flows as well.

I agree with both of your that there are pros and cons to either approach.

Debugging the chained processes might seem easier to those who feel more adept in Process Modeler than Interface designer.

Keep in mind, too, though, that by introducing process at every step, you essentially need to manage the interaction between process and interface at every step.  This kind of setup, when implemented with sensible navigation can work out very well.  However, if the designer fails to consistently manage navigation considerations across different task forms, it can be a user nightmare.  

Consider in advance how you plan to make use of buttons like "Cancel", "Back", "Next", "Save", "Save and Continue", etc.
Does clicking "Back" save what I entered?
That's just the tip of the iceberg.

An interface that provides a wizard-like or progressive disclosure style user experience may contain many components, but it is possible to achieve this design in many cases without moving in and out of process.  

Consider the memory footprint of this process as well?
How long-lived is the process?  How big is it going to get depending on which approach you choose?  Which approach more efficiently interacts with the database?

Whatever you choose, I think this discussion merits a mention the Playbook Play for Creating Flexible Processes.  Definitely worth the read!

I agree with both of your that there are pros and cons to either approach.

Debugging the chained processes might seem easier to those who feel more adept in Process Modeler than Interface designer.

Keep in mind, too, though, that by introducing process at every step, you essentially need to manage the interaction between process and interface at every step.  This kind of setup, when implemented with sensible navigation can work out very well.  However, if the designer fails to consistently manage navigation considerations across different task forms, it can be a user nightmare.  

Consider in advance how you plan to make use of buttons like "Cancel", "Back", "Next", "Save", "Save and Continue", etc.
Does clicking "Back" save what I entered?
That's just the tip of the iceberg.

An interface that provides a wizard-like or progressive disclosure style user experience may contain many components, but it is possible to achieve this design in many cases without moving in and out of process.  

Consider the memory footprint of this process as well?
How long-lived is the process?  How big is it going to get depending on which approach you choose?  Which approach more efficiently interacts with the database?

Whatever you choose, I think this discussion merits a mention the Playbook Play for Creating Flexible Processes.  Definitely worth the read!