[object Object]

The single most common painful day in a ServiceNow team’s year is the day a sub-prod clone overwrites a custom table that lower environment had been building test data into for a sprint. Clone data preservation rules exist for exactly this reason — and most teams do not configure them until after the first incident.

The clone model in one paragraph

By default, a clone copies production data over your sub-prod instance. Tables you want to keep require a Data Preserver rule. Schedules you want to keep require a Schedule Preserver. Properties to keep require a System Property Preserver. Three tables, three different preservers, easy to confuse.

The minimum preserver set

Every instance should have these from day one:

Data Preservers:
  - sys_email_account (no prod SMTP creds in sub-prod, ever)
  - sys_user (specifically dev/QA test users)
  - sys_user_group (test groups)
  - x_*_test_data (any custom test data tables)

Property Preservers:
  - glide.email.smtp.active = false (suppress mail)
  - glide.outbound_http.warning_threshold (different in sub-prod)
  - sn_now_assist.endpoint (point to non-prod LLM)

The mail suppression trap

If you forget the email property preserver, the moment the cloned instance comes up it will start sending real customer notifications referencing prod data. This has happened to every team I have ever worked with at least once.

Use Pre-Clean and Post-Clean scripts

Clone supports two script hooks. Use them.

// Post-clone script
gs.setProperty('glide.email.smtp.active', 'false');
gs.setProperty('glide.outbound_http.warning_threshold', '50');
new EmailUserDeactivator().deactivateNonTestUsers();
gs.eventQueue('clone.completed', null, gs.getUserName());

The glide.email.smtp.active=false belt-and-braces both the preserver and the script.

Schedule preserver gotcha

Scheduled jobs come over from production. Most should be disabled in sub-prod. Use a Schedule Preserver to flip active=false on jobs that should not run, rather than chasing them down each time.

Document the clone runbook

The clone runbook should fit on one page: who approves, who runs, preservers verified before, post-clone smoke tests, who signs off. Print it. Tape it to the wall.

What to do this week

Audit your preservers before the next clone. Confirm email is suppressed, custom test data is preserved, and the post-clone script runs. Run a dry-run clone into a third instance if you have one — discovering a missing preserver in production sub-prod is expensive.

[object Object]
Share