Nearly every case type we setup starts with a task where operators can fill-in data and join attachements.
Pega requires cases to be persistent to be able to manage attachement. This is very frustrating since cancelling the creation of a case stills creates the case. We had to implement a tricky "Delete Case" capability which is also frustrating since deleted case ids are "lost".
There is no OOTB way to manage attachements on temporary cases which is very limitating. Nearly any other demand management software include such a feature OOTB (Jira, ...). Any chance to have it included in Pega any time soon?
Thanks you very much for the provided links, especially the first one I didn't spot by searching myself.
Obviously we are are not the first ones to ask for this feature which is quite basic on a business perspective. We could of course spend some days (and money) building custom code to implement this behaviour while it should be built-in. Do you plan to include it in a future Pega release?
I'm not sure if this is currently planned, however our moderator team can make a request on your behalf for the desired functionality to be considered for inclusion in future releases. I've discussed with a member of our moderator team, who I'm looping in here.
Thanks for the suggestion. It could indeed make the job but have many side impacts and thus could only be considered as a technical workaround.
As in (nearly) every solution, user should have the chance to cancel an action he just started without impacts on the system. Pega supports this when an operator begins a task and then cancel it, but not when an operator creates a new case with attachements.
We understand that on a technical point of view, the evil is in the attachements, but it should be made transparent.
The ultimate solution is to wait for product enhancement FDBK-60599 as stated by Marrissa.
About the tricky "Delete Case" workaround : as you guessed, we have to cope with lost sequential IDs. Losing IDs just because you clicked on "New Case" by mistake is not explainable to the business. On a technical point of view, we had to develop and have to maintain this "Delete Case" logic which by the way should also be built-in.