How do you guys handle contacts who have left a company but you do not want to delete them because of the history?

I never advocate that my customers delete data from Sugar, as it would break the audit trail. Instead, I recommend exactly what Patrick McQueen suggested above. We create a simple dropdown called "Status" or something on Contacts, with two values:

• Active
• Inactive

The default value of this field is set to Active, meaning all newly-created Contacts are Active. We then create a standard filter on Contact list views to exclude all Inactive Contacts. In addition, all reports are based only on Active Contacts.

Finally, we ensure that the Contacts subpanel within Accounts displays this status, as it makes it easier for the end-user to be sure they're looking at the right people.

Hope this helps!

Hi Jesica Trejo,

we are using a checkbox for this purpose. 

But for me the more interesting question would be, what to do afterwards, if the same person starts at a new company and reaches out to you again? Do you knowingly create a duplicate contact on the new company to not loose the information connected to the old company? Or do you have the possibility to use the same contact again and show its previous relations?

At the moment we are going with the first option as it's easier, but I don't quite like creating duplicates on purpose, even if that case doesn't happen on a daily basis, but only occasionally....

This is where Sugar falls short, looking at the out-of-the-box functionalities. The standard model treats the Contact as a 'natural person', while it actually should represent a role or position for a natural person. This person can have multiple roles (for the same or different Accounts) and the roles this person occupies, might change in the future. So with the out-of-the-box functionalities you actually get duplicates or lose data or historical insight.

In our daily business with customers, we face this issue often and since (in our perception) it still is not solved correctly in the core of Sugar, we created a generic customisation (we added a custom module and changed the structure a bit), for this which we offer to our customers, which are actually facing the challenge of a person having multiple roles or have a hight turnover rate. 

This is where Sugar falls short, looking at the out-of-the-box functionalities. The standard model treats the Contact as a 'natural person', while it actually should represent a role or position for a natural person. This person can have multiple roles (for the same or different Accounts) and the roles this person occupies, might change in the future. So with the out-of-the-box functionalities you actually get duplicates or lose data or historical insight.

In our daily business with customers, we face this issue often and since (in our perception) it still is not solved correctly in the core of Sugar, we created a generic customisation (we added a custom module and changed the structure a bit), for this which we offer to our customers, which are actually facing the challenge of a person having multiple roles or have a hight turnover rate.