How to check what ServiceNow history your archiving and retention rules have kept

How much ServiceNow history is left, and what decides it

Three settings decide how many years of incidents, changes and knowledge articles still exist in an instance. Archive rules move records that meet a condition, such as incidents closed more than a set number of months ago, out of the live table into a read-only archive table; in most instances the archived copy lives in a table with an ar_ prefix, so old incidents end up in ar_incident. Archive destroy rules then delete archived records once they pass an age someone chose. Table cleanup policies delete rows straight from a live table without archiving them first, and are usually aimed at logs, email records and other high-volume tables.

So archiving on its own rarely loses history. Deletion does. The useful question for an admin is not whether the instance archives, but which destroy rules and cleanup policies are active and when each one next runs.

That matters beyond storage cost. A decade of incidents with work notes, change requests with approvals and outcomes, problem records with root causes and versioned knowledge articles is a detailed account of how IT work actually gets done. The page on ServiceNow incident, change and knowledge records explains why AI developers value that material.

What you need before you start

This is a read-only review. Nobody exports, moves or copies records during it.

• Admin access to the instance, or an admin working alongside you, so you can open System Archiving and the table cleanup settings.
• The company's written records retention schedule, plus any legal holds the compliance team is tracking.
• The instance go-live date and the name of any tool it replaced, such as an older helpdesk whose history may never have been migrated.
• A short list of in-scope tables: incident, change_request, problem, kb_knowledge, requested items, the journal table that stores work notes and comments, sys_audit for field history and sys_attachment for files.
• A named decision owner, for example the ITSM process owner or the CIO, who can approve a pause to a scheduled purge.

How to measure the history, step by step

1. List the archive rules. In System Archiving, open Archive Rules and note for each one the table, the condition, whether it is active and whether it carries related records such as work notes, audit history and attachments along with the parent record.
2. List the archive destroy rules. Note the table each one covers, the age at which archived records are deleted and whether the rule is active. An active destroy rule is the line that matters most in this whole review.
3. Check table cleanup. Review cleanup policies on each in-scope table and on sys_email, which holds the notification and inbound email records that often explain what happened on a ticket. Look for any policy someone added to an ITSM table to save space.
4. Count records by year. For each table, group the live table and its archive table by the year opened. Record counts only; no record content goes into your notes.
5. Find the gaps. Compare the earliest record date with the go-live date. A gap usually means history stayed in the previous tool or was purged before archiving existed.
6. Spot-check completeness. Open a handful of archived records from the oldest years and confirm that work notes, resolution notes and attachments survived. If an archive rule was set up without related records, the incident may exist without its conversation.
7. Write a one-page summary. One line per table: years covered, record count per year, next scheduled deletion and owner. The data inventory builder helps lay this out as metadata.
8. Hold pending deletions while the owner decides. If a destroy rule will soon reach valuable years, ask the decision owner whether it can be paused or pushed back, with sign-off from whoever owns the retention schedule. If policy or a legal obligation requires deletion, follow it.

The pre-purge check: is this history worth a licensing review?

Before a destroy rule runs on years of IT history, spend five minutes on four questions. If three or more are a clear yes, raise it with the company's leadership before the purge date.

• Depth: do several years of incidents, changes or problems survive with work notes and resolutions, not just titles and timestamps?
• Ownership: are these the company's own internal IT records, rather than tickets an MSP or outsourcer handles for its clients?
• Size: has the company had 50+ full-time employees at peak (contractors excluded) and several years of documented operations?
• Sponsor: is there an owner, CEO, CFO or authorized representative who would consider a one-time payment for an exclusive AI-training license over an agreed term?

Ownership is the answer that cannot be fudged. An MSP's multi-tenant instance holds records about its clients, and those records are the clients' to decide on. The page for managed service providers covers how to introduce a client company instead.

What export options exist if a license goes ahead

Exports for a license happen only after the company signs an agreement and authorizes delivery, under redaction rules settled before any work begins. The consultant or partner who made the introduction never runs them. When that point comes, the admin has several routes.

Typical redaction items in ServiceNow history include caller names and emails, hostnames and IP addresses, and passwords or license keys that people pasted into work notes. SourceX agrees those rules with the company before anything leaves the instance.

Common mistakes when reviewing ServiceNow retention

Illustrative example

Illustrative: a fictional 400-person software company has run ServiceNow since 2016. Closed incidents archive after 12 months, and an archive destroy rule deletes archived incidents after six years. Its ITSM consultant, running the review above during a platform upgrade, finds that the 2016 to 2018 incidents, complete with work notes, are due for deletion next quarter.

The CIO pauses the destroy rule with the general counsel's sign-off, and the summary table goes into the company's data inventory. The consultant then introduces the CFO to SourceX with a referral link. The same logic applies to other tools with expiring history, such as Zoom cloud recordings and the support records of a retired product.

Next step

Run the eight steps on one instance this month and write the one-page summary. If the history passes the pre-purge check and the company meets the who qualifies baseline, register as a partner and make the introduction, or have the sponsor apply directly at sourcex.si/apply using your referral link.