Skip to main content
'

Most of the credit for this post goes to @sdrostgainsightcom, who shared the bulk of these steps with me during an office hours session a while back. I’ve since added a couple notes of my own, as I’ve been dealing with a few user cleanup projects in our org. I’m hoping this can be a helpful guide for anyone else going through this process (and selfishly, I’ll probably need to reference this myself in the future!). 

 

  • ISSUE: When a username is changed in Salesforce for a user that is synced into Gainsight, the User Sync job, which uses the Salesforce Username as the upsert key by default to maintain the connected Gainsight User, creates a new user record: 
    • The new Gainsight user has the SAME Salesforce User ID, but has the NEW username from Salesforce – this user will not reflect the applied Gainsight license, etc. since that info remains unchanged on the original user record with the now out-of-date username.
    • This original Gainsight User will not be updated by the sync job going forward because the username no longer matches the username in Salesforce, so changes in Salesforce to Last Name, or Title, etc. get carried to the newly-created user record that was created.
    • The original Gainsight User, however, is the record that should be retained and re-linked to the source SFDC user, as that record has been assigned Gainsight license and permission bundles in Gainsight and is associated with owning CTAs, etc.
    • Note: This would all be much easier if Gainsight allowed SFDC User ID as a valid upsert identifier, which it does not as of today. 

       

  • PROCESS TO FIX ISSUE – STEP 1: IN USER MANAGEMENT, ON THE NEWLY-CREATED USER WITH THE NEW USERNAME AND SAME SFDC ID:
    • Update the First and Last name to Duped SFDC User (or similar)
    • Update the username with "dupe." in front so you have "username@userdomain.com"
    • Set the user to Inactive
  • STEP 2: ON THE ORIGINAL USER RECORD THAT STILL HAS THE OLD USERNAME
    • Update the username to the NEW username that''s in Salesforce.
  • STEP 3: GO TO "GAINSIGHT SHARING" IN THE ADMIN SUITE, AND THEN TO "USER ATTRIBUTES" SUBTAB. CLICK "REFRESH USER DATA" AND ALLOW THE REFRESH TO FINISH BEFORE MOVING TO THE NEXT STEP.
    • Note: For SFDC edition, this can be found under Administration > Gainsight Data Permissions
  • STEP 4: WHEN USERS ARE UPDATED AND THE USER CACHE IS REFRESHED:
    • Go to the Salesforce Connector and run the User Sync job manually for "all data" (or if this is for a single user that was changed recently in SFDC, set the date parameters to capture it).
    • Confirm that the ORIGINAL, VALID User record in Gainsight for which you have updated the username has been updated by the Connector, and the new user that you had changed to "dupe.user" was NOT updated (Modified Date in User Management will show what was written to by the User Sync).
  • STEP 5: ONCE THE SYNC IS UPDATING THE CORRECT USER RECORD, OPEN A SUPPORT TICKET FOR FINAL STEP:
    • Create report of users STARTSWITH "dupe." Show the GSID, Username and SFDC ID fields.
    • Dump to a CSV and open a ticket with support requesting that the SFDC ID on the attached usernames be set to NULL. This will take care of any dependencies on connector jobs in the future, etc.
'

Credit to @rob_culross for noting that this situation will change with Release 6.32!

 


Now if we could only have a user MERGE capability since we are not allowed to DELETE erroneous users…. hmmm 🤔


Erroneous users causing me so many problems - wish we could merge


Question:

The duplicates referred to here, are these the same users who fail to get in JO Mass email outreach programs due to the failure reason  - “Participant with unique criteria already exists” ?

 

we do not have duplicates in our SFDC database where we pull our query builder - but when we send out emails i always get a short list of participants who fail to get in the program. Just wondering if this is the same duplicate issue mentioned above. 


Question:

The duplicates referred to here, are these the same users who fail to get in JO Mass email outreach programs due to the failure reason  - “Participant with unique criteria already exists” ?

 

we do not have duplicates in our SFDC database where we pull our query builder - but when we send out emails i always get a short list of participants who fail to get in the program. Just wondering if this is the same duplicate issue mentioned above. 

 

This is a different issue referring to duplications on the User object.

It sounds as if your fetch is bringing in participants that may have already entered the journey. I would recommend checking the setup of your unique criteria or the query itself.


Thanks @duncan.young 


Reply