[Ask from Customer] Load to Company Person - Email is required identifier

  • 2 February 2018
  • 6 replies

Userlevel 4
-- Request from one of the Customer --

End users usually change their email addresses in client application somewhat frequently. They are bringing their unique ID into Gainsight MDA from Segment, and would like to update email on the Person, but Load to Person and Load to Company Person force email as an identifier.

They want to use their External ID so that email can be updated. Email is not a good unique identifier because it changes too often. 

Is there any alternate approach to achieve this or plan to handle via Load to Person / Company Person rule actions?

6 replies

Userlevel 4
Badge +2
Great point here Hitesh, I am curious what the resolution will be.
Userlevel 6
This is definitely in the direction we are moving with Person Model. I'll keep you posted on how this can be done using the config screen that we are planning to build it in the subsequent release

Cameron - There is an external ID that will be used for the resolution and Email ID would change over time for a person as I understand
Userlevel 7
Badge +2
Hi Hitesh, I'm curious as to the challenge you mentioned where end users change their email addresses 'somewhat frequently'. Can you explain that a little bit, as with the possible exception of someone getting married and changing their surname, I can't think of very many reasons why someone would change their email address often.
Userlevel 7
Badge +3
This came up in support. Basically, there was a person that was loaded at some point and then the email changed which resulted in a duplicate record based on the email. Because of this, email to timeline posted to drafts instead of the 360 page. In their instance they just want to use contact id as the identifier.

Userlevel 3
Badge +1

I am running in to this issue as well. With two different use cases. 


We have a two-way sync running between SF Contacts/Leads and GS Persons/Company Persons - we’re using the rules engine (rather than connector) for this so we can filter which platform was updated more recently and load the changes to the other platform to keep them both in sync (fingers cross for 2-way real-time sync…!).

If an e-mail is changed in SF (maybe it was put in wrong originally, or an individual has an update to their e-mail, like their surname) it creates a new record in GS rather than updating the original one’s email field. 

For the sync the other way (GS -> SF) we use the SFDC ID as the identifier. If there’s no SFDC ID then it’s newly created in GS and is therefore inserted into SF.  But if it has an ID and the email is different it will simply update email for the record in SF. 

But because of the SF->GS issue we now have two records in GS with the same SFDC ID, which means either of them could update the record in SF - causing incorrect data. 


We need to delete records in the Person/Company person object if a customer of ours withdraws consent due to sub-processor agreements we have in place for PII. 

As we’re unable to delete records I instead wanted to anonymise them by setting all fields to null, and then would do a manual deletion of these records on a monthly or quarterly basis (but if it doesn’t get done there’s no problem as all data is blank anyway). This is working fine for a custom object but I’m unable to do the same for the Load to People action as e-mail is a required identifier, so I can’t also set it to null. 


In both of these cases we would need to use the GSID as the identifier.  

I’m also curious with the recent update where Email is no longer a required field for the Person object how would someone update a record with no Email via the rules engine if it’s still a forced identifier? 

Userlevel 6
Badge +4

That’s how I’ve done in the past as well @HollySimmons. But definitely not an ideal solution. It would be great if we can adjust the email identifier as well because bad data entry on emails seems to be common at many companies. I totally understand why GS would want to keep it as the identifier so that there are no duplicate emails but it is limiting.