Implement Data Retention Policies using ServiceNow System Data Management

SaiAashishN · 3 weeks ago

The archive and deletion rules defined below should be implemented using ServiceNow System Data Management (And these rules should be applied to the particular Service Catalog Item)
features.

Default policy

- Records older than 3 years are moved to an archive backup table. These records are accessible for

- Records older than 7 years are permanently deleted

Note: Once delete these records are destroyed permanently from the system and no longer recoverable.

Tables that are excluded from Archive/Deletion policies

- The following types of tables NEVER have archive OR deletion rules

- Any table that is considered a "lookup", "type" or Choice value

- Any User Account records (e.g. from sys_user table)

- Any security related table (e.g. Groups, Roles, etc.)

- Any ServiceNow system table (e.g. "sys_" prefix) that does not already have an Out of box archive or deletion rule

Any suggestions please let me know

suraj sengar · 3 weeks ago

@Sai

Implementing these rules in ServiceNow requires a two-step process using the Archive Control and Destroy Control features. Since you specifically mentioned these should apply to a particular Service Catalog Item, you cannot simply archive the entire sc_req_item table; you must use Archive Queries to filter by the specific Catalog Item (sys_id).

Here is the recommended configuration based on your requirements.

1. Archive Rule (The 3-Year Move)

This rule handles the transition from the "Live" table to the "Archive" table.

Table: sc_req_item (Requested Item)

Active: True

Retain Records: Checked

Archive Run Interval: Monthly (standard) or Daily.

Conditions:

Item | is | [Your Catalog Item Name]

Created | before | Last 3 years

State | is one of | Closed Complete, Closed Incomplete, Closed Skipped (Important: Do not archive active tickets).

2. Destroy Rule (The 7-Year Permanent Deletion)

Once a record is moved to the Archive table (e.g., ar_sc_req_item), it is no longer in the live table. You must now create a Destroy Rule that targets the Archive table, not the original one.

Name: Permanent Delete - [Item Name]

Archive Rule: Select the Archive Rule created in Step 1.

Table: ar_sc_req_item

Conditions:

Archived | before | Last 4 years

(Note: Since they moved at year 3, waiting another 4 years in the archive equals the 7-year total requirement).

3. Handling the "Excluded Tables"

Your requirement to exclude "lookup," "choice," and "sys_user" tables is actually handled by default in ServiceNow's architecture, but you must be careful with Archive Related Records.

Lookup/Choice Tables: These are referenced via Sys_IDs. When you archive a Requested Item, the reference remains, but the actual Choice or User record is never moved unless you explicitly create an "Archive Related Record" rule for it.

System Tables: By default, ServiceNow does not allow archiving of core system tables (like sys_user) unless a specific OOB rule exists.

The Guardrail: When configuring your Archive Rule, do not add "Archive Related Records" for tables like sys_user, sys_user_group, or sys_choice.

4. Implementation Checklist & Tips

Performance & Safety

Test in Sub-Prod first: Archiving and Deletion are irreversible in terms of automated "undo" buttons. Run the archive on a small subset of data first.

Index your fields: Ensure the cat_item and sys_created_on fields are indexed on the sc_req_item table to prevent the archive job from causing a performance hit.

Auto-Stop: ServiceNow has a built-in safety. If an archive job takes too long or processes too many records, it may pause. For the initial run (clearing out years of backlog), you may need to run it in batches.

SaiAashishN · 2 weeks ago

@suraj sengar
Hi Suraj
I have a question
I need to implement the Achieve and destroy rules on a specific catalog item (that was the steps you provided to work on the sys_req_item table).

But, What happens to the Request table (parent table) so those won't get Archived and destroy right
So I need a solution where the Request records which is linked to that specific catalog item should also be archive and destroy.
So is there any solution for that
Can we run a schedule job by creating a custom field on the Request table and check whether the records were 3 years before and implement the Archive rule.

suraj sengar · 2 weeks ago

@SaiAashishN - You’ve spotted an important nuance in how Archive & Destroy rules work in ServiceNow.

What Happens by Default
Archive/Destroy rules are applied at the table level.

If you configure rules on sc_req_item (Requested Item), only those records are archived/destroyed.

The parent Request (sc_request) record is not automatically archived/destroyed, even if all its child items are.

This means you could end up with orphaned Requests that no longer have their associated items.

Possible Solutions
Cascade Archiving via Relationship

ServiceNow doesn’t natively cascade archive rules across parent/child tables.

You need to explicitly configure rules for both sc_req_item and sc_request.

One approach is to add a condition on the Request table that checks whether it is linked to the catalog item in question.

Custom Field + Scheduled Job

As you suggested, you can add a custom flag field on sc_request (e.g., u_archive_candidate).

When a sc_req_item tied to your catalog item is archived, set this flag on the parent Request.

Then run a Scheduled Job (e.g., nightly/weekly) that checks Requests older than 3 years with this flag and archives/destroys them.

This ensures Requests linked to those catalog items are handled consistently.

Business Rule Trigger

Create a Business Rule on sc_req_item that, when archiving/destroying, evaluates the parent Request.

If all child items are archived/destroyed, mark the parent Request for archiving.

This avoids leaving Requests without active items.

Archive Rule on Request Table

You can also directly configure an Archive Rule on sc_request with conditions like:

Opened date < 3 years ago

Catalog item = <specific item>

This way, both parent and child records are covered by rules, without needing a scheduled job.

SaiAashishN · 2 weeks ago

@suraj sengar
You mentioned one of the ways to achieve the solution is to implement

Archive Rule on Request Table

You can also directly configure an Archive Rule on sc_request with conditions like:

Opened date < 3 years ago

Catalog item = <specific item>
But how can we filter the condition with the Catalog item,
There is no such field available in the Request Table.
And if we want to archive the child records of the for the sc_req_item table means the
sc_task records, so we have to check the child records and parent records as well.