PeopleSoft Audit

Monitoring changes to important data and collecting facts about what changed, who changed it and when did it change should not be looked at from the perspective of a list of application data tables.

You should approach your PMO (Project Management Office) and or stakeholders (the managers held accountable for data integrity of the application (Ex: HR Manager and/or Payroll Manager)) for assistance with identifying specific categories of data and thus specific data elements to be monitored for change.

Typically, you will find that they want to see who changed compensation data, or who changed authorizations (permissions, etc.).

Don't rely on making educated guesses.

These managers decide what data to monitor for changes based upon industry standards, corporate policies and government regulations.

Once you have identified what they want "Audited" and where that data is stored, you have a few options available to you.

PeopleSoft audit features monitor changes that take place through the on-line (OLTP) portion of the application via the Component Processor (the heart and soul of PeopleTools).

Data Changes that take place through batch processing (SQR, Application Engine Programs using PeopleCode to update tables directly rather than component interface), will not be recognized by the component processor audit tools.

Having said this, you have two approaches available within the application (the component processor), both of which require working within the Application Designer tools.

1. Field Level Audits.
When a user changes the value of a field (data element) within a web page, information about the change (who changed it, when did it change, what was the original value, what is the new value) get stored in a common table (PSAUDIT). You can turn on the feature for specific record fields within application designer.

2. Record Level Audits
When a user changes any on of a number of fields on a given table, a snapshot of the prior values of the fields may be stored in an "Audit Record". Rather than storing information about who, what and when in a common table (PSAUDIT), it is incumbent upon a developer to construct a new record definition (table) whose name begins with AUDIT (Ex: PS_AUDIT_JOB). This table will store "audit records" containing the values of a collection of fields originating in the PS_JOB table.

3. External to PeopleSoft Audit tools, are data base level auditing features, such as database triggers and database audits.

One advantage of database level auditing tools is that they are not limited to monitoring only those changes that take place via web pages.

They recognize the fact that a field value has changed, even when the change takes place outside of the application (Ex. SQR, COBOL, SQL Scripts, etc.).

I often recommend to my customers that they turn on both record level as well as some for of data base level auditing features concurrently.

If the PeopleSoft Audit Record and Data Base Collection Record mirror each other (have the same record format), this provides you with the opportunity to subtract the PeopleSoft Audit Records (on-line activity) from the Data Base Collection table. Thus the only remaining records/rows stored in the collection table detail data changes that took place outside of the access controls of the application.