Undelete/Rollback Data Modification

The out of the box audit log is extremely helpful to track down what happened to some data. E.g. finding if someone accidentally delete/modify something in some way without realizing what they were doing. That being said, is there any method for undeleting or rolling back changes seen in an audit log entry? Maybe a spiffy way to convert the audit entry into an importable spreadsheet row to the data model?

Update: trying to convert the audit entry table to a format that the data import will accept is a huge pain because the field names are different. Underscores replaced with spaces and the letter casing is all messed up.

@fthomas That is an excellent idea, but unfortunately not something we currently have available. Please add the suggestion to our public roadmap - https://roadmap.journeyapps.com/

Your options at the moment are as follows:

  1. Build your own object revision management system in app. Depending on how much control you want to have over it and for how long you want to store “revisions” of the same object you can either use LocalDB for this and store copies of your objects in LocalDB. This option is good for basic in-app or mid-workflow “undo” functionality. If you need more permanent revisions, then you can have another dedicated model that will store previous versions of the same objects in the normal DB. You can then easily revert to those older versions using basic logic and obviously control who can revert and under what circumstances you allow the reverts.

  2. Use the Backend API Oplog to find the previous state the object in question and use that oplog entry to revert. The Oplog entry will be in a more useable JSON format. This option is useful for ad-hoc operations, as it will be quite a manual process.

Hope this helps

Thanks Tielman. I actually realized that copy pasting from the “Action Summary” column of the Audit log had the names exactly right unlike the “More Details” page. So I copied it into a CSV, did a couple text to columns, transposed, and imported into JA without needing to update any field column mappings. Crisis averted!

I also logged a roadmap enhancement as this could have been made easier via a one-click button on the audit log to either download a CSV or better yet redirect straight to the import CSV confirm page. Hopefully that’s a fairy low-hanging fruit QoL improvement.