I am trying to archive some old records by moving them to a new object in my app. One of the fields in the current object is a connection to Accounts which I use to tie the record to the logged-in User. I have set the ‘Display Field’ for accounts to Name, this is important because the field is used throughout the App, and using anything else would make things confusing. I’ve made a copy of my existing object and used it to create a new object called archive with all of the same fields. I exported all of the records I want to archive with no trouble, however when I try to import them into the new object, I cannot import the account field because the import tool does not allow me to select “Name” as the “Account field that matches the Account column.”
My question is, am I doing something wrong with my attempt to transfer the records to another object? Is there a better way to do this? I suppose I could temporarily change the display field to something that is on the list but I feel like the Name field should be usable.
I’m open to any thoughts or ideas. Maybe this should be a feature request?
I think the reason Name isn’t accepted as an Account identifier is because it’s not unique. I think using Email would solve your problem here because it uniquely identifies an Account. However, I haven’t run into this issue myself.
I’d recommend taking a look at Importing Connections and to quickly answer - yes the Name field will likely cause issues. I just updated the warning in that article to make it a little more clear:
If you’re importing and setting connection values to multi-part fields, such as Name & Address fields, you’ll get inconsistent results or the values won’t be set at all.
We suggest you use other unique fields such as email address or an ID field as your display field in the connected object and map to that value in your import. This can even be done temporarily until after you have completed your import and the records have indexed.
Hope this helps! And please reach out to our support team directly if you continue to run into problems.
Thanks for adding that to the article, I think it may help future Knackers. Something I thought about is that rather than select the display field within an object’s settings, it might be useful to be able to select an independent display field as part of a connection. Maybe a feature request?
Yes that’s a great feature request! We’ve actually begun some discovery on something like that, and this import scenario is a useful one, thank you for bringing it up.
Please follow these topics as I’ve already started some conversations on what this could look like: