Configure auditing

Use the Configure Auditing step in the Create a Class wizard to add, modify, or delete an audit definition. The audit definition specifies the events that trigger an audit entry, whether to record the original and modified state of the object, and an optional filter expression that determines whether the event is audited.

The configured audit definitions are displayed in the audit definition table. To work with audit definitions, select one of the following options:

Event
The type of event being audited. For a complete list of the events that can be audited for each class, see Auditable objects and events.
Type or Audit: Success, Failure
Determines what outcomes are audited for each event. You can audit successful events, failed events, or both.
Apply to Subclasses
Whether the selected audit definition is applied to all subclasses of the current class.
Is Enabled
Indicates whether the audit definition is enabled or disabled.
Inherited?
Whether the selected audit definition is inherited from a parent class.
Object State Recording Level
Specifies whether to include a snapshot of the object in the audit log. You can use snapshots to review the state of an object before and after an event. The original, pre-event object provides a snapshot of the permissions, properties, and content of the object before the event occurred. The modified, post-event object reflects the state of the object after an event. By default, the modified and original objects are not saved in an audit entry.

Snapshots use a lot of database space, so consider your storage resources before including snapshots. As an alternative, consider auditing the specific properties you are interested in. See Configuring auditing for a property for more information.

Display Name
Identifies the client application that processes the audit log. The property identifies a set of audit definitions for a given client or client function. Specify a unique value to distinguish one client application from another.
Filter Expression
Optional. Holds an expression that is evaluated against the source object, or an object referenced by an event source object, to determine whether the event is audited. For example, a filter expression can test if a property on the source object has changed; if not, the event is not audited. Filter expressions are applied only for successful operations. The expression uses the same format as the WHERE clause of a query; however, only a subset of the operators is supported. Filter expression examples:

TIP The creation event is triggered when you add a new document or when you check out an existing document. You can when a new document is added and exclude checkouts, as either a minor or a major version, by using the following filter:

((MajorVersionNumber=1 and MinorVersionNumber=0 and VersionStatus=1) or (MajorVersionNumber=0 and MinorVersionNumber=1 and (VersionStatus=2 or VersionStatus=3)))

Filter Property
Optional. Specifies the symbolic property name, which must be a singleton object-valued property of the source object. If the filtered property is specified, the filter expression applies to the object that the filtered property references, rather than the source itself. For example, when auditing a creation event on a Referential Containment Relationship object, you can specify property name "Tail" as the filter property. The Tail property represents the referential containment relationship container. By specifying the filter property, the filter expression is evaluated against the object referenced by the filter property, that is, the container rather than the referential containment relationship. For instance, you can specify auditing to take place only when the container has a title = "accounting".

If an invalid symbolic name is provided, the filter expression is ignored and has no effect on auditing.

There are two situations in which using the filter property is useful: