If you do not use Name attribute as your primary key, as the Name attribute need to be unique in Service Desk, it will, if you try to import a record that has a different value in your set primary key throw this error message if the value mapped to Name already exist in the database.
So basically, lets say you set Title to be primary key. Title is not unique in Service Desk meaning that you can have several records with the same Title value. When you run the import, as Title is set to be your Primary key it will run a comparison towards this value. If the value doesn't exist it will try to import it.
When it imports it it will of course insert the values to all mapped attribute, whereas Name will be mandatory. When it tried to insert the value to Name it will hit the unique constraint and therefore won't be able to continue as the value already exist. This is when you will get this error message.
It is always recommended to use Name as your primary key as this will make sure that you are always checking towards a unique value and to make sure that you are never going to experience this issue.
Thanks for the information. The only issue I have with this is that it's hard sometimes to have a completely unique value go into the Name field, simply because it seem like that field is the default field used for the explicit log in. So I can't use something like the AD GUID or an email address. So in the event that I'm pulling names from 3 different AD domains to get users, there is the possibility that there are 2 of the same name (ideally the SAMACCOUNTNAME from AD). I've found a way around this by concatenating the SAMACCOUNT and the truncated CanonicalName during the import so I get JCANNONRB now. I just know moving forward, this could be an issue for other people with the same scenario I have.
You would need to make sure that any values going in to the name field is unique. So in your source you will need to make sure that you don't reuse any values that are then mapped to Name in Service Desk. I know this can be difficult if you are importing from more than one source, but I'm afraid this cannot be changed in Service Desk.
You could use email address in your Name attribute in Console without any problem as long as it's unique. This means that users will need to sign in using their email address as their login name.
What I did ...
I imported the data into some shadow objects created just to hold the values for users in AD1, AD2 and so on. These had calculations on them to combine samaccount with a suffix and then I imported those shadow areas into LANDESK as they then had unique names.
OK not ideal - it would have been better to have processed only those where there was a clash, but there was no budget to do that.