Field Level & Record Level Auditing

Auditing is to perform to track the changes whatever done in the record. Its of two types:
* Field level auditing
* Record level auditing

Field level auditing:

The auditing mechanism enforced on a Field is known as Field level auditing. Field level auditing captures changes in one or more fields which are
then stored in PSAUDIT record. One thing to note is that only online changes are captured while Database level updates / inserts, deletes wont come
under audit.
Setting up Steps:

1.

open the record containing the chosen field

2.

go to the Record field properties of the field(s).

3.

In the Audit group box, Field Add, Field Delete, Field Change are the available options

4.

Check the boxes to chose appropriate level of auditing

5.

click OK.
Now you can perform some online transactions that affect the Record Field in question and check if auditing is working as desired; remember only the
audit options you have chosen in the record field properties will be captured.
Sample query:
Lets consider we are going to audit the EMPLID field in PS_JOB record.
SELECT * FROM PSAUDIT WHERE RECNAME = PS_JOB AND FIELDNAME=EMPLID
Record level auditing
As the name suggests, record level auditing is the auditing mechanism enforced on a record.
Setting up Steps:

1.

Choose the Record

2.

Create the Audit Record - The Audit record is essentially a copy of the record being audited. The easiest way to create a copy of your
record is to do a Save As. Name the new record under standard record naming convention prefixed with AUDIT_

3.

Remove the unwanted fields

4.

An Audit record doesnt need keys, so remove them

5.

Add Audit Fields Insert the below fields (also known as audit fields) at the top of the new record in the below order
AUDIT_OPRID (Captures the User who performed an action)
AUDIT_STAMP (Captures the date and time when the action was performed)
AUDIT_ACTN (Captures the type of action performed)
AUDIT_RECNAME (Captures the name of the audited record definition. This field is used only when the same audit record is used for auditing multiple
records)

1.

On the Record Field Properties for AUDIT_STAMP, we need to check the Auto-Update checkbox. This is essential to correctly populate the
date-time stamp.

2.

AUDIT_ACTN can take up any of the below values based on the type of the action performed.
A Row inserted
D Row deleted.
C Row changed (updated), but no key fields changed.
K Row changed (updated), and at least one key field changed.
N Row changed (updated), and at least one key field changed.
In case of C and K the system writes old values to the audit table. While for N, the new values are written into the audit table.

1.

Build the audit record

2.

Open the Base Record that is to be audited. Open its properties. On the Use tab, under the Record Audit, specify the name of the audit
record that we just created as the Record Name. Choose Audit Options based on your requirement
Add An Audit table row is inserted when a row is inserted in the base record
Delete An Audit table row is inserted when a row is deleted from the base record
Change Audit table row(s) is inserted when a row changes in the base record
Selective Audit table row(s) is inserted when common field (present in both base record and audit record) changes
10. Based on the Audit option that you have chosen, perform some transaction that can trigger the audit. Now query the audit record and check for
new rows.
Record Level Audit vs Field Level Audit:
When you realize that you need to employ auditing in a certain situation, you have got to decide between Record level audit and field level

audit.

Record level auditing provides the option to chose from the delivered PSAUDIT record or a custom built audit record. But this is not the

case with Field level auditing; here PSAUDIT is your only option.
When you realize that you need to employ auditing in a certain situation, you have got to decide between Record level audit and field level

audit.

Based on the factors outlines above, it would be wise to choose Record level auditing when the situation demands the auditing of a number

of fields or a record as a whole. However, you always have another option in Field level audit when you are chasing just a filed or two.

Field Auditing
There are two types of delivered auditing in PeopleSoft:

Field level auditing

Record level auditing

Field level auditing tracks changes to one or more fields on a PeopleSoft record and stores the results in the
delivered PSAUDIT table.
Like record level auditing, field level auditing only applies to data updated through PeopleSoft and not directly through the database.
So auditing will not apply to data updated by SQL scripts, SQRs and COBOLs unless they are specifically designed to update the
audit table.

Enabling Field Level Auditing

