As per the retention policy with the customer, the messages and posts deleted can not be wiped with the delete operation. When a user clicks on Delete of a message or post, the message cannot be completely wiped out from the Database until the defined threshold purge time period.
Within OOTB implementation of Pulse, the message gets deleted as the user hits delete.
Our design approach to addressing this is as follows:
When the user hits delete, along with the deletion of the transaction, we wanted to move the message to a new DB Table.
This way, the messages table is always clean and we can maintain a copy of deleted messages and posts in another structure.
We need help in Pega confirming the table structures they use to maintain through the pulse lifecycle. Also, please provide guidance on the best approach to handle this.
Your approach seems reasonable. I don't know all of the database internals for the pulse tables, but presumably if you followed the class mapping you could use the same schema in your new table that is used the other one.I'd start by tracing the delete with DB interactions turned on to see where it goes in the database, in case there is more than one table involved