Based on what you’re describing, I might suggest some other ideas for options instead of using a database trigger:

1.  Override the method, but change the part that deletes the records.
2.  Override the method, but write the rows to a new custom table, and let the existing method remove them from the original table.  Then you can query the records from the new table, and even join to the existing table.

Thanks @tlanzer25.

I couldn’t override the method that resets the approval as it is one of the private protected methods buried deep down in one of the approval map classes.

instead, I removed the trigger, added a list variable to my method before calling Acumatica’s standard action, broke the link between approval table that will be rest and the current document by changing parent ref to a temp value, call Acumatica’s base method, and finally reestablishing the broken link by restoring from the list variable I kept in memory. To ensure either everything is completed as expected or fully rolled back, I put the full method in a transaction scope. This worked perfectly but was some extra work compared what could have been achieved using trigger.

@aaghaei , that sounds like a good way to get around it, and the transaction prevents commit to the database for the approvals.  I would of course want to test it fully to make sure not removing those approvals doesn’t affect any built in scenarios or workflows.