We have a Constellation application of version 25.1.3, cases can be created either manually or automatically through an external system using a Service-REST rule. The case processing flow is identical for both methods.
We are encountering an issue with automatically created cases. When users click Submit or Save for Later , an “Invalid Request Data” error is displayed. This issue does not occur with manually created cases.
Observation:
On analysing the system logs, the following error was identified:
“For CASE-XXXX, the field Application.Address.AddressLine3 was not found in the PrepareCaseDetailsWrapper view for the PrepareCaseDetails flow action.”
To address this, we added the Application.Address.AddressLine3 property with a custom visibility condition. However, a subsequent log entry reported that Application.Address.AddressLine2 was not found in the same view and flow action.
This pattern continues, where each time a missing property is added, the next execution reports a different property as missing from the PrepareCaseDetailsWrapper view for the PrepareCaseDetails flow action.
Are there any more steps to be configured? Please let us know.
If you are seeing the “Invalid request data” error banner when trying to submit a Flow Action in Constellation, it is almost always caused by a discrepancy between the data payload structure being submitted by the front-end (DX API) and what the back-end Pega rules engine expects.
So my theory is:
The cases created via API do not have the right data structures. I find this hard to believe but theoretically it is possible to save a case/data instance with incorrect data.
You’re hitting some sort of Form Refresh Data, pyRefreshData, lazy loading or bug, where the data isn’t in the right state. I know 24.2 had an issue with hierarchical form that did that.
If you can’t find something obvious (1) then I would raise a ticket with Pega Support to help investigate why the payload is wrong.
Could you please confirm if you have configured the required fields in AllowedStartingFields DT that’s been passed as part of the API call. Usually, I have seen this issue whenever the fields are not defined in AllowedStartingFields DT. Please check. Pegasystems Documentation
We identified the root cause of the issue. It was caused by a customized When rule in which the page reference was configured with a TOP reference. The same When rule was referenced across multiple properties, which resulted in the “Invalid Request Data” error being thrown.
We have now updated the When rule, and the issue has been resolved successfully.