› CIS-DF Hub › Part 8 › Archiving, Purging & Data Retention
⬡ Part 8 · Topic 3

Archiving, Purging & Data Retention

Data grows indefinitely without governance. ServiceNow's Archive and Purge frameworks let you move old records out of active tables and eventually delete them — keeping the instance performing well while meeting compliance retention requirements.

📋 4 sections ⏱ ~15 min read 🎯 ~6% exam weight 🏷 Archiving · Data Retention · Governance
Section 1

Why Archive and Purge?

A ServiceNow instance that never deletes old data will eventually slow down. Queries scan millions of old resolved incidents. Lists take longer to load. Reports time out. Storage costs increase. Archiving and purging are the tools to manage this growth.

The two processes serve different goals:

  • Archiving — move old records from active tables to archive tables. The records still exist and can be searched, but they don't impact active list performance.
  • Purging — permanently delete records. Used to enforce compliance retention limits (e.g., "GDPR requires deleting PII after 7 years") or to reclaim storage.
Section 2

Archive Rules

An Archive Rule (stored in sys_archive) specifies:

  • Table — which table to archive from (e.g., incident)
  • Condition — filter for records to archive (e.g., state=Closed AND closed_at older than 2 years)
  • Archive table — where records move (automatically named ar_archive_incident or similar)
  • Schedule — when the archive job runs

How Archived Records Work

After archiving, the record no longer appears in standard list views of the source table. To find archived records:

  • Navigate to the source table list view → click the Archive toggle in the column header (or use the "Show Archived" button)
  • Search the archive table directly: ar_archive_incident
  • Archived records are read-only — you cannot reopen an archived incident
⚠
Exam Trap — Archived Records Are Still in the Database Archiving does NOT delete records. They move to an archive table and are still accessible (with the right permissions). Archiving improves performance by removing old records from active tables, but does not fulfill deletion/purging requirements. For actual deletion, you must configure a separate Purge Rule.
Section 3

Purge Rules

A Purge Rule permanently deletes records. It can target:

  • Records in the active table directly (dangerous — records are deleted without archiving first)
  • Records in archive tables (safer — archive first, then purge after a longer retention period)

The recommended pattern is: Archive → Purge from archive after retention period. This gives a recovery window between the two operations.

1
Archive Phase
Record Meets Archive Condition → Moved to Archive Table
The Archive Rule's condition is met (e.g., resolved_at > 3 years ago). The record is moved from the active table (incident) to the archive table (ar_archive_incident). It no longer appears in standard list views but remains queryable and retrievable.
2
Retention Window
Record Sits in Archive for Retention Period
The record is held in the archive table for the configured retention period (e.g., 5 years for regulatory compliance). During this window it can still be retrieved — a compliance officer or auditor can search archive tables and restore records if needed.
Still accessible via archive table queries Retrievable to active table if needed Counts toward compliance retention requirements
3
Purge Phase — Irreversible
Purge Rule Triggers → Permanent Deletion
After the retention period expires, the Purge Rule permanently deletes the record from the archive table. This action cannot be undone — no trash, no restore, no backup short of a full database restore. Always ensure retention periods align with legal requirements (GDPR, HIPAA, SOX) before configuring purge rules.
🚨
Warning — Purge Is Permanent and Irreversible Once purged, a record cannot be recovered from the database. Before configuring purge rules, ensure the retention period aligns with legal, compliance, and audit requirements for your organization. GDPR, HIPAA, SOX, and other frameworks have specific minimum and maximum retention requirements.
Section 4

Archive vs. CMDB Data Manager

There are two separate mechanisms for lifecycle management in ServiceNow, and the exam tests knowing which one to use:

FeatureArchive/Purge RulesCMDB Data Manager
TargetAny ServiceNow table (incidents, changes, etc.)CMDB CI tables only
ActionsArchive (move) or Purge (delete)Retire, Archive, or Delete CIs
CI-specific logic?No — generic record managementYes — understands CI relationships and lifecycle stages
Use whenManaging ITSM records (incidents, changes) lifecycleManaging CI record lifecycle in the CMDB
💡
Tip — Use CMDB Data Manager for CI Lifecycle, Archive Rules for ITSM Records If the scenario involves retiring or archiving Configuration Items, CMDB Data Manager is the correct tool — it understands CI-specific concepts like operational_status and lifecycle_stage. For archiving old incidents, change records, or tasks, use Archive Rules.
Exam Quick Reference

Common Exam Traps — Archiving, Purging & Retention

  • Archiving = move records to archive table (still accessible); NOT deletion
  • Purging = permanent deletion; irreversible
  • Recommended pattern: Archive first → Purge from archive after retention period
  • Archived records are read-only; find them via archive table or "Show Archived" toggle
  • Archive Rules = any table; CMDB Data Manager = CI tables only
  • Purging from active table skips the archive safety window — avoid unless intentional
Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Archiving, Purging & Retention Quiz 1 / 4

An auditor requests access to an Incident that was closed 3 years ago. The instance has an Archive Rule that archived closed Incidents after 2 years. Can the auditor access the record?

💡 Explanation

B is correct. Archiving in ServiceNow is NOT deletion. Archived records are moved to a separate archive table (e.g., ar_incident for archived Incidents) but remain accessible. Users can access archived records by: (1) querying the archive table directly, or (2) using the "Show Archived" toggle in list views to include archived records in results. Archiving's purpose is to reduce the active table size for performance while retaining data for compliance and audit purposes. Purging is the irreversible operation — only purged records are truly gone. This distinction is a frequent exam trap.

What is the key difference between CMDB Data Manager and Archive Rules for managing old CI records?

💡 Explanation

B is correct. CMDB Data Manager is specifically designed for CI lifecycle management: aging (changing operational_status based on staleness), archiving CI records, and managing CI retirement workflow. It understands CMDB concepts like operational_status, last_discovered, and CI class hierarchy. Archive Rules are the general-purpose ServiceNow archiving framework that can be applied to any table (Incidents, Change Requests, user records, etc.) — they move old records to archive tables based on configurable conditions. For CI records, you can use either, but CMDB Data Manager provides CMDB-aware operations that Archive Rules don't have.

A compliance team requires that closed Change Requests be retained for 7 years but not appear in normal list views. They also want to ensure records cannot be accidentally deleted during the retention period. What is the recommended approach?

💡 Explanation

B is correct. The recommended two-stage pattern: (1) Archive — moves records to the archive table, hiding them from normal views while keeping them accessible for audit/retrieval. Active table performance improves. (2) Purge from archive after the retention period — permanently deletes records once the compliance retention window (7 years) has expired. This provides: invisible in daily operations (archived), accessible when needed (audit retrieval), and guaranteed deletion after retention period (purge rule). Purging immediately (C) would destroy records that may be needed for compliance. Exporting to a shared drive (D) creates data governance and security risks outside the platform.

An administrator accidentally runs a Purge Rule against the active Incident table, deleting 500 Incident records that were still within the active retention period. Can these records be recovered?

💡 Explanation

B is correct. Purging in ServiceNow is permanently irreversible — there is no recycle bin, no undo, and no built-in recovery mechanism. Records can only be recovered from a database backup taken before the purge was executed. This is why the recommended pattern always archives first (safe, recoverable) and only purges from the archive after the retention period is confirmed expired. Running a Purge Rule directly against an active table skips the archive safety window and immediately destroys records. Before executing any purge operation, verify the scope carefully — purging cannot be undone.

Score: 0 / 4
Instance & Data Health →