I am writing this because I had several same inquiries in quick succession recently.
Those were inquiries about
By listening to their situations carefully, I found that;
If the application was immediately after being made (which was immediately after being Started), it can be deleted at a Process Detail screen.
If the application was back to Application Making Task from Approval Step (that means it was Rejected), it cannot be deleted.
To represent using a Process Model Diagram, it is as the following.
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.
== Example Measures ==
“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
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.
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?”
== Further Devising ==
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.
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.
== Afterword ==
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.
|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||Trouble-free! How to Perform an Options-XML Update? (Service Task Addon ed.)|