Importing Contacts that are related to multiple accounts

Hello - 

We're migrating a legacy home-grown CRM to Sugar (Ent V10.0 on-prem).  We're running through all the various imports, fine-tuning them before the production cut-over.

We've imported Accounts and grabbed the Account ID from Sugar to put it in the other imports.

We have CONTACT records that are related to multiple ACCOUNTS.  

The CONTACT import template has a column for a single ACCOUNT.  If we put the same CONTACT in the file with different ACCOUNT IDs, we get multiple records of the same CONTACT.  If we do the duplicate checking, it imports the first CONTACT but marks all the rest as duplicates.

I am aware of this article describing how to manually link CONTACTS to an ACCOUNT - https://support.sugarcrm.com/Knowledge_Base/Accounts_Contacts_Leads/Understanding_the_Accounts-Contacts_Relationship/.

It is a manual process.  I'm guessing we have to manually go into each ACCOUNT and link an existing CONTACT record.  But before we manually start linking a few hundred records, I thought I'd ask to see if there's a way via the import routines that we're just not seeing.

Thank you for your help.

Parents
  • ,

    Thank you both for your replies. I'll try to summarize the need so you'll understand our business case:

    We have several thousand customers (Accounts). Some of them are loosely affiliated with each other in a region - separate companies but sharing some services.  For Company 1 thru Company 10, John Smith is the I/T resource.

    If one of those customers calls and our support team needs to visit with their I/T resource, we want John Smith's Contact record related to each of the 10 Account records.  We don't want the caller to say, "John Smith is our I/T guy", have the support person look at all the Contacts associated with the Account, not see John Smith, and add a second (duplicate) John Smith.  

    We have those relationships in our existing legacy system.  As I mentioned, it's about 120-150 Contacts spread out across a few hundred Accounts.  It won't be the end of the world if we have to manually "Link an existing" Contact to each Account.  From what you both said, it sounds like that will be the easiest and least painful way to do this.  We don't want to go through the effort of custom modules, custom code, or other cases.  If this was several thousand contacts/accounts, we'd probably be more open to that.

    Thank you both for your help!

    Bob

  • That is an absolutely fantastic usecase which could be handled by a simple additional relationship between Accounts and Contacts. In your case I would create such a relationship as many-to-many because I think it can be possible that a customer has more than one IT-guy.

    So when you create such a relationship "IT-support" you will have a subpanel in Accounts and Contacts where you can add each of the supporting guys to any account. The many-to-many relationship automatically shows such links in accounts and contacts as you see in the following screenshots.

       

    Harald Kuske
    Principal Solution Architect – Professional Services, EMEA
    hkuske@sugarcrm.com
    SugarCRM Deutschland GmbH

  • Hi Harald,

    This particular case is indeed one that would push for a many to many relationship. But won't a custom relationship break some of the out of the box features? I'm thinking Sugar Connect, importing (OK, you provided a workaround for that one in another thread), etc? 

    Damien Pochon

    CRM & Digital consultant @ ITS4U Group

  • " I'm thinking Sugar Connect": Yes, , that's exactly the issue, as the OOTB relationship is used at so many places you never know which side effects can occur. So in most cases where additional fields are envolved an additional relationship-module would be the better choice. BUT with code to support the OOTB relationship, perhaps by copying the primary relationship to the OOTB relation tables. Detailed design must be done here.

    Harald Kuske
    Principal Solution Architect – Professional Services, EMEA
    hkuske@sugarcrm.com
    SugarCRM Deutschland GmbH

Reply Children
No Data