Exclude some records from a table being copied across during a clone

bpolo
Tera Guru

We are currently working on a project where we will be creating High Risk (Restricted) Security Incidents. We are not wanting these records to be cloned into any of our sub-instances. We know how to exclude a whole table from being cloned over. Our question is there a way to exclude only some of the data on a table from being cloned into the sub-instances,other than writing a script to delete the records from the table in the sub-instance after the clone is complete? Thanks!

5 REPLIES 5

Bert_c1
Kilo Patron

I can't think of any other way to achieve your goal from what you describe. A Data Preserver will preserve what is on the target instance.

MackI
Kilo Sage

hi @bpolo 

 

I hope you are well and good.

 

Yes, there is a way to exclude specific data on a table from being cloned into sub-instances in ServiceNow's Washington DC release, without having to delete them afterward. You can achieve this using Data Preservers with conditions.

Here's how you can approach it, along with explanations and considerations:

1. Leverage Conditional Data Preservers:

Data Preservers: Normally used to ensure data is preserved during a clone. We'll use them in a reverse way to prevent certain data from being copied.
Conditions: This is the key. You'll define a condition that identifies the High Risk (Restricted) Security Incidents that should NOT be cloned.
Steps:

Identify the Condition: Determine how you identify your High Risk incidents. Do they have a specific value in a field (e.g., a "Risk Level" field set to "High," a custom "Restricted" checkbox checked, etc.)? This will form the basis of your condition.
 
2. Navigate to Clone Data Preservers: In your source (production) instance, go to System Clone > Preserve Data.
 
3. Create a New Preserver: Click New.

4. Configure the Preserver Name: Give it a descriptive name, like "Exclude High Risk Incidents".
Table: Select incident (or whatever your incident table name is).
Condition: This is where you put your logic. Use the condition builder to define the criteria that identify your High Risk incidents
 
 
5. Add this Preserver to your Clone Definition:

Navigate to Clone Definition: Go to System Clone > Clone Definition.
Edit the Definition: Open the clone definition you use for your regular cloning process.
Add Preserver: In the "Preserve data" section, add the data preserver you just created.
Save.
 
Important Note___
 
Data preservers are table-specific. If you want to prevent certain records from being cloned on the problem table, you need a data preserver for problem. Similarly, you'll need a separate data preserver for the change_request table, and so on.
 
Testing: Thoroughly test this in a non-production environment before applying it to your live cloning process. Clone from your production instance to a test instance to ensure it works as expected.
 
If you like this opinion and your problem is resolved after reviewing and applying it. Please kindly mark this your best answer‌( Accepted Solution )🌠‌ OR  mark it  Helpful â€Œâ›‘‌ if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community
MackI | ServiceNow Technical Consultant | DXC Technology Australia | ServiceNow Practice | LinkedIn Top IT Operation Voice 2023 | Sydney,Australia

Hi Mack, 

 

To be clear, the Exclusion data and Preserve data are being set up at the source instance level?

NymphP
Giga Contributor

Great question! If you're looking to exclude only specific records from being cloned into sub-instances, rather than excluding the entire table, one approach is to use clone rules. Depending on the platform you're using, you can configure these rules to filter out certain data during the cloning process itself. For example, you might set conditions based on specific field values, like a status or a custom flag that marks the record as 'restricted.'

If clone rules aren't available or flexible enough for your needs, you might also consider leveraging data policies or scoped APIs to restrict what gets transferred. This way, you avoid the overhead of running post-clone scripts to delete the unwanted records.

Let me know if you'd like more details on setting up filters or conditions—happy to help!