GDPR erasure requests - importing previously removed records

Hi Philippa Grover 

The emails are stored in the table email_addresses, which manage the email address it self and the information of invalid email and opted out.

The table email_addr_bean_rel implements the relationship between a record (Account, Contact, Lead etc) against a speciffic email address.

So lets suppose several differents records are related to the same email address which is set as opted out, it means all of these records will be marked as opted out for that same email address.

So when you are going to import a third part database the SugarCRM application will double check if the given email address does exist and then it will assign that email address to the new record. Note that SugarCRM will not undo the opted out flag of such email on importing, this way if you try to send an email marketing campaign to a new record whose email address had been previously opted out the SugarCRM will refuse the send the message to that one.

But if that new Person/Company has some other email addressed not opted out then he/she will be targeted without big deal.

I hope I could answer your question.

Kind regards

The way erasure requests will work in Sugar is a bit different than delete. A data privacy manager will be able to select specific personal fields for erasure. What then happens is that the value of those personal fields is erased. On the front end, you will see "Value Erased".  The record itself is not removed, so that we can retain relationships with other records such as calls, meetings, tasks etc. 

If an email is marked for erasure, then the email value is also erased from the table. 

If that email address comes in again as a new lead or contact, then the new email will be created as a new record. There is no mechanism to tie in the new incoming email address to the previously held email address, because the previous email record was permanently erased. 

Hope that helps. 

Here's my understanding:

If I ask you to REMOVE my data, you have to remove it completely, you will have no reference whatsoever to whether I ever existed in your system or asked you to delete me. I become a total stranger.

Now, if you get my name from a list, the provider of the list also has to provide you with MY EXPLICIT CONSENT for the data contained in the list to be gathered for the PURPOSE of SHARING it with you (Opt-In Policy). Therefore you have EXPLICIT consent FROM ME (via the company who provided you the list) to use that data and you can add me.

If you don't have that documented consent you can't add me to your system. The default is DENIAL of consent.

In other words, you should NEVER AGAIN get just a list of random people that you bought or otherwise obtain without the explicit approval of the people whose information is contained in that list.

Makes sense?
FrancescaS

Your understanding is correct. If you don't have explicit consent, data should not be entered or imported into Sugar (or any other systems). If you have the necessary consent, you can record it in the respective module. We have added some fields to record consent, which can be customized as per the controller's processes. 

The only reason you would ever import without someone's consent is if there is a valid business legitimate reason, otherwise you need explicit consent. Customers who are processing data should consult with their legal counsel to determine lawful basis of the data they process. 

Your understanding is correct. If you don't have explicit consent, data should not be entered or imported into Sugar (or any other systems). If you have the necessary consent, you can record it in the respective module. We have added some fields to record consent, which can be customized as per the controller's processes. 

The only reason you would ever import without someone's consent is if there is a valid business legitimate reason, otherwise you need explicit consent. Customers who are processing data should consult with their legal counsel to determine lawful basis of the data they process.