The function that creates a contact profile from a candidate profile needs to be improved. In the old version, when converting a candidate to a contact, all the information would transfer over completely. Now, the information populates underneath each category in a light grey color, but not completely filling in the information. Unless you manually enter in all the contact’s information, everything will show up as blank when you download the contact in Excel. There almost is no point in having the option to create a contact from a candidate since you just have to manually enter all the information in anyways.
Thank you for your feedback!
In order to properly respond, it’s important for us to paint a picture of how we got here and why the candidate/contact linking works the way it does.
CATS was designed with unique candidate and contact record types. The idea behind this was that you will work with people to hire them and you will work with and prospect clients in order to get work from them. From that perspective, we always recommend that, while a candidate and contact may ultimately be the same person, you keep the personal information of that person on the candidate side, and the professional information about that person on the business side.
Over time, it became apparent that our users wanted some way to tie those records together. That led to our “merge view” being launched, which gave a third view of sorts for those records. This allowed you to view all of the information about both records at once. Unfortunately, this approach led to a fair amount of problems. It had to do some magic to de-duplicate displayed information and we frequently received feedback that our users were accidentally overwriting important information when editing in this merge view. It was also very inconsistent on which data was copied across to the candidate/contact. We knew this first attempt had some issues.
When we set out to design Nala, we knew that we could take a fresh approach with linking candidates and contacts, and that’s what led us to what is currently in CATS. When doing this, we contacted many clients that had this feature enabled and asked them what they liked and disliked about the feature. With that feedback, our core goals were to continue to advise our users not to duplicate data across the item types, give an easy way to link and toggle between each record and display information from the linked record so that, at a glance, you can see the contact information from the other record type and help avoid duplication of data.
In addition of mixing personal and professional information on record types that are designed to be separate, the duplication of data across record types causes issues with duplicate detection and features such as email integration, logging duplicate activities across both record types.
It seems that you might share a different opinion of how it should work. Given the explanation above, can you let us know why you find it beneficial to duplicate data between candidate and contact records? And, if so, which information would you prefer to automatically copy over?
Thank you for this explanation, this is very clear and concise. Essentially, when linking a candidate to a contact, you are trying to avoid overriding existing contact data, or creating duplicates. This seems to be the best approach currently. The only reason it could be beneficial to duplicate/autofill data from candidate over to contact is when there is no current contact profile, which it sounds like is not possible with the current system. For me personally, I have large groups of people that are currently candidates that also need to be added as contacts, so with the current system it’s hours of manual entry. When adding a new contact who is already in CATS as a candidate, it would be convenient to do less work when inputting in their title, email, phone, LinkedIn, etc., since it’s already right there for you in CATS. I understand that’s not really the function of the merge view.