I have 2 single select data reference tables in the UI. First one is Account and second in the Address. When user selects a row in Account table, the customer ID from that page will be passed into the second table data page and fetch and show the address of the selected account. This works fine when the view or flow action is called in a case flow, but when the same flow action is added as a local action, the parameter value from first table selection is not getting passed to the second table.
For time being as work around, I have changed the local action to case wide and split the screen into 2 screens. First one with the account table and 2 ns screen has the address table and the parameter is getting passed fine now. User has to go through 2 screens just because we couldn’t pass the values in the same screen. Also, this work around is having another issue where if user cancels the screen after completing the first screen, an assignment gets added to the case because they haven’t completed the case wide flow action. Then if the user selects the case wide action from actions menu and doesn’t complete it, again another assignment gets added to the case. This behavior doesn’t happen if it’s a local action. Any suggestions are welcome.
Do you notice any differences in the network tab when checking the API requests? Specifically, look at the sequence of API calls and the request payloads—is there a clear difference in how the parameters are being sent when it’s rendered as a local action versus directly in the case flow?
This looks more like a local action parameter propagation limitation than a problem with the data pages themselves. In a case wide flow action, Pega has a stable case context, so the selected value from the first table can be passed cleanly into the second table’s parameterized data page. With a local action, especially in a modal context, the interaction is more transient, and parameter refresh between two dependent table views on the same screen can be unreliable if the second table depends on a value selected in the first one.
While the workaround solves the parameter passing issue, it introduces a case lifecycle side effect, which is not ideal for a simple selection workflow.
A better approach would be to store the selected Account row value/ Account ID on the work page, use that property as the parameter source for the Address data page and refresh the Address table based on that stored property rather than relying on direct row to row propagation within the same local action.
Hi Haripriya - I was able to get an example working but it assumes that the pyGUID (or whatever the selection property is on the data reference) is also present in the structure on the second data reference, like a “foreign key”. For example, if the GUID on the Customer data object is CustomerID, the CustomerID value would also need to be present in the Address data object. I’ve attached an example configuration with screen shots, using Claimant and Policy, but hopefully the concept comes across.
Data Reference cascade example.docx (1.1 MB)
I know we’re also trying the “screen flow” approach, with the possiblity of canceling the assignment via SLA, or checking to see if there if is an existing address change that needs to be restarted.
