The History field is a special embedded table data type that is automatically generated for new tables. This field type creates date- and user- stamped history records of all edits and events that occurred in a record, in order to maintain a history of everything that happens in the system. This is a critical resource for storing data that is used by reports and rules and should never be deleted. In addition, history provides a full audit trail of all changes made to a record with snapshot capability that shows what a record looked like after any set of changes.

Since the history field is included and added to the Table wizard and record layout by default, you cannot add a second history field.

Since the History database table can end up being very large, sometimes exponentially larger than the source tables being reported on, space usage is an important design consideration. By default, the system stops creating new History entries after any single time-based rule makes more than 100 tracked changes to a record. This prevents the KB from exhausting disk space as a result of a rule updating records too frequently. If you have access to the Admin Console, you can change this number or disable this behavior if necessary by editing the Max History Size global variable.

Viewing Record Histories

To see past changes and versions of a record:

1. Go to the History tab in a record and navigate between the items in the History Events section. 
2. Click the look-up icon next to any item. This opens the History Details screen for that change.
   
3. Click View [Record] After Change to see details about that specific modification. For example, if a record change was triggered by a rule due to another record's modification, History displays the table and record IDs that triggered the record change as clickable links.
   

Tracking Field History

By default, history is tracked for all new fields. When a field's history is tracked:

• Any update to that field creates a history entry
• That field's contents are included in every history entry
• That field's contents are visible to everyone with permission to view the History field, even if they don't otherwise have permission to view the field

Tracking too many extraneous fields can quickly take up a lot of storage because not only are more history entries being created, but each entry contains more information. Choosing the right fields to track is important for maintaining a reasonable balance of storage use and detailed audit trails.

You can stop tracking history for certain fields, but this means:

• That field is not included in history entries or History Details screens, making it difficult to trace past changes to records
• If you click View [Record] After Change from History Details, the field's value is shown as "Not tracked" or "No records"
• The Advanced Search drop-down field list no longer includes the field
• The field is no longer available in saved searches that use the History field
• If the field is used in saved searches, actions, or rules, this is included in Integrity Manager reports

Common Field Selections

There are some fields in a table that never change and can potentially be removed from the History record, such as Created By, and Demo Data. ID and Date Created also don't change, but they should never be removed from history because of their use in linking history entries to records, and their use in reporting, respectively.

Certain field types should also be handled carefully to avoid storing unnecessary data:

• Linked fields: In linked field sets, choose representative fields rather than the entire linked set. For example, you might select the ID and fields used in advanced filters, but not select the other ten fields in the set. Because all the fields in the set update at the same time, you rarely need to track them all.
• Append Only fields: These take up a lot of space to track, but they're commonly used in rules, email actions, and other automation. If you need to stop tracking an Append Only field to reduce space usage, consider making the field view-only and adding a separate input field. For example, add a Working Note text field with a rule that adds any Working Note value to the Working Notes Append Only field and then clears the Working Note text. However, be aware that this creates duplicate history entries, since the input field is changed once by the user and then again by the rule that clears the text.

Configure Field History Tracking

To change how fields are tracked in history:

1. Go to Setup [Table] > Fields and edit the History field.
2. Go to the Options tab and select the appropriate setting:
   • All fields: Every field in the table prompts history entries when edited, and is included in history entry data whenever an entry is created. Be cautious with this setting, as it not only creates the largest possible history entries, but it also creates history entries every time any field is changed.
   • Selected fields: Only selected fields prompt history entries when edited, and history entries contain data only for selected fields. Other fields are shown as "Not tracked" in history entry snapshots. Click the magnifying glass to select the fields you want to track. If you remove a field that was previously tracked, past data for that field is removed to save space, but past history entries are retained even if they were triggered by a change to that field.
3. When a tracked field is edited, that field's name is listed in the History field. If you want to also show the new value for any tracked fields, select those fields in the "Show the new value" selection list. Select at least one field from the list.
   

4. Choose whether to automatically add new fields to the list of selected fields. Due to the potential size of History tables, selecting this option can cause major database load issues, since the field has to be added to every history record for the table. To minimize database workload, especially if you need to add more than one new field to the table, clear the "Auto-add new fields to History" checkbox while you're working and then select it again outside of working hours.

   During the implementation phase, when lots of history entries are created and periodically cleared out, you can grant select users the permission to modify the History field by going to the Field Permissions tab of the Table Permissions wizard. This permission should be granted only to admins, and revoked when the system moves into production. For instance, you might set up an admin-level timed rule that deletes previous history records, so the history of the record doesn't weigh down the updates for timed rules.

5. Choose when to create a history entry:

   • Only when at least one field tracked by history is changed. This restricts history entries to only those that affect tracked fields. Note that this does not apply to rules that are configured to always or never record history entries. If you choose this option, you can also select one or both of the following:
     • Exclude changes to Date Updated only. If Date Updated is a tracked field, you can use this option to prevent history entries whose only recorded change is Date Updated. For example, if a user edits a record and saves it, then opens it the next day and only clicks Save, this prevents creation of a history entry that reflects the date change only.
     • Exclude changes to the Updated By linked set only. If Updated By is a tracked field set, you can use this option to prevent history entries whose only recorded change is Updated By. For example, if a user edits a record and saves it, then a different user opens it and only clicks Save, this prevents creation of a history entry that reflects only the second user's information.
   • Whenever a record is saved. This creates history entries whenever the record is saved for any reason.

6. Save your changes.

Tracking Rules Updates

In addition to the settings in the History field of a specific table, rules have their own settings for how their changes are tracked in history entries. When you create rules, you can prevent them from appearing in history entries at all, or you can include an action in the rule that deletes all history entries created by the rule that are older than X days.

If you need to troubleshoot a large amount of history entries, it's important to understand the interaction between History field settings and rule settings. If your History field is set to record a history entry "Whenever a record is saved," the system evaluates the rule's settings and creates a history entry accordingly. If your History field is set to record a history entry "Only when at least one field tracked by history is changed," that setting is considered in addition to the settings of the rule when the system determines whether to create a history entry.

Cells are highlighted in blue when a rule results in the system checking the History field settings.

Always record history entries

This matrix assumes the History field is set to "Only when at least one field tracked by history is changed" and the rule is set to "Always record history entries." Review each intersection to see how rule modifications determine when history entries are created.

Only record history entries when record is modified by actions called by the rule

This matrix assumes the History field is set to "Only when at least one field tracked by history is changed" and the rule is set to "Only record history entries when record is modified by actions called by the rule." Review each intersection to see how rule modifications determine when history entries are created.

Do not record history entries

When the rule is set to "Do not record history entries," history entries are never created by the rule, and the History field settings are ignored.