For process start forms, I use an OR gateway that goes to an end node if the pv!cancel variable is true. I don't want to implement the same flow for user input tasks as it would kill the process without a way to retrigger. The approaches I'm considering are: Looping back to the user input task if a user clicks cancel to trigger a new task Omit the cancel button from the form so that user would just have to reject They both effectively force completion or reassignment of the task. In both cases, process or data manipulation would be needed to address a task that's lingering or deemed unnecessary. I just want to gauge which of the 2 options do people find themselves doing.

Question

Common practices for canceling a user input task?

Forum|Forum|5 years ago
April 13, 2021
9 replies
0 views

For process start forms, I use an OR gateway that goes to an end node if the pv!cancel variable is true. I don't want to implement the same flow for user input tasks as it would kill the process without a way to retrigger.

The approaches I'm considering are:

Looping back to the user input task if a user clicks cancel to trigger a new task
Omit the cancel button from the form so that user would just have to reject

They both effectively force completion or reassignment of the task. In both cases, process or data manipulation would be needed to address a task that's lingering or deemed unnecessary.

I just want to gauge which of the 2 options do people find themselves doing.

stefanhelzle0001

From a BPM perspective, a task assigned to a user cannot be cancelled. There can be different types of decisions or outcomes. Cancelling a task would mean to just stop processing.

If there is no specific business requirement then I do not add cancel buttons to tasks. Start forms need one, that is obvious.

Just my two cents.

csteward

Regarding Start Forms, I will use a Cancel decision if this is the first User Input Task inside the process model, however for Process Start Forms, I can't recall any situation where I've had to use a Cancel - as they do not create a process until submitted. Say in a Site Action Page, cancelling there would create a process just to end it, and leave the user back at the same form, essentially just removing any data entered. I would be interested to hear different use cases there.

For downstream tasks, I only implement a decision that ends a process negatively (cancel, deny) when explicitly required for reviewer or implementer type roles. Otherwise my standard is for these roles to "Reject" the process back to a task for the submitter, allowing them to resubmit with updates or "cancel" their own request. Orphan Exception Timers are always applied to submitters' tasks (typically extended for resubmit, vs initial submit) and never used to automatically end processes in downstream tasks (sometimes used for re-routing).

For the initial use case here, are you looking to have a process continually running that a user can always access an active task from? For example, we have Tempo processes with home pages, say under Records->Applications, these use a!startProcessLink() to create a running instance, the initial task has a Cancel decision, which closes it out with no routing, etc. They can then access the start link from the home page to submit another at any time.

mikes0011

Brainy

I would be interested to hear different use cases there.

My main (and perhaps only) counterpoint would be that it's unintuitive to expect a user who clicks into an action to somehow know that they don't really need to "Cancel" from a start form since they can simply click away. There's no reason to think they'd know or understand the difference. And of course there's no alternative functionality made available to designers to allow someone to "cancel" out of a start form without it being a submit button that starts and immediately terminates a process instance. I've always found this to be a rather small cost for the ability to avoid creating additional confusion for end users.

Sign up

Login with SSO

Login to the community

Login with SSO