Auditing & Archiving | ServiceNow CSA Part 4

Section 1

Field-Level Auditing

Auditing in ServiceNow records field-level changes so you have a complete, immutable history of who changed what and when. This is critical for compliance, security investigations, and change tracking.

The sys_audit Table

All audit records are stored in the sys_audit table. Each row in sys_audit represents a single field change on a single record.

tablename

The name of the table whose record was changed.

Example: incident

fieldname

The name of the specific field that changed.

Example: state

oldvalue

The value of the field before the change was saved.

Example: 1 (New)

newvalue

The value of the field after the change was saved.

Example: 2 (In Progress)

sys_created_on

Timestamp of when the change occurred (audit record creation time).

sys_created_by

The username of the user who made the change.

Example: john.smith

Enabling Auditing

Auditing is not enabled by default for all fields and tables. It must be explicitly turned on at either the table level or the individual field level.

Level	How to Enable	Effect
Table-level	Open the Table record → set the Audit field to true	Audits all fields on the table that have auditing turned on at the field level
Field-level	Open the Dictionary entry for the field → check the Audit checkbox	Tracks changes to that specific field only (table auditing must also be on)

Exam Must-Know: Both the table and the field must have auditing enabled for a change to be recorded in sys_audit. Enabling auditing on a table alone does not automatically audit every field — each field's Dictionary entry must also have the Audit checkbox checked.

Navigation Path: To enable auditing on a table, go to System Definition > Tables, open the table record, and toggle the Audit field. To enable on a specific field, go to System Definition > Dictionary, find the field's entry, and check Audit.

Viewing Audit History on a Record

Once auditing is enabled, there are two ways to view the change history for a specific record:

