Measures for “Cannot Delete Issues!”

I am writing this because I had several same inquiries in quick succession recently.
Those were inquiries about

“Some applications are possible to delete, and some are not!”

By listening to their situations carefully, I found that;

Possible

If the application was immediately after being made (which was immediately after being Started), it can be deleted at a Process Detail screen.

Process Detail screen 1 : Deletable

Impossible

If the application was back to Application Making Task from Approval Step (that means it was Rejected), it cannot be deleted.

Process Detail screen 2:Undeletable

To represent using a Process Model Diagram, it is as the following.

Capable and Incapable of deletion
<Capable and Incapable of deletion>

It’s too bad, but it is “Behavior as designed”.
Below is the reason why.

It is in order to prevent disappearing of the Issue without record of the fact that it has been rejected if the issue itself deleted after it went to someone else since it had been Started.
Deletion is possible when immediately after the application was made (which was immediately after being newly Started) because the necessity is low as it was not passed over to anyone’s hands yet.

“How do I handle a case where I Started a wrong issue, and it was rejected at approval?”

I have heard voices like that when I explained the reason.
Below are examples of measures.

1. To request deletion of the Issue to Privileged User

(Reference) M302 ADMIN-PRIVILEGE Assign Privileged Administrator of Each Business Process Definition

To run a Business Process Definition (Process Model) as a Workflow, you need [Process Model Editor Authorization], which is an Admin-Privilege that configured on each Process Model (Process Model Local). There are also [Administrator Authorization] and [Data Viewing Authorization] as Process Model Local Privilege.

2. To implement a Flow for withdrawal

It cannot be said “1. To request deletion of the Issue to Privileged User” is realistic measures if using by hundreds, thousands of Users.

Regarding “2. To implement a Flow for withdrawal”, I think it is easy to implement and easy to understand for Users.

Process Model Diagram of implemented Withdrawal
<Process Model Diagram of implemented Withdrawal>

The issue goes to End when “withdrawal” was carried out, so the “Record of Rejected and record of Withdrawal” will be preserved.
It will allow you to cope with questioning by the Approver, “What’s going on with that Issue?

Regarding “2. To implement a Flow for withdrawal“, it will allow withdrawal by the applicant. Whereas, there is also a risk of “Rejected Issue to be neglected!“.
The Issue would remain forever in My Tasks of the applicant. And the applicant would think “What is it about? Why it is remaining in My Tasks? I don’t know for sure, so let it leave alone.

I suppose everyone of you have been taught “Keep your desk clean“.
So, you should keep your My Tasks clean.

Process Model Diagram of implemented Withdrawal devised version
<Process Model Diagram of implemented Withdrawal devised version>

It shouldn’t be left for three, four days after being rejected.
In most cases, these Issues can be considered to be withdrawn automatically.

Measure against neglecting is possible by Flowing to End event using Timer Boundary event.

There wasn’t such a problem in the era when the application and approval has been carried out in the paper application form.

If it is an application of the paper, you can bring it back from the approver’s document tray of after the submission (although you shouldn’t do this), also you can throw away the document that has been rejected into the shredder.
On the other hand of convenience, I think it can be said it took so much time and effort for progress checking on application documents and looking for application form of the past.

Although you may feel a little bit cumbersome that your jobs have become digitized, you may be able to progress your jobs conveniently by some devising using Questetra BPM Suite.

Please feel free to consult us whenever you have trouble.

2016-04-05

About Masato Furukubo

Questetra, Inc. Sales Department
View all posts by Masato Furukubo

Recommendations
Prev article - 50. Questetra Tips To collaborate Cloud-based Workflow with Cloud Storage (Dropbox ed.)
Next article - 50. Questetra Tips Method for Operator Setting Being out of Process Model
Another article - Masato Furukubo To Control Inputting for Multiple Select Type Data Items (Radio Button / Checkbox ed.)

Archive

 RSS