@Sad?kY99

This happens when the row you “delete” in the UI is not actually removed from the source that repopulates the list, so a refresh or save reloads it. First, check the data source of TransactionList: if it comes from a read-only Data Page, Report Definition, or integration Data Transform, the Delete Item only trims the client list; the next refresh reloads the original records. Fix by editing a persisted source: either copy the TransactionList to a case property (Page List on pyWorkPage) and save the case, or switch to a savable Data Page and call Save data page after delete. If each transaction is its own data instance, call Obj-Delete-By-Handle (or a delete activity/REST) for that record and then refresh the list from the DB. If it’s an embedded list on the case, use a proper server-side remove (Property-Remove / RemoveFromPageList / pxListRemove) in a post-action Data Transform or activity, and then Save/Commit the work object. Check for any pre/post-processing Data Transforms that rebuild the list and unintentionally re-append the deleted rows; remove or guard those with “when” conditions. Make sure the section/region showing the table is not configured with “Reload once per interaction” or a refresh action that re-calls a loader DT/DP. If you must keep a read-only Data Page, introduce a “isDeleted” flag and filter those rows out in the table source until the back-end delete completes. Verify that sorting/pagination is not bound to a different list than the one you modify. If you are using Constellation, wire the trash icon to a View action that calls a server action set (DT/Activity) to remove, then “Save case,” then “Refresh list.” Ensure optimistic locking isn’t blocking the save (lock the case before delete if needed). After the change, confirm on tracer that the correct page list length decreases and that a Commit occurs. Finally, re-test by reopening the case to prove the deleted row does not return.