We've updated the ServiceNow Community Code of Conduct, adding guidelines around AI usage, professionalism, and content violations. Read more

Implement Data Retention Policies using ServiceNow System Data Management

SaiAashishN
Tera Contributor

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
 
2 REPLIES 2

suraj sengar
Kilo Guru

@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
Tera Contributor

But I need to get the same output using ServiceNow System Data Management
Is the same possible using the System Data Management