- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-23-2017 07:35 AM
Hello all,
Today, a strange idea visited my mind: to export a table from one Helsinki Instance to another Helsinki Instance via a XML file.
I made two tests, in order to achieve this:
- Test 1 - exported a XML file of a global (default) table (which exists on both the Instances) from the first Instance and then imported the XML file on the second Instance.
In order to notice any changes, before exporting the XML file, I added an additional Table Column to the table, making the column count to 87, while the same table continued to have 86 on the second Instance.
Here are the steps I did:
Instance 1 -> System Definition > Tables > marked the checkbox of the selected table in the Tables list, then right - clicked the Name filed > Export > XML;
Instance 2 -> System definition > Tables > marked the checkbox of the selected table in the Tables list, then right - clicked the Name field > Import XML;
Result: nothing happened. The importation of the file was completed, but yet, the table of Instance 2 continued to have 86 Table columns, not 87 as the table of Instance 1;
- Test 2 - exported a XML file of a table from Instance 1, which table does not exist in Instance 2.
Result: nothing happened after the importation of the file. The table did not appear on the Instance 2;
I have to say that I read the following documents in Wiki:
Exporting Data - Exporting Data - ServiceNow Wiki
Exporting and Importing XML Files - http://wiki.servicenow.com/index.php?title=Exporting_and_Importing_XML_Files#gsc.tab=0
Importing from Another ServiceNow Instance - http://wiki.servicenow.com/index.php?title=Importing_from_Another_ServiceNow_Instance#gsc.tab=0
All of this leads me to the conclusion that I cannot export a table from one Instance and to import it to another one via a XML file.
I can import table records, but cannot import the table itself (if we have a scenario in which the table does not exist in the target instance, where the importation will be happening) or to import its fields (if we are talking about a scenario in which the table exists on both the instances, but the Table Columns count is different).
In order to be absolutely sure in this, I would like to receive an official confirmation of my understandings. Please let me know:
- If I got the things right or I am wrong and I can export and import a table (no matter existing or not) from one Instance to another. If so, then let me know how to do this;
- Confirm to me if the only way for this to happen (importing a whole table or only its fields from one Instance to another) is via an Update Set?
Thank you in advance!
Best Regards,
Georgi Mavrodiev
IT Consultant
Do It Wise
You may visit us in our Web Site: www.doitwise.com
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-23-2017 11:38 AM
Hello Georgi,
Thanks for the details. Sorry, I missed that table already exists on your target instance. In this case, you should have moved the column XML file(i.e record from sys_dictionary) and it would have worked.
However, in this particular use case when it comes to creating table/columns, I would confirm you that the changes need to be migrated via update set.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-01-2017 07:43 AM
Hello Pradeep,
I would like to hear out your opinion on the below question, which is in regards to this thread.
I listen to your advice and proceeded to perform tests using Update Sets.
I managed to complete my original Test 1 (using a default table which exists on two instances, but on the first one the table has 1 additional Table Column).
I did this by creating a new Update Set and let it running ('In Progress'). In addition, I made the Update Set to be my current one. Then, I went to the target table and clicked on the additional Table Column and changed its Column label, saved it, and immediately after that re - changed it to the default one. By clicking on the field - I opened its Dictionary entry and then, by changing its Column label - I ensured that both (the Dictionary entry and Column label) will be captured by the Update Set. Once I finished with these changes, I went and marked my Update Set as 'Completed'. Then I exported it into a XML file and committed it on Instance 2. All went fine and the goal of the test was completed -> only the additional Table Column was moved to Instance 2, exactly as I wanted it;
Then, I completed another Test - let's call it Test 2 - I activated an Update Set and left it running as current. After that, I created a custom table, which refers to Task table. In addition I added 4 custom fields to the table. Once its creation was completed - I stopped the Update Set. Then I exported it in a XML file and committed it to Instance 2, where the table did not exist. Once the Update Set commitment was completed - the custom table appeared on Instance 2 with all of its fields. So, this outcome was also a great one.
Now, my last scenario left to be covered (not solved):
- Again, we have two instances (Instance 1 and Instance 2). On Instance 1 there is a custom table which extends Task table. This custom table does not exist on Instance 2.
As you see, Pradeep, this scenario is similar to Test 2 (above). Yet, here I am not creating a custom table on Instance 1, while there is an Update Set running.
So, I want an already old (existing for a while) table to be transferred to Instance 2. Yet, I cannot find a way to do this. The only possible approach, which I can think of is to turn on a new Update Set, make it the current one and start clicking on all the Table Columns of this custom table and then changing their Column labels and immediately after that re - changing them to the default names, only in order for these actions to be captured by the running Update Set. But what will happen if the table has 100 Table Columns? It will cost a lot of efforts, so to me this idea is not acceptable. In addition, I believe I will need to do the same on several more tables: sys_dictionary and sys_db_object for example, which will be really time - consuming.
Thus, I would like to ask you for assistance, so I can use another solution here.
So far I did not find such in Wiki or here, in the Community, so I will really appreciate you help!
Thank you in advance, Pradeep!
Best Regards,
Georgi Mavrodiev
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-13-2017 04:15 AM
Hi ctomasi ,
Excuse me for bothering you, but I am not able to deal with the last scenario of mine (mentioned in my latest reply, located above).
I performed all kind of tests I had into my mind and I am definitely stuck here.
I will really appreciate if you may look into this matter when you have time (it might not be today or tomorrow, just when you are free).
If it is comfortable for you - then, I will highly appreciate your assistance, my friend!
Thank you in advance!
Best Regards,
Georgi

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-13-2017 06:10 AM
Hi Georgi,
There is an option, but it is risky and takes some testing. You can create a new update set and move the items in manually. The trick is to find the exact right items. A table is made up of the table definition itself, columns, field labels, potentially ACLs as well.
Being by creating a new update set. It doesn't have to be your current update set. For the sake of this post, I'll refer to it as "Set A".
From the navigator filter on the left, type in sys_update_xml.list and press enter. You are taken to a list of all changes made to the system. Somewhere in that vast list is your table. I prefer to use the date filter to narrow down the search. I also filter on the "Default" update set only (when no update set was selected to make the changes.) Locate the various table components (fields, labels, etc.) and change the Update Set field (not Remote Update Set) to point to Set A. These changes are now related to Set A, which you can mark as Complete, transfer and test on the test instance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-14-2017 12:25 AM
Hi Chuck,
Thank you for answering my request!
This is exactly what I feared - so many actions to be required + searching in a vast list of data.
Well, after this is the only feasible way for my scenario to be done - then I will definitely look into it and perform some testing.
(Handshake), Chuck!
Best Regards,
Georgi

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-14-2017 06:31 AM
It's times like this that certainly make you appreciate the work that is being done behind the scenes and how important it is to have the correct update set chosen. It also makes me appreciate scoped apps so I can get away from update sets and use the publish/install feature.
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.
If you are viewing this from the community inbox you will not see the correct answer button. If so, please review How to Mark Answers Correct From Inbox View.
Thank you