I am working with a three‑level embedded page list structure:
LoadCharacteristicsList
UnitsList
LoadsList
Multiple breakdown lists at the same level as LoadsList
The LoadsList is rendered as a table in the UI with columns Load Type and Number of Devices. Based on the user’s input in this table, corresponding breakdown tables are conditionally displayed below.
Requirement
When a Load Type record is removed from the LoadsList table, the corresponding breakdown table (along with all its values) should be completely cleared and removed from the UI.
Current Implementation
Since this is a deep embedded (3‑level) structure, I am using pyRefreshData with a When rule to clear the relevant breakdown lists when the Load Type is removed from LoadsList.
From a runtime perspective:
Tracer clearly shows that the breakdown list entries and their values are being removed as expected.
I have also tried explicitly setting each individual property inside the breakdown list to null before removing the list.
Issue Observed
Despite the above:
When the same Load Type is added back into the LoadsList, the previous breakdown values reappear in the UI.
This behavior is seen only in the UI; tracer confirms that the breakdown lists were cleared earlier.
Multiple variations of When rules and list‑clearing logic were attempted, but the issue persists.
This suggests a possible UI state caching / refresh issue, where the UI is not fully reconciling with the updated clipboard state even though the data is correctly cleared server‑side.
Ask
Is there an alternative or recommended approach—other than using pyRefreshData—to rely on:
Clear breakdown list values when a Load Type is removed from LoadsList, and
Ensure that stale values do not reappear when the same Load Type is re‑added?
Any guidance on best practices for handling such deep embedded list clean‑up and UI refresh consistency in this scenario would be appreciated.
The recommended approach for complex data structures is Table with Modal actions. It is thankfully built right into the authoring, so you don’t just have to rely on my opinion or documentation.
The implication of your question, is that you’re hitting the limits of what pyRefreshData can offer you in terms of control. I would be looking at using Tables with Modals that give you more control with pre/post processing.
There are alternatives available, they are not a one size fits all but like the table with modal actions solution. It’s all about trying to break up a complex UI into smaller, manageable parts.
It improves the UX
It makes it easier for the developer to manage state and process data by providing more hooks with pre/post processing
I’d love to hear from the community on what they have or haven’t used it for.
Personally, I find this light when it comes to documentation and implementation (e.g. Defining the run-time presentation of Flow Actions) and coincidentally have been having discussions about how we can get more knowledge out there.
am yet to discuss that with @JayachandraSiddipeta as he is already so busy helping the community with other Expert Circle conversations and an upcoming Webinar
Thanks @MarcCheong
Using Pre or Post DT in modal actions, will work if they click on edit option from the table, but suppose the user doesn’t click on edit option, and directly removes it from the table using delete option in the table itself, in those cases, i tried pyRefreshData so that it removes the contents from the breakdown table as the modal pre or post DTs wont run in that scenario
If the tables are related, via a hierarchy, then I would be using Embedded inside of Embedded data model. Then you delete the parent embedded rowit would delete the child embedded row.
E.g. in an Insurance purchase case:
Capture Family Members
Each family member we capture Medical History
If i delete Family Member 2, then it would delete the medical history for that family member.
So in you’re example, given you have this “sibling table” then post processing would happen on submit of the higher level. E.g I delete LoadsList, post processing the breakdown list wouldn’t change, once i submit the Units List, i could use post processing to clean up breakdown list?
We have used Repeating Views for a similar use case, where the deletion and modification reflects the same in UI and clipboard. However, we’re using the screen flows so the data get persisted in the clipboard during any modifications.
@Priyam From the question, I understood that this is what you are trying to achieve. I created a list property Unit List and in it, we have Load List, Brk1List, Brk2List, Brk3List. Now, when we add a record to Load List, we have a pick list to select Brk value. If I select Brk1, I need to see Brk1 list with 1 empty row added, and same for others. If I remove any Brk value, corresponding BrkList should be cleared and removed from screen. If re-added, it should start with empty row. Please confirm if this is the requirement. If this is the requirement, it is achievable with combination of pyRefreshData and visibility when conditions.
Hi @VVNagaSaiN LoadsList contains Loadtype, based on Load Type, breakdownLists are visible,the pyrefreshdata is not removing data from breakdown lists if we do save from later and come back to the case and remove Load Type from LoadsList, the BreakdownLists are removed from the screen, but the data inside still remains, though in tracer it shows values are deleted
Yeah, Once the case is saved, its behaving exactly like you mentioned.
But I think there is a reason for it. Even though the tracer shows that the values are deleted, they are just deleted from caseContent page which is formed in the API but not the original case. Here, everytime refresh API is called, case is opened from the database in which these records are never deleted.
For that to happen, once they are removed from caseContent, pega should add these records to pageInstructions with “DELETE” instruction like below.
If it adds to pageInstructions like this, next time refresh API is called, first these instructions get applied on the case Data, delete these rows, and then our logic will run.
BUT, We are deleting our Breakdown list records using pyRefreshData but not directly from the UI be clicking delete. It seems like whatever logic we are running in our pyRefreshData, it is not considering it to add to pageInstructions. Only actions that are performed in the UI directly like Add record, Delete directly from the UI are getting recorded.
SO, as of now this is how it is designed to work. @MarcCheong Hoping in further versions this functionality can be extended in such a way that system compares the data before and after the run of every API call and update pageInstructions based on those changes as well.
This is purely my understanding on how things are working right now. Please feel free to correct me if anything I mentioned is incorrect.
I have passed this feedback on. I am hoping we can have some firmer guidance on pyRefreshData in '25 soon (and '26 for whatever enhancements/changes are made)
