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. Calendar 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 List 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]). Control access to historyYou can give a role access to view audit history by setting a system property.Change the number of history entriesBy default, the history displays a maximum of 250 history entries, but you can change this value.History TimelineYou can view a timeline of changes for a CI and for its related records, relationships, baselines, and proposed changes for the CI. Timelines are available for CIs in the Configuration Item [cmdb_ci] table or a descendant of this table, if auditing is enabled for the tables.