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:
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.
Discussion posts and replies are publicly visible
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.
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.
Chris said: 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.
I can definitely agree on the user experience concerns, and it is an interesting little area for debate regarding Process Start Form cancellation. For the other scenario of User Input Tasks used for process initiation, we always have a Cancel decision available, where the already-started process ends and leaves the user at the application home page or Actions list (not site-based).
In this scenario with a site with an Action Page, Process Start Form. If we provide a "cancel" decision, this will start/end a process, leaving the user back at the same start form, just with any entered data cleared. If the user "cancels" before entering any data, it appears as nothing occurs (also potentially confusing). We can always route them to a User Input Task showing a note such as "request cancelled", but this leaves a task in their Tasks List if we use a no-button, short exception method to end, unless we give them a confirmation button to close the "cancelled" screen and route back to the start form. We would also need an exception on the confirmation, try to keep it short to minimize showing in the Tasks List, but users can leave their tab open past the (say 5-10 minutes) timer, then click to close later and receive an error that the task has already been completed.
I have a handful processes with those types of confirmations (that auto-close via exception) and I don't think I've ever decided what I think is best for the timer, as a standard..
But so far in my experience with Sites, I have had less complaints on inability to cancel Process Start Forms, than in other areas, so I promote the logic of "submit or not submit" ;)
Also agree that with appropriate archive/delete process model cleanup settings, dev and server use is negligible for starting/ending a process with a "cancel" mechanism on these, should the users prefer.
..mostly just my $.02 :)
My bad -- It didn't even occur to me that you were referring to implementations using the "start form as site tab default page" approach. In that case I agree - if a user hasn't clicked into any action / related action / etc, then it's probably best to avoid having a "cancel" since it'll just appear like their data has been cleared. This is an illustration of why I've personally chosen in almost all cases to avoid setting things up this way -- invariably I prefer "actions" that a user needs to click into, and thus can click out of; whether that's traditional actions or simply "start process links" on a SAIL form.
No worries! Just covering both scenarios. Agree on a!startProcessLink(), we also use this primarily for process initiation, within SAIL forms containing a "cancel" decision, mainly in Tempo, vs our Sites typically utilizing Process Start Forms with no Cancel decision.
I have one Site with a Process Start Form that has neither Submit or Cancel, in a one-form-process type setup. Options are chosen via 3 sets of buttons, when the final is clicked a!writeToDataStoreEntity() persists the data, hides the inputs and shows a confirmation. Users can re-click the Site Page to re-load but they typically only need to submit once per day. Since the start form is never submitted, it doesn't even initiate a process (my server admin was pleased ;) ).