User Interface Cancel Button Configuration

Any buttonWidget with the 'submit' parameter set to true will exit the interface and continue the process flow

hi aaronp0001, what I am looking for here is that it closes the interface without progressing the process model (ie the task remains open), so almost like a "close interface" button

Any user input task in a process model allows you to select a checkbox on the forms tab labelled "Allow users to save a draft of in-progress tasks" which sounds like it should do what you're asking, allowing the user to close the task and resume it at any point from their tasks in tempo.

However, with numerous user input tasks in your process it sounds like this could lead to very long lived processes if escalations/exceptions aren't configured correctly, so bear this in mind.

I'm not sure why you say the process instance can't be progressed any - with any submit button click the process instance would need to progress at least a little bit.

So, if you specifically need an "exit" button (i would suggest not calling it "cancel" because that carries other meanings for most users), you would simply have a gateway after the User Input Task in your process model which loops back to the same task but without chaining.

Cancel usually denotes ending the process without doing anything further, or possibly rolling back changes that were made.  You can always configure tasks to be assigned to a group, and the person who accepts the task will have the option of returning it to all assignees.

If I understood your requirement correctly, we can achieve this by providing cancel button which will be passing flag (Exit) to process model using rule input. When user choose cancel you can have XOR gate to check the user action from flag(Exit) and redirect to the user input task without activity chaining. So process instance will be alive and task can be picked anytime later.

Hi Arunkumarc, will this result in another task ID/task instance being created?

Hi,

Yes, it is created new task but existing task is done. Again user can open that task they can do their activities on that.

Unknown said:

will this result in another task ID/task instance being created?

Yes - the new task would be a new instance with a new task ID.  There is really no way around this, other than just having the users click back out to their task list without clicking anything.  Any button or link that causes the form to submit will require the process model to move forward and for the existing task instance to end, as I mentioned in my reply from yesterday.

The only other option is assigning the task to a group.  An individual has to accept the task to start it, and after accepting, they have the rights to reject that task and return it to all assignees.

The process won't move forward until someone submits the task rather than rejecting it and returning it to all assignees.