Hello,
My customer wants to change prefix of existing work objects in production system. For example, we want to change it from X-1 to Y-1. Are there any OOTB approach? If not, can we manually change it somehow?
Regards,
Hello,
My customer wants to change prefix of existing work objects in production system. For example, we want to change it from X-1 to Y-1. Are there any OOTB approach? If not, can we manually change it somehow?
Regards,
Hi @CloeW938: It is not recommended to change the prefix of existing cases in PROD because it is part of primary key. Also there may be lot of tables which is still linked to the work object (like attachments, index, assignments).
Thanks.
Hi @CloeW938,
We can’t modify the existing work objects prefix. it is quite risk process and that is not best practice
Thanks,
Ashok
Thanks for the info. FYI, let me share our experience:
We created an activity and opened an existing work object to modify keys. When I changed pyID, system automatically changed pzInsKey, pyInternalAssignmentHandle, and pzInsKey as well, for me. System did not change pxLockHandle, so I manually did property-set to change it. I made it from X-1 to Y-100 in Work table. Also, we did the same for assignments (Assign-Worklist) and attachments (Link-Attachment and Data-WorkAttach-File). As a result, I was able to open the new work object (Y-100) by Review mode and its attachments without an issue, however I was not able to perform the assignment. Customer and I concluded changing keys are risky and gave up this requirement. Below is the screenshot of error when I tried to open a new assignment.
Regards,
Hi,
From design perspective, there are certain aspects that needs to be considered before changing the prefix of the inhouse cases
As discussed in the forum, the pyID value is a part of pzInskey, which spans across multiple tables as a reference key in the PEGA platform, aside from the work table. Here’s a summary of the tables for your reference:
If there’s a business need to modify the pyId value with a new prefix, it’s essential to consider data consistency across every table. I strongly recommend avoiding updates to the prefix for existing cases. However, the approach can be considered for new cases.
-Naren