User Connector job should allow SFDC User ID to be key field

Related products: None

When a user’s username is changed in Salesforce, it produces a duplicate record in Gainsight’s User table because the User Connector job doesn’t let you select the SFDC User ID as a Key field - the only immutable field on the SFDC User record.

As a result, this is causing duplicate records to be displayed, exported when using SFDC User ID as a lookup value on dashboards, queries, etc.

Even though, yes, a SFDC Username must be unique - it can be changed on the same SFDC record.  The SFDC User ID cannot.  It should be the Key value.

 

Hello @darkknight, thank you for your post. Looping in the Product Manger to look into this and get back to you. 


yes! Similar puzzlement to why Person upsert key can only be an email.


YES. So annoying to have to ensure the user email is changed on both SFDC and GS ends at the same time in order to avoid this. And then no way to delete the now invalid dupe user! Causes trouble in tagging and lookups.


@darkknight @bradley @gunjanm,
Thanks for writing in! We are looking into it - if we can enable SFDC User Id.


@Neha Gupta Support told me yesterday that in Horizon Connectors, we'll be able to select SFDC User ID as the update key, which is great... but then they also told me that any changes made to the SFDC Username field will not get synced to Gainsight and will have to be made manually.  This doesn't quite make sense to me because if a field is editable in Salesforce, it should be able to be synced via Connector.

cc: @bradley @gunjanm 


@Neha Gupta Support told me yesterday that in Horizon Connectors, we'll be able to select SFDC User ID as the update key, which is great... but then they also told me that any changes made to the SFDC Username field will not get synced to Gainsight and will have to be made manually.  This doesn't quite make sense to me because if a field is editable in Salesforce, it should be able to be synced via Connector.

cc: @bradley @gunjanm 

Maybe it’s related to the current behavior where the User connector only imports data meeting the filter criteria once, and then doesn’t action on it even if it’s updated e.g. If you pull in SFDC users with Active = TRUE, they aren’t removed if ActIve=FALSE.

Unless I missed something, the connector doesn’t look at new information period, which is equally puzzling.

 

Reference: “Note: When users are synced for the first time from Salesforce to Gainsight, the Status (Active/Inactive) of them is updated in Gainsight as per their status in Salesforce. If the status of the users is changed in Salesforce, it will not be updated in Gainsight.”

 

Source: https://support.gainsight.com/Gainsight_NXT/01Onboarding_and_Implementation/Onboarding_for_Gainsight_NXT_in_Salesforce/Login_and_Permissions/Sync_Salesforce_Users_to_Gainsight


@darkknight @bradley Thanks for mentioning it! 

We are internally working upon to support updation of usernames or any other fields in user object if SFDC User Id matches. Will keep you posted about the ETA.


Curious if there are updates on a solution here - we’re fixing the same problems over and over - unable to correct user IDs and appropriately assign CS teams..


@Neha Gupta Support told me yesterday that in Horizon Connectors, we'll be able to select SFDC User ID as the update key, which is great... but then they also told me that any changes made to the SFDC Username field will not get synced to Gainsight and will have to be made manually.  This doesn't quite make sense to me because if a field is editable in Salesforce, it should be able to be synced via Connector.

cc: @bradley @gunjanm 

I’m facing the same issue. There is a massive update to both usernames and emails coming for our users, and when I tested in Sandbox, I noticed the same issue where Username did not get updated when I set SFDC User ID as an identifier. 

 

This will be a major issue for us if it doesn’t get fixed soon. Also, why does the connector even allow me to select SFDC User ID as the upsert key if it’s not going to work properly? This is one of those things that frustrates us admins to no end.


Oh, and we can’t do this in the Rules Engine either. “Username has to be set as identifiers”...why??

 


@Neha Gupta any update?


@shannon_olsen @spencer_engel @darkknight we are in the middle of testing all the use cases when SFDC User ID matches both through Connectors and Rules Engine. The use cases include updation of any user attributes that got changed. Will keep you informed about the ETA.


Oh, and we can’t do this in the Rules Engine either. “Username has to be set as identifiers”...why??

 

FWIW this still appears to be the case in our sandbox instance, which is on Horizon Connectors 2.0. You can select SFDC User ID as an identifier/upsert key, but not by itself. You must also include username which seems to be back to square one.


I was hopeful that I had found a workaround to this issue thanks to @sdrostgainsightcom, who suggested populating “External ID” with the SFDC User ID value and using it as my lone external identifier. This seems to work well at first. However, today I learned from support that usernames are excepted from being updated with this workaround, which means you cannot update usernames automatically in the system at all, whether via the connector or via the rules engine. This is causing us a lot of headaches. 

 

Also, there is a duplicate idea post for this that should be merged. 

 


Oof - yes, @spencer_engel -- this is something that I came to understand, and understand why, it’s done this way -- even if the Gainsight user’s username is first generated from the connector to be the same as the SFDC username, it then becomes an independent, Gainsight username . . . since users can be enabled to log directly into Gainsight vs. logging in via SFDC NXT tab, we don’t want username, and username/password combos changing.  It made sense to me once I pictured trying to convince a Salesforce admin that if I change a username in Gainsight, the SFDC Username should be automatically changed to match -- same request in the opposite direction -- and knowing what the SFDC Admin would think.

THAT SAID, with so many Gainsight instance linked to an SFDC instance that is the only way the end users can log in, a utility, or checkbox, for a 1-time update when needed would help.  I just know that architecturally, changing a username isn’t without downstream effects or lag time, etc.


I was hopeful that I had found a workaround to this issue thanks to @sdrostgainsightcom, who suggested populating “External ID” with the SFDC User ID value and using it as my lone external identifier. This seems to work well at first. However, today I learned from support that usernames are excepted from being updated with this workaround, which means you cannot update usernames automatically in the system at all, whether via the connector or via the rules engine. This is causing us a lot of headaches. 

 

Also, there is a duplicate idea post for this that should be merged. 

 

Thanks for the pointer @spencer_engel.

Merging is not possible on the current technology, so I’ve given a shoutout to voters to come and vote this idea up. cc @Ritesh Sharma , @Neha Gupta  


Oof - yes, @spencer_engel -- this is something that I came to understand, and understand why, it’s done this way -- even if the Gainsight user’s username is first generated from the connector to be the same as the SFDC username, it then becomes an independent, Gainsight username . . . since users can be enabled to log directly into Gainsight vs. logging in via SFDC NXT tab, we don’t want username, and username/password combos changing.  It made sense to me once I pictured trying to convince a Salesforce admin that if I change a username in Gainsight, the SFDC Username should be automatically changed to match -- same request in the opposite direction -- and knowing what the SFDC Admin would think.

THAT SAID, with so many Gainsight instance linked to an SFDC instance that is the only way the end users can log in, a utility, or checkbox, for a 1-time update when needed would help.  I just know that architecturally, changing a username isn’t without downstream effects or lag time, etc.

Fancy running into you in the wild @sdrostgainsightcom!

We recently made this change and were unaware that the Username would not be updated. I understand why now based on your post. Shouldn’t the product support users that only login via SFDC? This is a problem affecting all SFDC instances just to support login via NXT. It seems like it could be solved by functioning differently for instances that have System DB(NXT) auth disabled?


Hi All,

Now we can select SFDC User ID as an identifier in User object in the direct mappings for SFDC Connector. It will update all the user fields except username if there is any change in Salesforce. Please reach out to support if there is any bulk update required for the usernames. Please let us know if there are any open questions.

Thanks and regards,
Neha