Contact Management 2020

Our Contacts typically tend to move around in the same industry, so odds are, when they leave one Company they'll show up later in another Account we service - which is why we'd like to retain any associated history. 

Over time, as users began to edit Contacts, rather than sending the info to admin, many fields were left untouched (which made them still "mailable," visible, etc), so I'm looking to make this more efficient (because all teams use Sugar for all things, Contacts have to be editable - not sure a Role can fix this one).

QUESTION: could this work?

If all Users had to do was replace the Account name with one established for this sole purpose i.e.<Contacts Moved Co.> (versus being orphaned or left on the account), this could all easy filtering to either clean up records or searching for a contact before creating.  Is there a better method? What is the considered best practice for removing or disassociating a Contact no longer at a Company, but whose information is worthy of keeping? 

Is this true?  

once removed from the Account, any linked records the Contact had remain at the Account level and Contact level until manually unlinked from both, record x record, no matter the Contact's Account name? 

Brieanne Rowe user administration 

#contacts account management contact management crm administration sugar q2 2020

  • Practice we use is to have a Contact Status which when changed to a certain value, triggers BPM to update a range of fields. There was a couple of limitations atm with BPM - e.g. not being able to change the email address to invalid. So we have BPM create a task that is assigned to a specified user to tidy that up.

    When the contact turns up somewhere else, create a new contact by copying hte existing contact.

    We do this because it retains history but most importantly keeps history for a contact confined to when they were with an Account. If you just use the existing Contact and relink it, then the history is all together even though they worked at different places.

  • Thanks Greg Barrass - so to clarify:

    • when you copy the existing Contact, it copies the related records (histories) as well?
      • I'm just worried about our data :/ 10y in Sugar, 20K Contacts,  5K accounts, 100K archived emails
      • ...and about the BPM - need, want, wish there were ready to go templates for Enterprise! I believe this should be a standard feature  for the commoners. Brieanne Rowe


  • When you copy the contact, the system does not copy the history. The history stays with the original contact.

    SugarCRM have provided some good example BPMS in the KB section of the Support Web Page, but I do agree there is a learning curve and I had to put quite a bit of work to get comfortable with BPM.



  • Thanks for the clarification and info

  • As Greg has said, you want to mark keep the contact history with the previous account. Thus copying the contact to a new record, and updating the information there is a key part of the process. We also mark the first contact record for that person as inactive, email as inactive. We've built our own customisation to make this stuff easier as BPM hasn't yet been able to do all that we need to do for this.


  • To manage the history and data of resigned people, we usually use the following approach.

    We add the special (technical) account Unknown Company and move all resigned contacts o this account. It happens when contact marked as "Resigned" or manually. The special process automatically clears all nonactual personal data (corporate email but not private, work phones, work address, status, etc.) when a contact links with the "Unknown Company."

    Contact stays there until we know a new place of work. As soon as we knew, we move the contact to a new company with a detailed history and fulfill new personal data.

    Besides, we save the history of the movement from company to company as essential events in the TimeLine Events that are related to contact and appropriate accounts. The set of contact important events covers many aspects of relationship history, not only changes places of work.

    It helps new assigned to develop relationships find in our company someone, who can help quickly to refresh relationships with this person.

    This the main idea. Usually, this approach is tailored to the particular needs of a specific company.

    If this approach might be of interest and you would like to get additional comments, please feel free to contact me directly.

  • All of these suggestions are workable, and for some customers, I've recommended them too. It really comes down to your access to skills which can implement, and the usability demands upon your users, i.e. is it straightforward enough for them.

    Another suggestion to consider:

    • Do not duplicate contacts - just change the Account name.
    • Create a new custom module (m:1 to Accounts, m:1 to Contacts) called "Employment History"
    • Use logic hooks to populate data into this module when a Contact changes its Account from CompanyA to CompanyB. You can use the opportunity to set things like title and dates etc as well.

    In this way, when you engage this Contact, you are literally seeing everything you know about your history with them - including conversations when they were with their past employer. Given your contacts are staying in the same industry, I'd posit that this intelligence is of value to subsequent conversations.

    When you view a person, you see a history of all the companies they've worked at while having a relationship with your organisation.

    When you view a company, you see a history (can become long) of all the employees who've moved through their organisation too.