Common practices for canceling a user input task?

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:

  1. Looping back to the user input task if a user clicks cancel to trigger a new task
  2. 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.

  Discussion posts and replies are publicly visible

Parents
  • Certified Lead Developer

    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.

  • This is my train of thought as well. The action would need to be completed unless there is an issue beyond the scope of the process that makes the task void. In that instance, I think an admin should should come in and delete the process. This happens infrequently.

  • I think an admin should should come in and delete the process

    Also a quick note here, you should never consider deleting data, or a process instance (unless it's data is persisted to the DB), unless it is explicitly required such as in HR data retention requirements, etc.  I cannot count the number of times users have 'deleted' something and requested it back, which is easily possible if you retain, and flag the data.  This is also a concern for auditing, for any data sets where that may apply.  

    In this scenario I will always suggest having a function available for process administrators (vs system administrators), such as a Related Action that will allow them to "cancel" the request (updating a status flag), which can be filtered in and out of reporting as necessary.  

Reply
  • I think an admin should should come in and delete the process

    Also a quick note here, you should never consider deleting data, or a process instance (unless it's data is persisted to the DB), unless it is explicitly required such as in HR data retention requirements, etc.  I cannot count the number of times users have 'deleted' something and requested it back, which is easily possible if you retain, and flag the data.  This is also a concern for auditing, for any data sets where that may apply.  

    In this scenario I will always suggest having a function available for process administrators (vs system administrators), such as a Related Action that will allow them to "cancel" the request (updating a status flag), which can be filtered in and out of reporting as necessary.  

Children
  • My Appian application pulls some data from an integrated external Oracle database and the data is used. If there is ever a problem with submitted data, like a privacy issue, all systems may be required to scrub it.

    I've seen a case (prior to using Appian) where someone entered their SSN into an address field which got exposed to other systems. So if that happened in my app, I would need to kill the process and wipe out anything that got written to the data store.