How to auto-close and submit a form (without an User action)

Generally speaking this is not possible with OOB appian functionality.  What is your use case?

Thank you Mike, I am testing a scenario... where a process contains a lot of nodes (let's say 50 nodes for a full saving process).
I would like to break the process in 2 sub process, with a form displaying a message ("saving in progress...").

But I would like this to be completely automatic.

I'm still not sure what you're hoping the user-facing experience will be.  Are they going to be seeing a task while the "saving" processes run?  Do you intend for them to go from that task directly to the next chained task, or to navigate away and do something else?

Sorry Mike if my explanations are not clear enough...
Here is the full process I would imagine:

- The user start the process model (70 nodes) of updating data (many DB tables to update).

- A start form (A) is displayed with a lot of field to fill

- The User enters values in all the fields, and click on submit to validate the form (A)

- The saving data is started

- because of the very important size of nodes (causing an error when size > 50 nodes), we call another Form (B) in the middle of the saving data process model, and this form just displays a simple message "Data saving in progress...". The goal of the form (B) is just to cut the process model.

- The new form (B) is displayed... and then, 10 seconds after, it is auto-submitted without any User action, and then is auto-closed.

- The process model can continue, until the end, without error because it has been cutted into 2 sub processes (35 nodes each).

There may be a simple solution then, since there is no further User task in the sequence.

On the task in question, you can say "saving in progress... you can now navigate to a different tab" etc.  Do not give a submit button or any other way for the user to submit.  The user will leave the form by clicking to a different tab/etc.  You can then safely auto-complete the task via timer after any interval (you can do 1 minute or any other length), without affecting the user's experience.

This is the way I've handled similar cases in the past and it works decently.

I'm not sure to understand.

in your solution, as you are not decreasing the number of successives nodes executed... the error would persist.

In our system configuration, exceeding 50 nodes causes any process to be aborted.

A 50-node process doesn't automatically abort; that's just the limit of nodes between two chained user interaction tasks.  If you're experiencing something different, then you might have a more severe error in your environment, because this is NOT a limitation of Appian that I've ever seen.

In my example above, the process would continue running in the background and complete anything it needs to complete, both before and after the user-facing "saving in progress..." task expires.

Thank you Mike... very intertesting... I thought the process was automatically aborted.

But in our case, we should have others errors because when the User submits the form.... nothing happends... (and no error are throwed in the Process).
The screen should return back to the readonly form (the previous form), but it does not.
And when we fix the nodes to 50 max, the update form is well closed.

In you example below, you're saying that the process continues running in the background.
It is maybe dangerous, there is nothing telling the user the data has been well and fully updated ?

He could modify the same contract and working with data still in update that may cause some conflicts, I presume...

These are all considerations, and all things that you should be able to design your process around, IMHO. 

There are various techniques to accomplish this, the easiest and most obvious being, shift some of the user input "work" into a subsequent process task (i.e. not the start form) where the process will be able to run in the background and do some of the processing that doesn't rely on their input from that task, and then when they're done with that task, the background process can continue on in such a way that it utilizes what they've entered.

Yes, I understand Mike... thank you for your advice.

I agree with Mike - in general activity chaining isn't necessary unless all the activites must be complete before the user returns to their previous page. If you just add a message near the submit button something like "It may take a few minutes for all data from this form to update" or something similar, that would probably do the trick without a more complex process.

The other thing I'm wondering - do you really need 70 nodes to update data in a database? If you use the Write to Multiple Data Store Entities node, you can combine a bunch of writes to the database in a single transaction, which might reduce the number of nodes required in your process.

Thank you Peter.
Yes, some of our processes has a lot of data to save and our form are functionaly very complex. Some of our other processes can be organized with kind of wizard, and could be cutted into multiple Input Tasks and subprocesses, but other ones can not (or would need to be completely re-designed).

Yes, for the multiple Data store entities, we already have such a advices, since few weeks, we already have started the works to optimize some of our processes.

(what a pleasure to have a reply directly from one of the Appian Instructor of training courses I've took ! ;-) )

Thank you Peter.
Yes, some of our processes has a lot of data to save and our form are functionaly very complex. Some of our other processes can be organized with kind of wizard, and could be cutted into multiple Input Tasks and subprocesses, but other ones can not (or would need to be completely re-designed).

Yes, for the multiple Data store entities, we already have such a advices, since few weeks, we already have started the works to optimize some of our processes.

(what a pleasure to have a reply directly from one of the Appian Instructor of training courses I've took ! ;-) )