Why does excluding table data during cloning is not the best practice?

meg6 · ‎06-25-2018

Hi experts,

We are planning to upgrade test instance . While cloning Prod to test we want to exclude prod data and preserve mock data in test instance.

As per now we understood that ServiceNow consider scripts/Business Rules also as table data, so that we can not exclude, and even for tables it is same.And also it seems like ServiceNow suggests that "it is the best practice to clone everything to subProd." (https://docs.servicenow.com/bundle/kingston-release-notes/page/release-notes/upgrades/task/upgrades-phase-2.html)

ex: we can not exclude user data as it is referenced by hundreds of tables and again those tables are referenced by hundreds of tables. Do we need to find all the tables that are being affected and write the rules for it before cloning?

Is there any subset of tables that we can exclude ?

Is there any solution for it? I think its normal requirement that companies do have. Any inputs for this will be helpful.

Thank you

Chuck Tomasi · ‎06-26-2018

First, cloning WILL include configuration changes like business rules, UI policies, ACLs, etc. It's a clone. It's going to be complete.

Let's go down the path and say that you didn't clone sys_user. What then, do you anticipate will happen to all the tasks, CIs, and other records that reference sys_user when you complete the clone? You'll have "orphan references" that point to no records and if someone clicks through one of those links they'll get a Record not found error. That's no good.

I'm curious to understand your vision of what you would like to do when you leave out such a foundational table.

View solution in original post

Chuck Tomasi · ‎06-27-2018

Thank you for the explanation. I would argue that without the data, the configuration is far less meaningful for testing.

If you didn't clone 100,000 incidents, for example, you might not pick up on performance issues in an inefficient script until you get to production. An upgraded sub prod instance might appear to work fine, but you won't have the load with prod data until you get to prod and that might reveal additional issues.

There's no OOB way to say "Don't clone my data" without explicitly stating the tables in the exclusion list. I can understand your use case and I invite you to open an enhancement request! Our product managers DO listen.

Enhancement requests: Tell us how you would improve the ServiceNow product

meg6 · ‎07-11-2018

Thank you Chuck .

Chuck Tomasi · ‎07-11-2018

You are welcome.

If I have answered your question, please mark my response as correct so that others with the same question in the future can find it quickly and that it gets removed from the Unanswered list.

Thank you

Sama4 · ‎09-30-2018

Hi ,

Did you manage not to clone the user data from PROD to non PROD instances? If yes, was sys_user table added in excluded tables option ?

I understand Chuck's opinion here but even we have similar case as yours not to clone the user data because of security constraints.

Radha K · ‎01-23-2020

Hi Chuck,

Is there a way to clone instance which includes configuration changes, but does not modify any records of REQ/RITM/SCTASK/INC/CHG?

RK
If my response is helpful, please select Helpful. If my response answers your question, please select Accept as Solution.