Understanding Audit Information
This topic discusses:
History versus auditing.
The audit record.
Important! PeopleSoft delivers the system with auditing features disabled. Because enabling auditing can negatively impact application performance, you should analyze audit needs carefully and enable auditing only when there is a strong business reason to do so.
PeopleSoft CRM tracks events that occur in cases and emails using a feature called the Active Analytics Framework. You can view a summary of these tracked events on component history pages. For each tracked event, a corresponding audit trail record stores details of changes and is used to display details of the changes.
Use the following pages to review history information in the Case component and in the Inbound Email component:
Case History page
The Case History page lists information about major events in the life of the case, including a description of the event and details of field changes that are associated with the event. You can define case history events using complex conditional statements. For example, you can configure the case history so that changes to a field only appear if the field changes to or from a particular value.
You set up case history processing using the active analytic framework.
Email History page
The Email History page lists email history events that are captured by the active analytic framework. You can use this page to review email event history, routing history, and audit trail information.
Both history pages offer access to a detailed audit trail page that displays record-level changes. You can specify the fields in the record to audit and the types of changes to capture (add, update, display, or delete). You cannot incorporate logic based on the value of the fields; the system captures changes without regard to the data that changes.
See PeopleTools: Application Designer Developer's Guide product documentation.
The audit record stores audit trail data. The structure of this record determines the fields that get audited. The audit record for the Case component, RC_CASE_AUDIT, stores information from both support cases and help desk cases. The RB_INEM_AUDIT record stores information for the Search Inbound Emails component (the email workspace).
The audit record consists of these elements:
Audit record key fields.
These fields hold information that is specific to the audit action.
The key fields for the records to audit.
These are alternate key fields in the audit record.
Cases are based on several records; the audit record includes the key fields for every record that is audited. The BUSINESS_UNIT key field, however, is not on the audit record even though BUSINESS_UNIT is a key to the main case record, RC_CASE, and to each of its child records. This is because case numbers are unique across all business units, and the value in the CASE_ID field is enough to uniquely identify the case.
The fields to audit.
If a field appears in more than one record, changes to both records are audited. For example, the RC_DECSRLONG field appears in both RC_CASE and RC_CASE_NOTE. By including this field in the audit record, you ensure that changes to both the case description and the note description are audited.
This is the audit record architecture for RC_CASE_AUDIT:
Image: Partial case audit record
This diagram shows the audit record architecture for RC_CASE_AUDIT.
The left and right columns list the records that are audited, or source records. The middle column lists the audit record.
Note: This diagram is an example only. Use PeopleSoft Application Designer to review the actual record structures for cases.
Before you turn on auditing, review the record structure so that you know which fields get audited.
To change the fields that get audited, use PeopleSoft Application Designer to modify the RC_CASE_AUDIT record definition or the RB_INEM_AUDIT record definition.
Important! PeopleSoft does not support modifications to the audit record definitions.