Enhanced Audit Tracking

This is a solution which I have looked for since long time

This is cool app. Not only audit trail feature even i can prepare report also from this. This app will help me to any number of fields and all data type.

Unable to get it working - can't deploy Apex trigger

This looks like exactly what I need, but after following the installation and user guides I can't get it working. In order to create the Apex Trigger (page 6 of the User Guide) I have to use a Sandbox and deploy it to Production. The deployment process is failing because of a Code Coverage Failure. I am not a Salesforce developer but my understanding is that an Apex Test Class is required to resolve this. This wasn't included in the installation or user guides so I am not sure how to proceed to implement and use the package. I contacted the support email provided on this listing page but have had no response.

Really cool app

This is a really cool app! How many times have I tried to create a custom Auditing solution via Process Builder or Flow and it just never works well. I will start with this app from now on. I extended the app to fill in the lookup to the record for the objects I am tracking and then built a custom report type to show the field changes with the key fields from the Account - something you just can NOT do with regular field history changes. I also added an additional field to mark if the change was by the owner, by the external integration, or by a System Administrator, so the report I did only shows changes where the Account is Active and the changes were NOT made by the Account Owner. I can then subscribe the Account Owners to the report to only receive the report when there are changes they need to know about. I love that it uses Queueable so it doesn't affect the end user's experience of saving the record. My only gripes are... I would love to see it auto deploy the trigger like DLRS does, and the mapping page can be a bit slow when you have 500 fields on an object. Ah, but not so fast... it's still cool, but I did have to make some changes. And I'm a bit disappointed that the app developers said they would not help to implement this. Even though I had no fields that were being updated by DLRS that were also being tracked by this app, the way the trigger works is that it runs on every single update to the record - even if the update is being done in bulk by DLRS. So I had to amend the trigger code and use the new Quiddity function to NOT trigger if the trigger was invoked by a batch update on the record. I think the developers should build this in as default and provide a list of Quiddity Enums in a CMDT for each Object so that Admins can tweak when this app runs. It seems to be working really well now.