Knowledge article ID vs sys ID

[Les1]

for knowledge articles, in the XML one does not find "sys ID" mentioned but rather the field "article ID" 

can anyone elaborate around this construct as it differs from other record types where usually Sys ID is found on the xml as well as when exporting records.

i'm trying to test some article imports from one servicenow instance to a different customer instance in which the issue of LIKE article numbers or LIKE sys ID would be things to contend with.

in my tests thus far, i took an article xml for an existing article, then altered the ARTICLE ID to see what it does when importing, but it simply updated the existing article instead of making a duplicate as i would have expected. So this indicates that article ID is not the unique identifier but rather the sysID still is but sysID does not show in the xml or in exporting the article to excel.

thanks for your help

[bammar]

Without intimate knowledge of this exact use case ill try to diagnose this. 

A sys_id is like the social security number of a record- a Unique id in that instance.

When you move data from one instance to another- the sys_id in the destination could already be taken in the destination.

That is why the Knwoledge id is taken so u can have a semblance of connectivity a human can recognize- as a human doesnt memorize the sys_id - a new sys_id will be created on insert in the destination table. 

The only way to preserve exact sys_id is to do a clone. 

[Les1]

the article id = sys_id as far as i can tell unless one manipulates the xml before import.

guess i'm  a little confused by your comment around readability as the article id string is no more readable than the sysid (as they are the same string)

thanks for that tip bout cloning, this is between two different company instances in which we're trying to migrate articles but dont want to overwrite existing articles.

[bammar]

I may have been comfusing that Article ID for KB number.

Whats the situation in the other instance- are there old versions of the same articles or are they totally different. If they are totally different then you dont have to worry and you can always run a filter- created on last hour to see what you loaded in.

If there are old versions and some articles need to be updated from your import consider an import set that coalesces on a common field... Or even load these in a brand new Knowledgebase and have a SME curate them and keep what you need - retire a duplicate etc

[Les1]

we're trying to migrate articles from a different company's servicenow into our servicenow. So there is the possibility that the importing articles could have the same article numbers or even same sysID though i think the latter would be unlikely.

I think i'm going to have to just do a data comparison (like an excel vlookup match or something) between the articles to be imported versus what we have to resolve the like article numbers or like article ID (sys ID) and handle those differently.