Question
Pegasystems Inc.
JP
Last activity: 18 Jun 2017 21:37 EDT
The task with label 'ASSIGNMENTXX' and id 'XYZ' could not be found in this flow.
Hi,
We have MyApp:01.01 in production and we are going to import a new enhanced version MyApp:01.02. There is a workflow which has small changes (We have just overrode the flow rule to add local actions to Assignment shape). Since customers don't want to resolve all open cases before import, and also the changes are minimum, I would expect the old assignment (created in prior MyApp:01.01 version) for this flow to be still openable / performable after new version is imported. However, there is only one flow rule that is giving error when user tries to open this assignment that says, "The task with label 'ASSIGNMENTXX' and id 'XYZ' could not be found in this flow." and assignment can't be performed. There are also some other flows but they are fine and only this flow is problematic. My guess is, when developer overrode this flow rule, he might have deleted the assignment shape and added a new shape. Each assignment shape has some internal (in this case "63") and that shape is gone. The old assignment is created based on this old "63" assignment shape but after new version is released, user would open this same assignment object in new assignment shape (maybe different number?) and PRPC throws an error. Am I correct? If so, why isn't PRPC built such way that this kind of migration would be handled correctly? If my guess is incorrect, can anyone direct me how to fix this error?
*Details are attached in the excel file and please take a look.
Thanks,
Accepted Solution
Pegasystems Inc.
JP
I did save as the original flow rule before assignment shape was edited to a new version and without deleting shape I did all the needed changes (adding local action, etc) and resolved this issue. Though I still think PRPC should be built in a way that developer don't need to worry such issues.
Thanks,
Pegasystems Inc.
IN
Hi
The above reported scenarios happen where there are any modifications/deletions are done to the flow as you mentioned. And say suppose, you have initiated few flows without resolving them, and later modified some of flow itself, and resume the earlier flows with these changes, then you would such errors because there are few parameters like FlowInsKey that gets modified and the latest run tries to find for the key that is stale( points to the earlier one).
To get over this, you can implement a workaround by circumstancing the flow rule with date period. Like if the flows that are created prior to this date use the flow rule that is not modified and the flows that are created after the flow modifications should use the new flow rule. This way you can ensure that the flow resume points to a proper inskey to work on the assignment.
Thanks,
Madhuri
Optus
AU
Hello,
Can you try running the "Work-.FixProblemAssignments" activity by passing the pzInsKey of the case for which erroneous assignment exists and share the results.
Accepted Solution
Pegasystems Inc.
JP
I did save as the original flow rule before assignment shape was edited to a new version and without deleting shape I did all the needed changes (adding local action, etc) and resolved this issue. Though I still think PRPC should be built in a way that developer don't need to worry such issues.
Thanks,