I have to report back to our development team on Thursday on the auditing within SF. I have seen many threads but need to know if the auditing (as far as saving data to the audit tables) is working within the SF Framework. If so what we need to do to make it work. We can build our own viewer if one is not available yet.

The SFSAuditDataChanges, SFSAuditDataFields, and SFSAuditEvents are deployed to the same database as my other RBS tables.

I am assuming I need to turn on Auditing by user (although I really want this turned on for ALL users). In the security I can't find where I set this property. Where is it? Can it be set programatically?

Next I am assuming I need to set properties on each BO such as "AuditDataChanges". What properties need to be set on the BO?

Do any properties need to be set at the column level?

If these properties are all set, will the SF Framework automatically track new rows added, column changed and rows deleted in the 3 audit tables above? Or is there something that is needed to be done in addition to the above?

Is it possible to set a property the track changes and deletings but not additions?

Above my questions relate to tracking columns in tables and not events. IE.... tblCustomer.CustName

Finally, if I wanted to send a record to the 3 tables above such as "Attendee attemtped to register twice", what would be the method to have this reflected in the audit tables?

 

 

Trent, I have my meeting today with my Dev Team at 2PM and I need a definitive answer to this thread. Does Auditing work or not as advertised? If so, I need to know and how to make it work with any small example. We do not want to waste our time trying to chase something that does not exist.

Ross,

There is a reason that the "just check it" approach hasn't taken hold.  We don't even use it ourselves in the medical world due to several factors:

1. The check it and forget it approach would produce records client side, a lot of records, then have to move those records to the server.  This in and of itself would be horribly inefficient as there would be WAY to many audit records produced for every live record.
2. Ambiguous and monotonous data would be created making it very difficult to filter through.
3. Prevents triggers and/or client side threads outside of the BO basic logic to be implemented improved performance and reducing overhead.

In our medical application we audit a lot.  But it is thought out and implement where it is necessary instead of just pulling the "log it all" card.  If you want to log it all, then get a SQL Server side auditing tool that interfaces at the server level that will do this for you.  But if you want to create intelligible viewers and log records for your client to use daily, then you will want to think about what you want to log.  Below are a couple of screenshots from our medical application:





In our event viewer (1st image) we have many events, but they are organized and thought out.  This includes field level changes in different areas of the application that captures.  But some of these are not turned on by default and is an option within our application:



As you can see in one of our audit options screens, there are warning signs next to anything that will produce a vast number of audit records.  They can turn it on, but it is an option.  You can wrap security around this as well.  But it is extremely important to think out your audit approach and needs. 

You can combine approaches too.  You can slap an SQL auditor on the SQL side to catch everything.  Then you can get more pointed and specific on the app side.

Hope this helps.