Since cloning is not possible, the best approach would be a controlled and sanitized import of only the required production incident records into sub-production using Import Sets and Transform Maps.
I would not recommend copying the full Incident table or moving all related data such as work notes, comments, attachments, SLA records, audit history, metrics, emails, etc. For Predictive Intelligence training, you mainly need good historical incidents where the categorization is already reliable.
For Incident Categorization, use resolved or closed production incidents where the Category value is correct. ServiceNow’s Incident Categorization solution predicts the Category field mainly from the Short description, so the quality of Short description and Category is very important.
Recommended approach:
Identify the right production dataset
Use a production filter similar to:
Created in the last 6 or 12 months
Active = false
State = Resolved or Closed
Category is not empty
Short description is not empty
Exclude test incidents
Exclude duplicate/spam incidents
Exclude old or retired categories
Exclude records with incorrect categorization
Also check that each category has enough records. If some categories have very few examples, the model may not train well for those categories.
Export only the required fields
Export only the fields needed for training and validation, such as:
Number
Short description
Description, only if you plan to use it as an input field
Category
Subcategory, if required
Contact type, if relevant
Business service or service offering, if relevant
State
Active
Created date
Resolved date
Avoid exporting sensitive fields unless they are required. If incident descriptions contain employee, customer, patient, financial, or security-sensitive data, sanitize or mask the data before importing into sub-production.
Import through Import Sets
Load the data into an Import Set table first and then transform it into the Incident table in sub-production.
During transform, tag the records clearly, for example:
u_ml_training_data = true
u_source_instance = Production
u_prod_incident_number = original incident number
u_prod_sys_id = original production sys_id
Active = false
State = Resolved or Closed
This helps separate ML training records from normal sub-production testing records.
Avoid duplicate imports
Use a coalesce field such as production incident number or production sys_id stored in a custom field. This way, if you import again later, existing training records can be updated instead of duplicated.
Prevent unwanted side effects
Before importing into Incident, make sure the import does not trigger unnecessary notifications, SLAs, assignment rules, integrations, or business logic. This should be handled carefully in a controlled import plan.
Train using a clean filter
In the Predictive Intelligence Classification Solution Definition, use a filter that includes only the imported training records, for example:
u_ml_training_data = true
Active = false
State is Resolved or Closed
Category is not empty
Short description is not empty
This prevents the model from learning from normal sub-production test incidents, which are usually not reliable.
Validate before training
Before training, validate:
Category choices match production
Category/subcategory values are still valid
No sensitive data is exposed
No duplicate training incidents exist
There are enough records overall
There are enough records per category
Training data represents real production patterns
My recommendation would be:
Use a controlled Import Set based migration of sanitized, resolved/closed production incidents into the sub-production Incident table, tag them as ML training records, and train the Predictive Intelligence solution using a specific filter that includes only those records.
This avoids cloning, protects ongoing sub-production development, reduces data privacy risk, and gives the model realistic historical data.
Also, once the solution definition, filter, and prediction quality are validated in sub-production, the final production model should be trained in production using approved production filters, because production has the real incident history and real operational patterns.
Please mark this as Helpful if it helps.
If this addresses your question, please mark this response as Accepted Solution
or mark has helpful
if you find it helpful.
Thank you!
TejaswiniY
