Need ability to delete users from User Management

Hi @darkknight  User deletion is not supported for now , will making user inactive work for you ? 

No… because the username is identical, and that is my upsert key.

@darkknight Can you  please let us know the details of problematic  users or is it possible to share the error file?

What sort of details?  Basically I have two users with different SFDC IDs who have the same SFDC Username.  Because the SF Connector User job uses SFDC Username as the upsert key it’s getting confused and saying there are multiple users that match the criteria.

@darkknight If these numbers are not big, is changing username in user mgmt page(we can edit the username in GS System)  and retrying helps?   

@darkknight did you get a chance to view comments from @uday 

I currently have 90 users that fit this.  But for some reason it keeps happening - we end up with duplicate records that have the same user name.  And I have no idea why.  

@darkknight  Could you please share the details of those users, we will see how we can get these fixed for you.

@uday I would love to - although Support told me this:  “The reason we cannot delete users is that we have several dependencies( in the UI and on the backend) created when a User is created and deleting a User would involve trying to clean them out from everywhere which sometimes gets messy. I agree with duplicates are bad and for that reason, we ask customers to be careful while ingesting data to standard objects, not include duplicates as deleting them brings in more complications.”

Is that accurate?  Seems to me it should be fairly simple to delete duplicate users.

@darkknight  Yes thats correct, deleting user may have more dependencies and evaluating dependencies at every user is not an easies way.

Yeah, we were brilliant and accidentally loaded 620 user profiles from SFDC. We only need about 20. Would be nice to be able to remove the ones we just added accidentally. We could set them all to inactive, but I’m still going to have a list of 640 users.. and finding active ones without knowing their names would be challenging.

Hi @jochle These users might have dependencies in GS tool, if we delete them we will loose the references. 

Yes, but they were just created, so they shouldn’t have any impact to the system if we just remove them right away? They don’t log in, they aren’t even real users. These should be things we can remove.

I am having a similar issue and support opened this community post on my behalf. I feel as though there are two possibilities here: Give us the option to delete users (which GS seems unwilling to do) or change the upsert key to an ID field rather than a Username field considering Usernames can be edited.

We have been living with a similar issue and it has been really hurting us. Recently there were 9,000+ users that lived in our SFDC database that were brought over….. they are not people we need in there at all. We were managing it just fine in SFDC but now that they live in Gainsight it’s causing massive headaches. We never used the users at all. We verified they were never used. They are clogging up our internal stakeholder tagging. We only have an org of about 150 users and now it shows that massive number. GS refuses to delete the users we will never and have never used. I understand there “might” be other dependancies that those users “might” impact…… but really not our fault those users got created in GS but now we cant get rid of them? We asked to have them deleted right after they were made and still were told no. Now several weeks have passed and our adoption from our CSM team has decreased because they are having more issues tagging people and combing through the multiple results. A temporary “workaround” was found but we do our best to maintain data cleanliness and now every time I have to search or update a user I am greeted with 9,000+ fake useless users. We get you might have had issues with customer in the past deleting users they were unaware had dependancies and causing issues but withholding this capability even when the case is strong does not seem like a good idea. It makes it really hard for an admin to champion GS to end users and leadership when you have issues like this you have to explain and justify. 

+1, we have a bunch of users that were accidentally brought over from SFDC during implementation and it would be great if I could delete them myself instead of having to rely on a support ticket. 

Hello Everyone, 

Thanks so much for all your feedbacks. As such, there are two issues we need to address

1. Identify a non-username field as upsert key in SFDC Connector user sync job
2. Provide ability to delete users from Gainsight user management

We are in the process of designing a solution to delete users from GS. We intend to provide a “Mark for deletion” functionality in GS user management. Once marked for deletion, a user can be deleted if there are no references to those users in GS objects. User for whom there are references can be made inactive and those users will not show up when trying to tag in a Timeline post, assign CTA etc. The process of deleting users will be Async and will not be realtime. Please let us know your thoughts on this approach.

Thanks!

This is also an issue for our organization. We just need the ability to delete users entirely. How is this not something that already exists?

Hi @PerryRogers19 as Sumesh indicated above, there are some complexities with user deletion, especially in cases where that user had created some Gainsight assets like Timeline activities, CTAs, changed health scores, etc. The team is working on solutions for this that won’t create downstream issues and we hope to have something deployed before too long. We recognize this as a very valid use case and need for most teams. 

@PerryRogers19 did you get a chance to view the comments posted here.

Is this still on the roadmap? Duplicate users continue to be an issue for our org. 

@cmultanen Yes, this is in the roadmap but we do not have any update on the timelines yet. We will post once we have an update on the timeline.

Adding my vote to this as we also need to use the SFDC ID as a unique identifier versus the username.

I’ve stopped syncing SFDC users because of this issue, it means manually adding them when needed, which is a burden but better than having erroneous data loaded that can never be deleted (and by that I don’t mean either option is ideal). 

any update on this? 

Seems a pretty common request