The History related list on the record form — shows a user-friendly chronological view
Querying sys_audit.list directly and filtering by documentkey (the record's sys_id)
Using a History Set — a grouped, formatted audit view (see Section 2)

Immutable Audit Trail: Audit records in sys_audit cannot be edited or deleted by normal users. This immutability is what makes the audit trail trustworthy for compliance purposes. Even admins cannot modify audit records through the standard UI.

Section 2

Record History & History Sets

While sys_audit stores raw audit data, History Sets provide a human-readable, structured view of record changes organized for easy interpretation.

Tables Involved

sys_history_set

The parent record for a History Set — one per tracked record. Links to the source table and record sys_id.

sys_history_line

Individual history line items within a History Set. Each line represents one field change event at a point in time.

sys_audit

The raw, low-level audit table that stores every field change. History Sets draw from this data to build their user-friendly views.

History Sets vs. sys_audit — Key Differences

Aspect	sys_audit	History Sets
Purpose	Raw, immutable audit log of every field change	User-friendly grouped view of changes
Tables	`sys_audit`	`sys_history_set` + `sys_history_line`
Grouping	Individual rows per field change	Changes grouped by save transaction
Target audience	Developers, administrators querying data	End users and agents reviewing record history
Access path	Direct table query or `sys_audit.list`	"History" tab / related list on the record form
Prerequisite	Auditing enabled on table + field	Auditing must be enabled on the relevant fields

Exam Trap — History Requires Auditing: History Sets do not independently track changes. They are a view built on top of sys_audit data. If auditing is not enabled on a field, that field's changes will not appear in the History tab — even if History Sets are configured.

Viewing the History Tab: On any record with auditing enabled, scroll to the related lists section at the bottom of the form and look for the History related list. Each entry shows the timestamp, user, and the before/after values of all changed fields in that save transaction.

Section 3

Session Logging & System Logs

ServiceNow maintains several types of system logs that capture application activity, errors, and transaction data. Understanding which log lives in which table is a frequent exam topic.

The syslog Table

The primary application log table is syslog. Navigate to it at System Logs > Application Logs or type syslog.list in the filter navigator.

Log Levels

DEBUG

Lowest level — verbose diagnostic output for development. Not shown in production by default.

INFO

Informational messages about normal application events.

WARNING

Potential issues that don't prevent execution but warrant attention.

ERROR

Errors that impact functionality but don't crash the system.

CRITICAL

Highest severity — system-level failures requiring immediate attention.

Application Logging API

Server-side scripts write to the syslog using GlideSystem (gs) methods. These entries appear in System Logs > Application.

// Write to syslog at different levels
gs.log('This is a general log message');        // INFO level
gs.info('Record created successfully');          // INFO level
gs.warn('Fallback logic triggered');             // WARNING level
gs.error('Failed to retrieve user record');      // ERROR level

// All of these are visible at: System Logs > Application

Exam Fact — gs.log() Destination: gs.log() writes to the syslog table, visible at System Logs > Application. This is the correct answer when asked where application script log messages appear. Do not confuse with the transaction log or node log.

Other Log Types

Log Type	Table / Location	What It Contains
Application Log	`syslog` — System Logs > Application	Messages written by gs.log(), gs.info(), gs.warn(), gs.error() in server-side scripts
Transaction Log	System Logs > Transactions	Every HTTP transaction (page load, form save, API call) — timing, user, URL, response code
Node Log	System Diagnostics > Node Log	Server-level JVM output, node startup/shutdown, infrastructure errors
Slow Queries Log	System Logs > Slow Queries	Database queries that exceeded the slow query threshold — performance tuning tool

Section 4

Security Incident Response & Login Tracking

ServiceNow tracks authentication events, failed access attempts, and security incidents at the platform level. This data is critical for security investigations and compliance reporting.

Login Failure and Account Lockout Tracking

Failed login attempts are tracked in the syslog table with a source of login
When the High Security Plugin is enabled, account lockout policies activate after a configurable number of consecutive failures
Locked-out users can be identified in User Administration > Users — look for the Locked out checkbox on the user record
Admins can unlock users by unchecking the Locked out field and saving the user record

Failed ACL Attempt Logging

High Security Plugin Required: Detailed logging of failed ACL attempts (recording which ACL denied a user and why) requires the High Security Settings plugin to be activated. Without it, denials are silently enforced without being written to a log.

Security Incident Response (SIR)

The Security Incident Response (SIR) application is a separate ServiceNow product/plugin. When installed, it adds dedicated tables and workflows for managing security incidents.

sys_security_incident

The primary table for security incidents when the SIR application is installed. Separate from the standard incident table used by ITSM.

Scope

SIR is beyond the CSA exam scope — awareness that it exists as a separate app/table is sufficient. The CSA focuses on platform-level auditing, not SIR workflows.

Section 5

Archiving

Archiving moves old records from active tables to shadow archive tables, keeping the active table performant while preserving data for compliance and reference. This is fundamentally different from deletion.

Archive vs. Delete — Critical Distinction

Aspect	Archive	Delete
Data preserved?	Yes — moved to an archive table	No — permanently removed from the database
Recoverable?	Yes — can be restored to the live table	No — not recoverable through normal means
Visible in normal lists?	No — hidden from standard list/form views	No — not present at all
Table location	`u_archive_[tablename]`	No table — gone
Schema preserved?	Yes — archive table mirrors source table schema	N/A
Use case	Compliance retention, performance optimization, keeping old closed records	Removing truly unwanted or duplicate records

Exam Must-Know — Archive Destination: Archived records are moved to a table named u_archive_[original_table_name]. For example, archiving incidents moves records to u_archive_incident. The archive table has the same schema as the source table. Records in the archive table are hidden from standard views but can be accessed directly or restored.

Archive Rules — sys_archive

Archive rules define which records get archived, when, and from which table. They are stored in the sys_archive table.

Archive Rule Field	Purpose	Example
Table	The source table to archive records from	`incident`
Condition	Filter that identifies which records qualify for archiving	`state=7 AND resolved_at < javascript:gs.daysAgoStart(365)`
Active	Whether the archive rule runs on its schedule	`true`
Archive store	Destination — always the corresponding `u_archive_*` table	`u_archive_incident`

Restoring Archived Records

To restore records from an archive back to the live table:

Navigate to System Archive > Archive Rules
Open the relevant archive rule
Use the Restore related list or function on the archive rule record
Select the records to restore and confirm — they are moved back to the source table

Exam Fact — Restore Path: To restore archived records, the correct path is through Archive Rules > Restore function. You do not directly edit or move records in the u_archive_* table — the restoration process handles the move back to the live table automatically.

Section 6

Data Retention

Data retention policies govern how long audit records and other system data are kept before being purged. This is primarily driven by compliance requirements (GDPR, SOX, HIPAA, etc.).

Audit Record Retention

Retention policies define how long records in sys_audit are kept
The sys_audit_delete scheduled job automatically removes audit records that exceed the defined retention period
Retention periods are typically defined by your organization's compliance requirements, not set by ServiceNow defaults
Common retention drivers: GDPR (EU data protection), SOX (financial audit trails), HIPAA (healthcare records), PCI DSS (payment data)

sys_audit_delete Job

A scheduled job that scans sys_audit and removes records older than the configured retention period. Runs on a defined schedule to keep audit table size manageable.

Compliance Drivers

Regulatory frameworks often mandate minimum retention periods. For example, SOX may require financial change audit logs to be kept for 7 years. These requirements drive retention policy configuration.

Retention vs. Archiving

Retention policies apply to audit records in sys_audit. Archiving applies to business records (incidents, changes, etc.) in operational tables. They are separate mechanisms with separate configurations.

CSA Exam Scope: For the exam, know that retention policies control how long audit records are kept, that the sys_audit_delete job purges old audit records, and that compliance requirements drive retention periods. Deep configuration knowledge is not required at CSA level.

Section 7

Transaction Log, Active Sessions & Instance Health

ServiceNow exposes several tools and views for monitoring instance health, active sessions, and transaction performance. These are primarily admin and platform diagnostic tools.

Key Tables and Views

Table / View	Purpose	Navigation
`syslog`	Application log entries from gs.log() and platform events	System Logs > Application
`v_transaction`	Virtual view of currently active sessions and in-flight HTTP transactions on the instance	System Diagnostics > Sessions
stats.do	Instance health page — thread status, memory usage, active users, database pool stats. Admin-only access.	Navigate to: `[instance].service-now.com/stats.do`

stats.do — Instance Health Page

The stats.do page is a platform diagnostic page accessible only to admin users. It provides a real-time snapshot of instance health metrics.

Thread Status

Shows active threads processing requests, waiting threads, and thread pool utilization. Useful for identifying processing bottlenecks.

Active Users

Count of users currently logged into the instance with active sessions.

Memory Usage

JVM heap memory utilization — used vs. available. High memory can indicate memory leaks or undersized instance.

Database Pool

Database connection pool stats — active connections, idle connections, wait time. Helps diagnose DB performance issues.

CSA Exam Note: Know that stats.do is the instance health page, accessible only to admins, showing thread status, active users, and memory usage. You do not need to interpret the raw output for the CSA exam — awareness of its existence and purpose is sufficient.

v_transaction — Active Sessions

The v_transaction view shows active HTTP transactions currently being processed by the instance. It is a virtual (not stored) view refreshed in real time.

Shows: session ID, user, URL being accessed, time elapsed, thread state
Useful for identifying stuck transactions, runaway scripts, or heavy users
Admins can terminate stuck sessions from this view
Navigate to: System Diagnostics > Sessions or type v_transaction.list

Section 8

Key Exam Facts & Common Traps

This section consolidates the highest-priority exam facts for auditing and archiving. These points are the most commonly tested and the most common source of wrong answers.

Fact 1 — Auditing is not on by default: Field-level auditing must be explicitly enabled. It is not turned on by default for all fields. The table's Audit flag must be true AND the individual field's Dictionary entry must have Audit checked. Missing either one means no audit record is generated.

Fact 2 — sys_audit tracks CHANGES, not views: The sys_audit table records field value changes only. It does not track when a user reads or views a record. If you need to track who viewed a record, that requires a separate custom mechanism (not part of standard platform auditing).

Fact 3 — Archive moves records, does not delete: When an archive rule runs, records are moved from the source table to the u_archive_[tablename] shadow table. They are not deleted. They remain in the database, just inaccessible from standard views.

Fact 4 — Restoring archived records: The correct path to restore archived records is through Archive Rules > Restore function. You do not manually insert records back into the live table. The platform handles the move using the archive rule's restore capability.

Fact 5 — gs.log() writes to syslog: Application script log messages written with gs.log(), gs.info(), gs.warn(), and gs.error() all write to the syslog table. They are visible at System Logs > Application. This is the expected exam answer for "where do script logs appear?"

Fact 6 — History Sets require auditing: The History tab on a record is populated from sys_audit data. If auditing is not enabled on a field, that field will not appear in the History tab even if History Sets are configured. Auditing is the prerequisite, not History Sets.

Fact 7 — Audit records are immutable: Records in sys_audit cannot be edited through normal platform mechanisms. This immutability is intentional — it ensures the audit trail is trustworthy and cannot be tampered with. Even admin users cannot modify audit records via the standard UI.

Fact 8 — Archive table naming convention: Archive tables always follow the naming pattern u_archive_[source_table_name]. For the incident table, the archive table is u_archive_incident. The archive table has the same schema as the source table (same columns, same field types).

Quick Reference — Auditing & Archiving Tables

Table / Object	Purpose	Key Fact
`sys_audit`	Raw field-change audit log	Immutable; requires auditing enabled on table + field
`sys_history_set`	Parent of a History Set grouping	One per tracked record; user-friendly audit view
`sys_history_line`	Individual history line items	Child of sys_history_set; one row per field change event
`sys_archive`	Defines archive rules	Contains condition, table, schedule for archiving
`u_archive_*`	Archive shadow tables	Same schema as source; records hidden from normal views
`syslog`	Application + platform log	Destination for gs.log() / gs.info() / gs.warn() / gs.error()
`v_transaction`	Active session/transaction view	Virtual view; real-time; admin diagnostic tool

Putting It All Together — Audit Trail Flow:

Admin enables auditing on a table (Table record → Audit = true)
Admin enables auditing on specific fields (Dictionary entry → Audit checkbox checked)
User saves a record → changed fields are written to sys_audit
History Sets read sys_audit data → visible as the History tab on the record
Retention policies + sys_audit_delete job purge old audit records per compliance rules
Archive rules move old closed records to u_archive_[table] to keep live tables lean
Restored records are moved back to the live table via the Archive Rules restore function