We have a caseID that is updated in our system from JA-0001 to JA-xxxx-yy-0001. When we search with just input JA-0001, it finds the case and opens properly. We have a requirement to be able to search for the whole new caseID (of format JA-xxxx-yy-0001). We do not want to change the PEGA OOTB functionality as that works fine, we need to somehow change how it is searching for this specific caseID or reformat it before the search occurs so it can find it properly. There should not be a case where the (xxxx-yy) will be the same for two caseIDs unless the final 4 digit value (0001 value) is different (The JA and 0001 are the only two values that should make the case ID Unique).
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
We have a case prefix that is updated in our system from JA-1 to JA-xxxx-yy-0001. Earlier we were able to search with case id say JA-1, and pega finds the case and opens properly.
After tweaking the case prefix per new requirement, new case ID format is JA-xxxx-yy-0001. We are not able to search cases with the new case number. Looks like Pega bug to me, but want to see if anyone else faced the same issue.
I have re-indexed and it hasn't rectified the situation. This to me seems like a Pega bug of some sort with custom prefixes.
We are running on Pega 7.31, Customer Services 7.31.
I have now determined what the cause is and it's related to Activity pzSearchResults and step 11. Seems there is an issue with the regex call here as it returns false instead of true. This lead me to this https://community.pega.com/support/support-articles/unable-search-cases-custom-work-id-format but is referenced for Pega 7.2.2 as an enhancement request, which is bogus if you ask me as it's a bug. If you can change the prefix to suit business requirements then anything that uses the pyID should also respect those changes. However since we are running a later release I'd have expected this to have been rectified by now! Any thoughts?