Details about this thread
  • State Not Answered
  • +1 person also asked this people also asked this
  • Replies 8 replies
  • Subscribers 314 subscribers
  • Views 2812 views
  • Users 0 members are here
Related content from around SugarClub

Importing Contacts that are related to multiple accounts

Bob Bundy

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
  • 0 Sugar Employee Badge

    I totally agree to 's post. We often have the requirement that customers want to have such a many to many relationship between Contacts and Accounts. But mostly it is not only the relationship, there are special requirements for this relationship, like the type of employment, the function within that company, titles, even start and end dates or just the fact that somebody left a company. So it mostly depends on the usecases in the requirements how this could be solved.

    The accounts_contacts relationship itself is a many to many relationship but Sugar code  brings it down to a one to many relationship. If a customer needs the many to many thing there are two possible ways to solve that:

    1. extension of the existing relationship with new fields. This was done by partners already in some version 6 implementations and it is a very stony way as the out-of-the-box relatiosnhip has certain hard coded workflows which can change from version to version.

    2. creation of a new realtionship module which holds the relationships itself as records which can be edited.  This was done by partners too and it requires a very exact design to make sure that the interaction with the existing relatonship does no harm to the new one and vice versa.

    Both ways are doable, but both require detailed analysis and good developers for the implementation.

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

Reply
  • 0 Sugar Employee Badge

    I totally agree to 's post. We often have the requirement that customers want to have such a many to many relationship between Contacts and Accounts. But mostly it is not only the relationship, there are special requirements for this relationship, like the type of employment, the function within that company, titles, even start and end dates or just the fact that somebody left a company. So it mostly depends on the usecases in the requirements how this could be solved.

    The accounts_contacts relationship itself is a many to many relationship but Sugar code  brings it down to a one to many relationship. If a customer needs the many to many thing there are two possible ways to solve that:

    1. extension of the existing relationship with new fields. This was done by partners already in some version 6 implementations and it is a very stony way as the out-of-the-box relatiosnhip has certain hard coded workflows which can change from version to version.

    2. creation of a new realtionship module which holds the relationships itself as records which can be edited.  This was done by partners too and it requires a very exact design to make sure that the interaction with the existing relatonship does no harm to the new one and vice versa.

    Both ways are doable, but both require detailed analysis and good developers for the implementation.

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

Children
No Data