Audit trails

Some records may be considered so sensitive that you want to keep a record of all changes made to them. A record of all changes that were made to a record is called an audit trail.

These are the most common reasons for wanting an audit trail.

Users with legitimate access to records may be tempted to do something dishonest. This often happens when the records in question are used to represent money or other things that are worth money.
There is an undesirable legal consequence if an improper change to, or action on, a record is performed.
There is a regulation or standard that requires your company to track changes to records.

If any of these concerns is relevant to a record, it is important to have an audit trail that tells who did what to each such record and when they did it. Having an audit trail is a disincentive for dishonesty, because it makes it easier to discover dishonest actions. An audit trail removes speculation about what actually happened.

An audit trail is an historical record of everything that happened to a record. Because it is an historical record, the information that is in an audit trail cannot be altered or deleted.

There are two main reasons for not wanting an audit trail:

Maintaining an audit trail increases the amount of time that an operation takes. Saving the audit records takes additional time.
Maintaining an audit trail can greatly increase the amount of storage that an application uses. In addition to needing space to store records, you need space to store the audit trail. The space that is needed to store the history of everything that ever happened to a record can be significantly larger than the record itself.

Support for audit trails is built directly into the IBM TRIRIGA Application Platform. Though it is possible to implement audit trails as part of an application's business logic, IBM® TRIRIGA® strongly suggests that you use the audit trail support that is built into the platform. There are at least three reasons for this:

An audit trail that is maintained by the platform is more secure than an audit trail maintained by the application. An audit trail based on an application's business logic is only as reliable as the application itself. If there are bugs or mistakes in the application, an audit trail that is maintained by the application may not be accurate. The accuracy of an audit trail that is maintained by the built-in audit trail mechanism is unaffected by bugs or mistakes in an application.
It takes a lot more work to build the logic for an audit trail into an application than it does to use the audit trail support that is built into the platform.
Although all audit trail mechanisms increase the amount of time it takes an application to do things, an audit trail that is maintained by the platform's built-in mechanisms has less impact on performance than an audit trail that is maintained by an application.

You set the options for maintaining an audit trail for records that are created from a business object by setting the relevant properties of the business object with the Data Modeler.

The following properties of a business object control the generation of an audit trail for records that are created from the business object.

Audit Actions

If the Audit Actions check box is selected, when a user clicks a sub action in a form that is editing a record that is created from this business object, an audit record is created.

Selecting the Audit Actions check box enables the creation of audit records that identify the sub action that was performed, the user ID of the user that clicked the sub action, and when the sub action was clicked. Selecting the Audit Actions check box only enables the generation of audit records for sub actions that you specify should be audited by selecting their Log check box. For audit records to be generated for a particular sub action, the Log check box in the sub action's properties must be selected.

Select the Audit Actions check box for the Request for Information (RFI) metrics and for reports in IBM TRIRIGA Workplace Performance Management products.

Audit Access

If the Audit Access check box is checked, every time a user utilizes a form to view the contents of a record that is created from this business object, an audit record is created.

Audit Interactive Data

If the Audit Interactive Data radio button is selected, every time a user uses a form to change the contents of a record that is created from this business object, an audit record is made. The audit record contains the user ID that made the change and the time of the change. The audit record also contains the old value and new value of every changed field.

Audit All Data

If the Audit All Data radio button is selected, an audit record is made for every change to a record created from this business object. This includes changes that are made by a user in a form, due to a formula calculation or rollup calculation, or by a workflow. This does not include changes that are made if the record is modified by an editable query.

Selecting the Audit All Data property can affect performance.

Require Explanation

If the Require Explanation check box is selected, when a user uses a form to change the contents of a record that is created from this business object, the user is asked to enter a reason. If the Require Explanation check box is selected, the Audit Interactive Data property is automatically selected.

The reason that is given for the changes to the record is included in the audit record along with the other information about the change.

Whether you are creating a new sub action or editing it, after you click the appropriate action you check the Log check box to enable auditing of the sub action.

Configuring the generation of audit records is only half of the IBM TRIRIGA Application Platform's built-in mechanism for maintaining an audit trail. The other half is a mechanism for viewing audit records.

If a form is used to edit records for which audit records are generated for data access or changes, you need to update that form to show the Audit tab. To do so, revise the properties of the form for the business object where you would like to see the audit data and check Show Audit Actions.

After the form is published, the form has a tab that is labeled Audit. The purpose of the Audit tab is to display all the audit records that contain data changes that were made to the record.

Three columns display in an Audit tab.

Modified By: The user ID that made the changes.
Comment: The reason the user entered if required to enter a reason for making changes to a record through a form.
Modified On: When the data was changed.

Tip: You may not want all users to see the information in the Audit tab or the Audit Actions tab. Access to those tabs is controlled through group permissions, just like any other tab.

To see details of the data changes that were made, click the hyperlinked audit record. The Audit Details form shows the user that made the change, the name of the field that was changed, the value of the field before it was changed, and the value of the field after it was changed. If changes were made while the record was created, the fields had no previous value, and the old value is blank.

If a form is used to edit records for which audit records are generated as a result of clicking sub actions, the form has an Audit Actions tab. The purpose of the Audit Actions tab is to display the audit records generated to record actions that were performed on the record.

The Audit Actions tab shows every recorded sub action that was clicked in the record. The Audit Actions tab shows the label of the sub action, the user that clicked the sub action, and when the sub action was clicked. To allow a user to view this data, you need to update that form to show the Audit Actions tab. To do so, revise the properties of the form for the business object where you would like to see the Audit data and check Show Audit Actions.