To enable field level auditing, simply update the record-field properties of the relevant fields on the PeopleSoft record. For instance,
the following screenshot shows how to audit field add, change and delete, on the PROJECTNAME field
of PSPROJECTDEFN:

Testing Field level Auditing

Once enabled, make changes to the relevant field of the relevant PeopleSoft record online and confirm your changes are audited by
querying the table PSAUDIT.
The record PSAUDIT stores the old and new values of the field along with the audit action (e.g. A for Add, D for Delete and C for
Change). It also stores the record name and key fields of of row in the PeopleSoft record that was modified so that you can track back
to it. These are the values that appear in the fields KEY1KEY15.
So for example, if you had field level auditing enabled on the field LASTUPDOPRID of the
record PSPROJECTDEFN and the LASTUPDOPRID was changed, you would see:

The person that made the change (AUDIT_OPRID)

The date/time of the change (AUDIT_STAMP)

The audit action of change (C) (AUDIT_ACTN)

The record name of PSPROJECTDEFN

The field name of LASTUPDOPRID

The old value of LASTUPDOPRID before the change

The new value LASTUPDOPRID after the change

The project name (PROJECTNAME field) in KEY1 as this is the first (and only) key of
the PSPROJECTDEFN record.

Choosing Between Record or Field Level Auditing

Field level auditing is more cumbersome to track when you have many fields on a particular record being audited. This is where
record level auditing is more appropriate, particularly when you want to audit many or all changes on a record.
Record level auditing also uses its own audit table while field level auditing uses the delivered PSAUDIT record.
Essentially if you only need to audit one or a few fields, then use field level auditing. If you need to audit most or all of a record, then
use record level auditing.
application-designerauditingpeopletools

Audit Records
If you are creating an audit record, there are normally three fields that need to go at the start of the audit record (remember to use
the AUDIT_ prefix as described in the record naming conventions). These three fields will uniquely identify your audit data. They
are (in the order they should be put on the audit record):
1.

AUDIT_OPRID

2.

AUDIT_STAMP

3.

AUDIT_ACTN

The audit stamp field is a date/time field. However in order for it to be correctly populated, make sure that you set it to Auto-Update
so that it is automatically set to the correct date/time stamp.
If you are using the same audit record for multiple records then add the field AUDIT_RECNAME. Ensure that this is system
maintained and this will tell you which record the audit action relates to.
PeopleTools ver 8.45

To audit an already exisiting PeopleSoft record, we need to create a record definition and SQL table in which we store audit information. When creating
the audit record, remove any attributes such as
PARENT records, Query Security Records, and PeopleCode. The easiest way to create an audit table is to open the record definition of the base record that
you wish to audit. Save it as a new record, prefaced with AUDIT_.

Remove the all edit and key attributes from the newly saved record. Also remove any attributes such as
PARENT records, Query Security Records, and PeopleCode. Add to the top of the audit record the following three special audit-specific fields in the same
order given below.

AUDIT_OPRID
AUDIT_STAMP
AUDIT_ACTN
AUDIT_RECNAME

In most cases you should include AUDIT_OPRID, AUDIT_STAMP, AUDIT_ACTN. The AUDIT_STAMP must be given the attribute AUTOUPDATE. You might
also add AUDIT_RECNAME if you are creating an audit table to audit more than one record definition.

Make these fields required and keys. Then build the table. Make sure you can query this table using sql editor.

The purpose of each audit specific field is explained below.

AUDIT_OPRID Identifies the user who caused the system to trigger the auditseither by performing an add, change, or delete to an audited field.
AUDIT_STAMP Identifies the date and time the audit was triggered.
AUDIT_ACTN Indicates the type of action that the system audited. Possible actions include:

A: Row inserted.
D: Row deleted.
C: Row changed (updated), but no key fields changed. The system writes old values to the audit table.
K: Row changed (updated), and at least one key field changed. The system writes old values to the audit table.
N: Row changed (updated), and at least one key field changed. The system writes new values to the audit table.

AUDIT_RECNAME Identifies the name of the record definition that was audited.

The audit table does not have to include all the columns of the base table. In fact, for performance reasons, its best to only include those fields in your
audit record that are deemed

Open the record properties for the record you want to audit, Under the Record Audit, we have the following options

Record Name Specify the user-defined audit record.

Audit Options following are the audit options to choose for auditing the record.

Add Inserts an audit table row whenever a new row is added to the table underlying this record definition.
Change Inserts one or two audit table rows whenever a row is changed on the table underlying this record definition.
Selective Inserts one or two audit table rows whenever a field that is also included in the record definition for the audit table is changed.
Delete Inserts an audit table row whenever a row is deleted from the table underlying this record definition.

Now perform online transactions on the audited table, query the audit table to know what is changed and who changed it at what time.

7 Steps to Setup A Record Level Audit in PeopleSoft

0
inShare

Posted by Raja Palaniappan in PeopleTools | 15 Comments

As PeopleSoft maintains critical enterprise data, having an audit trail on critical data is of paramount importance. This post will help
you setup Record Level Auditing in 7 simple steps.

Record level Auditing

As the name suggests, record level auditing is the auditing mechanism enforced on aRecord. To set
up record level auditing, follow the steps below.

1. Choose the Record

Not all records in PeopleSoft need auditing. When there is such a business requirement, choose the record(s) that needs to be
audited.
2. Create the Audit Record
The Audit record is essentially a copy of the record being audited. The easiest way to create a copy of your record is to do a Save As.
Name the new record under standard record naming convention prefixed with AUDIT_
3. Remove the unwanted
An Audit record doesnt need keys, so remove them. The same rule goes with Related Language Records, Query security records
and PeopleCode. Also, remove all other fields that you are not interested in. Just remove them all.
4. Add Audit Fields
Insert the below fields (also known as audit fields) at the top of the new record in the below order
AUDIT_OPRID (Captures the User who performed an action)
AUDIT_STAMP (Captures the date and time when the action was performed)
AUDIT_ACTN (Captures the type of action performed)
AUDIT_RECNAME (Captures the name of the audited record definition. This field is used only when the same audit record is used
for auditing multiple records)

Audit Fields

On the Record Field Properties for AUDIT_STAMP, we need to check the Auto-Update checkbox. This is essential to correctly
populate the date-time stamp.

Auto Update property

AUDIT_ACTN can take up any of the below values based on the type of the action performed.
A Row inserted
D Row deleted.
C Row changed (updated), but no key fields changed.

K Row changed (updated), and at least one key field changed.

N Row changed (updated), and at least one key field changed.
In case of C and K the system writes old values to the audit table. While for N, the new values are written into the audit table.
5. Build the audit record
Your Audit record must be a Database record and you should be able to access it using Query.
6. Link them up
Open the Base Record that is to be audited. Open its properties. On the Use tab, under the Record Audit, specify the name of the
audit record that we just created as the Record Name. Choose Audit Options based on your requirement.

Audit Record Mapping

Add An Audit table row is inserted when a row is inserted in the base record
Delete An Audit table row is inserted when a row is deleted from the base record
Change Audit table row(s) is inserted when a row changes in the base record
Selective Audit table row(s) is inserted when common field (present in both base record and audit record) changes
7. Test the Auditing
Based on the Audit option that you have chosen, perform some transaction that can trigger the audit. Now query the audit record
and check for new rows. Try to infer the meaning of each row that got added.
A delivered page to test this is the Department page. Navigate to Set Up Financials/Supply Chain > Common Definitions > Design
ChartFields > Department. Add a new value.

SELECT * FROM PS_AUDIT_DEPT;

Examine the audit rows.
Thats it on Audit Records in PeopleSoft!

Tags: Audit, PeopleSoft Tutorials, Records, Security

Hi Vera,

While migrating the project from dev to tst, click the Options button in the Copy Database dialog. This will take you to the Upgrade Options settings.
Here, on the General options tab, select the Set Target Audit Flags from Source option in the Audit Flags on Records settings.

Click OK and proceed with the migration.

In 9.1 we also have a delivered audit logging feature which can track most of the commonly used transaction tables.
Common Definitions> Audit Logging