Details about this thread
  • State Not Answered
  • Replies 7 replies
  • Subscribers 309 subscribers
  • Views 1635 views
  • Users 0 members are here
Related content from around SugarClub

Contact Management 2020

Missy Brooks

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

Parents
  • 0 Sugar Employee Badge

    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.

Reply
  • 0 Sugar Employee Badge

    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.

Children
No Data