History sets

The system generates history set records when a user requests to view an audited record's history.

If the record is on an audited table, a history set is generated when the record is inserted. A user must view a record for the system to create or update a history set for that record.

Note: Do note use history sets to generate reports.

Viewing history sets

There are two ways of viewing the history set, accessible through the Context Menu action History.


The history calendar shows you the days a record was changed and by whom.

In this view, you can:

  • Highlight changes to a particular field by selecting the field from the Highlight changes to field selection box. Hover over the text of one of a highlighted change to see the change in value.
  • Hover over the icon within an entry to view a popup displaying all the value changes.
  • Click the day number to get a view of the changes for that day.
  • Click the week number to the left to get the week view. You can scroll to and from month-to-month to see changes.
Figure 1. View Calendar Changes

The history list displays each change as its own row in the change list.

To view a history list, the following requirements must be met.

  • Auditing: Auditing for the table must be enabled to view a history list.
  • ACLs: By default, the List history option is only available to users with the admin user role. To enable this option to non-admins, create a custom ACL rule granting read access to the Record History [sys_history_set] table.
  • Roles: At least one of the roles that the user has must be included in the glide.history.role property, which includes the itil role by default.
Figure 2. View History List

Click a row item to view additional details about the change.

List view fields

Table 1. List View Record Fields
Field Input Value
ID A Document ID for the record whose history is being recorded.
Table The audited table for the record whose history is being recorded.
Load Time The amount of time it took to generate the history set.
Table 2. Audit History Record Fields
Field Input Value
Label The label of the field which was changed.
Old The value before the change.
New The value after the change.
Type Indicates if the entry is for a normal field, an email record, or a relationship change record.
Update Number The number of times this field has been changed. A value of -1 indicates when the record was created or deleted.
Update Time The date and time of the change
User Name The name of the user who created the change.

Tracking inserts, references, and relationships

History sets can also track changes to references, inserts, and relationships.

Tracking changes to reference fields

Since reference fields only store an ID value, the system can normally only audit changes when the ID value changes. By default, the system does not audit changes when a reference field display value changes.

Consider the following situation. A user changes her name from Jane Smith to Jane Miller. Since the user name is the display value for the User table, any previous reference to Jane Smith instead refers to Jane Miller. If the administrator just updates the name of the existing user record, audit and history records will only display the new name Jane Miller. By default, the system does not provide a way to distinguish between changes made under the original user name versus those made with the new user name.

If your auditing policy requires tracking user name changes, you can:
  • Create a new user record for the new name and deactivate the previous user record. The system preserves audit records for the old user name and creates future audit records with the new user name.
  • Create custom fields and a business rule to save the previous name and the date of the name change. The system can use this information to construct the proper names in audit and history records.
Tracking inserts

By default, the system does not create Audit records for inserts because in a typical instance, inserts can account for over 80% of the size of the Audit table.

Not tracking inserts allows for better performance and a much smaller Audit table. Administrators can enable auditing of inserts by setting the glide.sys.audit_inserts property to true.

Tracking CI relationships

Changes to a CI relationship (CI Relations, CI/User Relations, or CI/Group Relations) appear in the history of the items on both sides of the changed relationship regardless of whether the change was manual or a result of Discovery.

For example, if the computer alpha has a used by CI Relation with the computer beta, then the history for alpha has a record of when the relationship with beta was established, and likewise, the history for beta has a record of when the relationship with alpha was established. This example illustrates the history displayed when some CI Relations are established, and then one of the relations is removed:

Figure 3. CI Relationship History

The created bullet indicates the date that the CI, user, or group was created. The last activity bullet refers to when the relationships were last changed. If you don't want to show CI relationship history for any or all CI relationship types, you can turn it off by disabling auditing on the CI relationship tables (CI Relationship [cmdb_rel_ci], CI/User Relationship Type [cmdb_rel_user_type], or Group Relationship [cmdb_rel_group]).