Setting Up Auditing for Cases and Inbound Email

This chapter provides an overview of audit information and discusses how to set up case auditing.

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.

Understanding Audit Information

This section discusses:

History versus auditing.
The audit record.

History Versus Auditing

PeopleSoft Enterprise CRM tracks events that occur in the Case component and Inbound Email component 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 the Case History page and the Email History page 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.

The Audit Record

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 Inbound Email component.

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:

Partial case audit record

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.

Setting Up Case Auditing

This section discusses how to set up case auditing.

Page Used to Set Up Case Auditing

Page Name	Object Name	Navigation	Usage
Audit - Setup	RC_COMP_AUDIT	Set Up CRM, Common Definitions, Audit Trail - Setup, Audit - Setup	Choose which actions (add, change, and delete) to audit.

Choosing Actions to Audit

Access the Audit - Setup page.

Note. PeopleSoft does not deliver entries for the inbound email component.

To define a new entry for this component, use the following values when setting up this page:

Component name: RB_EM_IB.
Audit record name: RB_INEM_AUDIT.
Record (table) name: RB_IN_EMAIL.

Component Name

Enter the object name of the case component. PeopleSoft delivers entries for RC_CASE (the Case component).

Although you configure auditing at the component level, the processing occurs at the record level. Therefore, when multiple components are based on the same record, the system captures data changes regardless of which component the user was in when making the change. For example, the auditing that you establish for the RC_CASE component is also valid for the self-service case components, which are based on the same records.

Audit Record Name

Enter the record where the system stores information about data changes. The structure of this record determines which fields get audited.

Record (Table) Name

Enter the record that is associated with the audited component. The Case component includes data from several records.

Record - Audit Options

The fields in the Record - Audit Options region enable you to select which actions (add, change, and delete) to capture for each record that you audit. The selections apply to all audited fields in the specified record. You cannot set any field-level auditing options; all fields in a record must use the same auditing rules. To set field-level auditing options, you must redefine the audit record using PeopleSoft Application Designer.

When you activate auditing on the Audit Setup page, you turn on auditing only for the fields that are included in the audit record (RC_CASE_AUDIT or RB_INEM_AUDIT)—the record that stores the audit trail data.

All auditing is based on differences between the field values at the time that the component is opened and at the time that the component is saved. If a user saves several times while working in a component, each save triggers auditing activity.

Add	Select to have the system capture the change every time a value is added to a field that is audited. A value is considered as added in two situations: When data is in the field the first time that you save a new row of data. For example, if you create a new case, the values in all populated fields are considered as added the first that time that you save that case. When you save data in a field that was previously null.
Change	Select to have the system capture the change every time the value of an audited field is updated. A value is considered updated when a new non-null value is different from the previous non-null value.
Delete	Select to have the system capture the change every time the value of an audited field is deleted. A value is considered deleted when a null value replaces a non-null value.
Show Field Label	Select to have the Audit Trail page display the field labels rather than the field's object name. For example, if you're auditing the RC_PRIORITY field, selecting this option causes the Audit Trail page to refer to this field as Priority rather than RC_PRIORITY. If this check box is clear, the Audit Trail page displays field values. If the audited field has translate values, the translate long value appears.