- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on ‎03-21-2019 06:23 AM
Human Resources data in many instances is considered sensitive. Cloning production instance to sub-production instances is one of the good practices that can help in successful migration and delivery of enhancements/updates. But cloning an instance with Human Resources data might raise concerns as ServiceNow System Administrators/Developers see production data in sub-production instances after a clone. Our HR department wanted to completely exclude production data coming to our sub-production instances after a clone. In order to make this possible, I explored the community to look for answers and found a post (URL below) which talks about the issue. Different solutions were given for this problem, but I wanted a solution that occurs as part of the clone process without needing any manual steps.
HR data to remove during cloning
What does not work?
Before I provide details on the solution that worked for me, I wanted to discuss something that did not work. ServiceNow Docs clearly mentions that Task table and tables extending task cannot be excluded during clone unless you exclude the task table in its entirety. All HR Case tables extend from task table and it's obvious that you wouldn't want to exclude the entire task table during clone just for preventing production HR data from being transferred to sub-production instances.
"The system cannot exclude tables that extend the Task table and are also flattened into it as part of the table per hierarchy extension model. Since these extended tables are actually part of the same physical database table, the system clones the data when it clones the Task table. You can exclude tables that extend the Task table under two conditions. Either the system stores the tables in their own physical tables as part of the table per class extension model, or you exclude the Task table itself."
I wanted to try it anyway to confirm that creating exclusions do not work. I created a exclude on sn_hr_core_case and all its extensions like sn_hr_core_case_leave_and_compliance etc. I deleted all the existing data in my target instance before clone and scheduled a clone. After clone, all the HR case data from core case and other extended tables were brought over to the target instance. This proved that excluding Human Resources tables in Exclude Tables which start with sn_hr_core_case does not work.
What works?
After trying the exclude, I was looking for a way to exclude data as part of the clone process. I thought I can create a cleanup script to delete the data, but wanted to confirm the idea with ServiceNow support. After contacting support and receiving the suggestion to create a cleanup script, I decided to do so:
deleteAllHRdata();
function deleteAllHRdata() {
var gr= new GlideRecord("sn_hr_core_case");
gr.setWorkflow(false);
gr.deleteMultiple();
}
Before scheduling clone of the target instance for the second time, I wanted to make sure my script worked. So, I ran the script as a Fix Script and made sure the data was deleted in the target instance (sub-production instance). After this, I scheduled a clone to my target instance. At this point, I was hoping that all the HR production data does not come through. Post clone, I checked the target instance and was surprised to see HR Production data. So, did the cleanup script not work? Well, after working with ServiceNow support again I figured that I was missing a piece.
In the table configuration for sn_hr_core_case, out of the box under Application Access you will see that the Can Delete is unchecked. This is to prevent other scopes other than Human Resources : Core from deleting HR data. For the cleanup script to work, this box should be checked. Be cognizant of the fact that checking this box is enabling delete access from other application scopes including global scope.
After making this change and scheduling another clone, production data did not come through to sub-production instances. Hurray!
In summary, two updates need to be made for the data to be excluded in sub-production environments
1. Update Application Access in sn_hr_core_case table to allow Can Delete (✔) in production instance
2. Create a Cleanup Script in your production instance as shown above (or create one of your choice which can delete all the data on sn_hr_core_case). Available in System Clone > Clone Definition > Cleanup Scripts.
Things to note:
1. You can create the cleanup script in global scope or Human Resources: Core scope. You should have the 'Can Delete' (Application access) checkbox checked, irrespective of the scope in which this cleanup script is created. I had created the cleanup script in Human Resources : Core scope, but until I checked the Can Delete (Application access), production data in sub-production instance did not get deleted
2. If you want to test the script, you can test it in Background Script/Fix Script. But, make sure you only test in sub-production instance. (Warning! Running script in production can cause loss of data. Be cautious of the instance that you are testing with)
3. This method works for sn_hr_core_case and all the tables that extend sn_hr_core_case. If you have a table in Human Resources : Core scope which does not extend sn_hr_core_case and you want data to be excluded from that table, follow the same steps as above for corresponding table.
I have requested ServiceNow to add this feature to their core platform. I know that many customers might want to exclude production data during clone especially data pertinent to Human Resources. Let's hope that this gets added.
Let me know if this helped you or comment below if you have other ideas.
- 2,686 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Given the often sensitive nature of HR data you would think the exclude tables would work for HR tables. Most customers will not want HR records coming down into sub-prod instances.
This is simply odd, ServiceNow need to explain why this is the case and clearly state this in the DOCS site, or fix this. They also need to highlight the importance of having the 'Can Delete' checkbox checked on the table in the DOCS site.
I have reported this on the exclude page in DOCS: https://docs.servicenow.com/bundle/quebec-platform-administration/page/administer/managing-data/task/t_ExcludeATableFromCloning.html#
Thanks for the clear explanation.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Thank you for going through this article Paul

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi,
Thanks for the article. This got me thinking since I have just recently cloned a customer instance and excluded the HR tables successfully and was fairly sure that task was not excluded (all tasks, incidents and etc was cloned to sub instances).
I read the documentation ones more and it says "You can exclude tables that extend the Task table under two conditions. Either the system stores the tables in their own physical tables as part of the table per class extension model, or you exclude the Task table itself." I'm thinking that since HR has their own tables it fulfills the first part in the quote?
/Markus

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Questions
1) If even System Admins cannot see HR data in Production, why would they be able to see it in the lower instances? Or what would be the purpose of excluding it from the lower instances?
2) What about all your good data / test data in the lower instances? It's hard to develop and test without any data in the tables. So isn't the Delete Everything approach kind of overkill?

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Hi @G24
I would argue that best practice is to exclude HR data when cloning sub-instances.
Rather common that e.g developers have access to HR scope in sub-instances but not in production. Since HR data also more often is sensitive data you really want to avoid data leak.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Just a note, if you don't want to change cross scope permissions for your tables, you can use the classic trick of adding a script include in scope, with cross scope access enabled. This lets you call the script include from the global scope (all clone cleanups run in global regardless of the actual cleanup scripts scope), but delete.

- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
There's still a small challenge here in that the deleted records will be in the deleted records table.