- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
yesterday - edited an hour ago
A practical guide to moving stale records out of your live tables — keeping your instance fast and your data manageable — without losing access to historical records.
If your ServiceNow instance has been running for a few years, chances are your primary tables have accumulated a lot of data that is no longer operationally relevant — closed incidents from 2020, resolved problems from 2019, CMDB entries for decommissioned servers.
That data sits in your live tables, slows down queries and reports, and makes it harder for your teams to find what actually matters today.
Data Archiving is ServiceNow's answer to this problem. It moves inactive records out of your primary tables so the data you work with every day stays fast and manageable — while older records remain fully accessible, searchable, and ACL-governed when you need them.
Archived records are not deleted. They remain queryable, respect your existing ACLs, and can be restored if needed. Archiving is about moving data to the right tier — not losing it.
Before diving in, it helps to know that ServiceNow offers two distinct archiving capabilities. Understanding the difference up front saves confusion later.
ar_* tables in same databasecom.glide.db.columnar.archiveArchive rules are identical between both modes. If you start with System Archive today and later upgrade to RaptorDB Professional, your existing rules carry over automatically — no rework needed.
Three concepts you need to understand before configuring anything.
Define which records get archived. Each rule targets a single table and uses filter conditions — typically time-based — to identify records to move. For example: "All Incidents closed more than 150 days ago where Active is false." A single table can have multiple rules, and rules run on a 60-minute schedule by default.
When records are archived, they move to a corresponding ar_* table — for example, ar_incident for the Incident table. On System Archive, these live in your primary database. On Live Archive (RaptorDB Professional), they are backed by object storage.
An optional policy attached to an archive rule that permanently deletes records after they have been archived for a set duration. If you leave the archive duration empty, records are destroyed immediately on archive. Destroy rules are irreversible — plan carefully before enabling them.
Available on all instances — no additional licensing needed. Here is the complete setup flow.
-
1Understand what you have first. Open the Data Management Console (
All > System Data Management > Data Management Console) and look at the table-size and growth trend views. This tells you where archiving will have the most impact before you write a single rule. -
2Create an archive rule. Navigate to
All > System Archiving > Archive Rules > New. Set the Name, select the Table you want to archive, and build your filter conditions. A typical Incident rule looks like: Closed → relative → on or before → 150 → Days → ago AND Active → is → false. -
3Preview before committing. Click Recalculate Archive Estimate to see exactly how many records match your conditions. This is your sanity check — confirm the number looks right before the rule ever runs.
-
4Activate the rule. Check the Active checkbox and submit. The archive job runs every 60 minutes by default. You can also trigger it immediately via Run Archive Now — note that a Data Management Policy must also be active for this to work.
-
5Verify. Navigate to
All > System Archiving > Archive Tablesto confirm records have moved to the correspondingar_*table. -
6Optional: create a destroy rule. On the archive rule form, select Create Destroy Rule and set the Archive Duration (how long records sit in the archive before being permanently deleted). Only enable this if you have a clear retention policy.
If you are on RaptorDB Professional (Australia release or later), enable Live Archive to physically move records and attachments to object storage — freeing your primary database and delivering the full performance benefit.
RaptorDB Professional subscription, Australia release or later, and at least RaptorDB Professional version 35.1. Admin role required.
-
1Install the plugin. Navigate to
All > Application Manager, search for "Live Archive", and installcom.glide.db.columnar.archive. During installation, any existing archived data is automatically converted to compressed columnar format and moved to object storage. Normal instance operations are not affected — only archive rule processing is paused, and it resumes automatically when done. -
2Verify the S3 facade. Navigate to
sys_service_endpoint_list.do, filter bys3_facadein the Name column, and confirm two endpoints exist with Active = true. These endpoints (one per datacenter) are your confirmation that the storage layer is ready — and they provide high availability if one datacenter is unavailable. -
3Confirm the Object Storage tile. Open the Data Management Console. You should now see an Object Storage tile. Storage stats refresh once daily and reflect compressed sizes. The tile populates only once an archive table exceeds 512 MB or 2 million rows, so it may take some time to appear after the first archive run.
-
4Your existing archive rules are already working. No changes to your rules are needed — Live Archive picks them up automatically.
Most tables — including task and all its extensions (Incident, Problem, Change Request) — support archiving. The following tables cannot have archive rules created for them:
- sys_audit and audit variants
- sys_attachment — archived automatically with the parent record
- sys_journal_field — archived automatically with the parent record
- Internal system tables
You do not need a separate archive rule for attachments or journal entries. They are automatically archived and destroyed alongside their parent record.
sys_archive_log record is the only mechanism for restoring an archived record. Deleting one makes restoration permanently impossible.