Set a dynamic Case ID prefix based on a property selected by the user during the case creation stage

General
, ,
1

I am trying to set a dynamic Case ID prefix based on a property selected by the user during the case creation stage, using pyDefault runs too early, and by the time the create stage view is shown, a caseID is already created.

2

Can anyone help with this? It seems like quite an obvious requirement, but that doesnt always mean its possible in Pega…

3

Hello @PhilipG1165

I am afraid you cannot modify the case prefix once the case is created and that too based on the data entered by the user. This is, if you are using a standard work portal or a self service portal rendered through pega login.

Below are the approaches i can think of,

  1. If you have the UI screens outside pega rendered in react / angular where user will fill the data in the screens and on the final submit you call DX API for creating case, then should be able to dictate the pega case prefix in pyDefault, pySetFieldDefaults, etc
  2. You can have a simple isolated case created first to get the inputs from the user and then based on that inputs you can create your actual case. Keep them linked together as related cases.
  3. Last but not least, i could think of will be parent-child relationship. Parent could be the case which is created for data intake and based on the that information, you can create the child cases with conditionally derived prefixes.

I would let others also pitch in with their opinions here.

Hope this helps

Regards

JC

4

I have had this requirement before. We went with @JayachandraSiddipeta’s option 2 - we had a case called “new service request” and in that form it had the fields required to create the actual case.

We created it as a spin-off case, so there was no parent/child to confuse the end user. For all they new they created the case and had a case ID with the prefix they needed.

5

Interesting, thank you

The spin off case being a completely separate case type (as you said not child case)?

If so, my plan would to be to frontload a new caseType to make that initial selection, with the current caseType being the ‘spin off’ case I guess. (in order to keep all properties in the case type and reporting available, rather than separate caseTypes.)

6

Correct. Not child case, just removed that hierarchy, which in our scenario confused users. That said, if your user base actually like this, then there is no harm in keeping it. It’s all about testing and iterating to get the desired UX.