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

[meg6]

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]

Can you be more specific about the tables you want to exclude? If you are excluding tasks, users, cmdb, etc. then what's the point of cloning?

The reason most organizations clone is to "refresh" that data from prod to sub prod instances. Changes like business rules, form layouts, etc. are done in dev and flow "up" while transactional data like incidents, problems, CIs, etc. are captured in prod and cloned "down".

[meg6]

Hi Chuck,

Thank you for the response. I am surprised to know that we are an exception.I want to exclude table data like user data (sys_user) and transactional data. Requirement is we are not supposed to keep user data in the sub prod instances  due to information security  requirements. 

But cloning should include other changes like business rules/configurations.

[Chuck Tomasi · Accepted solution]

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.

[meg6]

Hi Chuck,

I understand that we can not exclude foundation table like sys_user as hundreds of tables are referencing user table.

Prod data should exist only in prod environments because we typically don't apply the same rigour in access control and general security practices in dev and test environments as we do in prod. 

This is why we would like to avoid cloning production data.

The reason we are cloning the environment is to test the upgrade on our subprod instances before we upgrade prod. We have been advised that we need to test with prod data as well as configuration but we would prefer to only clone configuration / business rules (to protect the security of our prod data). Is it not possible to separate configuration of the ServiceNow instance from the data it holds?