Activity Chaining Two Tasks with Multi Node Instance (one instance for each assignee) with two different interfaces

Question

We have a process where we have two tasks which are activity chained. 
 The first task has an interface and is assigned to a group with one task for each user - using multi note instances. 
 The task is configured to move forward when the first instance completes. There is an exception flow to complete remaining tasks. 
 This task is activity changed to another task, which has a different interface. The second task is also configured exactly same. Its assigned to a group and has one to one task assignment for users using multi node instances. 
 The issue we are facing is that when the first task completes, instead of going to the second task, the UI goes back to the list of tasks in tampo. 
 When we embed this task, the behavior is even strange. It shows a "Form Data Submitted" message and then just stays on that task interface instead of going to the next one. 
 This does not happen if we change the second task to a single task assigned to a user or group without multi node instance. (but we need Multi node instance because we dont want users to accept tasks) 
 
 So can someone help us with some information on how to activity chain two multi node instance tasks with different ui and one instance per assignee with move on first instance complete. 
 
 Thanks

davidl692 · Answer

It's unfortunate that your idea doesn't work, but I can sort of understand why it doesn't work. What you want to do is configure the next task to be assigned to the person who completed the previous task. Right now, there's no way to configure an Appian node to do that, and even if you did, it would get confused and probably assign all instances of that task to the same person. 
 You're going to need to use MNI on a sub-process. See if you can configure the subprocess node to create an entirely separate process for each user in your group. Now each user will have their own process that the others can't interfere with, and in each individual process the two activity chained Input Tasks each have only one assignee set by PV, and chaining will work properly. 
 The OTHER thing you could do is make it only one form. Trade out the first form's Submit button for an ordinary button that sets a local "form flag" to say you want to look at the second form. You'll have to include a showWhen parameter to all the components. First you show all the components of the first form and hide all the components of the second form, then when you press the button, it hides all the components of the first form and shows all the components of the second form. Now, you only LOOK like you're chaining to a new form. Everyone gets their own instance of the transforming form, and everyone thinks they activity chain to the next form even though they really don't, and the MNI just works. If you don't do any script tasks or writes to database or anything like that in between, there's no real reason not to do it this way (other than a pretty complex code-base in this one form to maintain).

Mike Schmitt · Answer

I think if your first task is MNI, you should change your second task to *not* be MNI. The user who completes the instance of the first task will chain into their very own instance of the second task, and since it's chained, it'll be auto-accepted. A user who completes a subsequent instance of the original task will then chain into their own new instance of the second task, and so-on. 
 Honestly this is a good example for why MNI on tasks (other than the simplest-possible implementations) is best avoided at all costs. I'm not sure I understand why you're putting yourself through such extra pain just to avoid having users accept tasks, either - that feature exists for a reason.