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

Luiz Lucena · ‎06-12-2019

Hi everyone,

I know this post is old and was already well pointed by Chuck, but considering the user's point on what the documentation says:

"it is the best practice to clone everything to subProd."

Would that overwrite REST, SOAP connections?

Chuck Tomasi · ‎06-12-2019

If you use Credential Aliases in your integrations (Orchestration and IntegrationHub) you're safe. If you hard code your connections (in script or using straight connections, you're at risk.) Credential Aliases were designed specifically for this purpose - you can design with a "name" and it references the credentials which are different on each system.

Create a Connection & Credential alias

Luiz Lucena · ‎06-12-2019

Thanks, Chuck.

So, as far as I understood, the aliases will protect the connections and credentials stored in the discovery_credentials.

However the REST message we have is on the Orchestration application and the authentication for it is on sys_auth_profile_basic.

From the exclude list, if I leave the first one checked and the other two checked, would you know what would be the result?

Chuck Tomasi · ‎06-12-2019

Hard for me to answer that without knowing what's in the Exclude list.

#2 and #3 are pretty self explanatory. Audit and log data is excluded to save time on the clone (and generally not useful on the cloned instance.) It only applies if your table is audited. #3 only applies if you have attachments. Neither seem to be applicable to REST integrations.