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!

By using a single interface for a wizard, you throw away what is (in my opinion) one of Appian's best features - the process history. It is far, far easier to debug even a relatively simple wizard when you can see, step-by-step, the actions a user has taken. Clearly this should be caveated; as very large amounts of data in lots of processes such as this could cause memory issues.

Hi,
I Support Robert Shankin about this, in this scenario I will go for Wizards, as to reduce the complexity in wizard we will create multiple interfaces like "general Info" in one interface and "detailed info" in other, call them in parent interface (which wizard exists).

The advantage of the wizard is it gives you greater flexibility to redesign the interfaces without having to manipulate the process models and you have fewer process model paths to create, manage, and test (Save, Save & Exit, Back, Next, etc) so your process models become simpler. However, as stated earlier, you do lose the process history so you need to decide how important is the process history vs the flexibility to redesign interfaces.

Hi Larry Nguyen,

I presume that, In your scenario I would suggest you to go for a wizard because wizards should be used to break up a large form into smaller steps rather than activity-chaining.It is not recommended to design a wizard which require users to frequently reference previous steps to complete the current step. Whereas Activity-chained tasks are useful when something needs to happen between kicking off the process and the user seeing the form.