CS User Delete - PII details

v relevant topic and interested in what some of our GameChanger friends have to say:

@Molly.McQ, @TMaier, @romihache, @darkknight, @Stuart     

I think the privacy implications of internal users (former employees) are different than what we deal with when we handle customer data. The email address on file for these users would presumably be a company account, and not a personal email, and I’d argue that activities completed in the course of employment are not subject to the same ethical standards as data gathered from non-employees. 

That being said, a de-activated callout for internal attendees, timeline activity authors, CTA owners, etc, would be extremely nice for practical reasons. Being able to quickly see that the CSM assigned to an account has been deactivated? Wonderful. Seeing that the owner of a CTA is deactivated? Delicious.

Completely agree with @TMaier on this. Having a reference of the inactive user and their deactivated status on past activities offers our team greater insight that can be used as needed in evaluating activities and behaviors of deactivated users. Understanding specific user behavior and how this relates to the customer journey, sentiment, etc., definitely has value! 

Absolutely agree with both.
Showing the status of the user will be very valuable.

I would like to add @alizee to this thread. She’s the first to call out GDPR implications when discussing things in Slack/Community.
 

Looks like a consensus from everyone on this topic so far that keeping the user and showing as deactivated is the winner.

If SSO is enabled for the tenant, I’d like to think the majority of the changes would cascade down to Gainsight from the IdP, however I’ve not yet encountered licensed user attrition to confirm what changes would occur from the IdP, and those required directly in the Gainsight UI.  Can anyone else confirm?

Stuart, nothing changes in Gainsight due to changes in the SSO mechanism - you still need to offboard those users through the Gainsight UI which is a little bit of a pain. It would be super if we could automate this process somehow - either through the CRM connection or directly through the SAML/SSO integration.

So either of these paths would be acceptable to me...

SSO Update > SFDC Profile Deactivated > GS User Deactivated (license recovered)

SSO Update > GS User Deactivated

Hi all,

Thank you for tagging me @romihache 🤙

I generally disagree with the survey consensus:

1. An employer can only hold onto employee details for so long, and keeping the first name / last name forever doesn’t do the trick.
2. There are employee DSRs, and when they occur, they are most often way nastier than customer DSRs, we need appropriate means to respond.
3. First name and last name are personal data - the users with the same name theory doesn’t apply to all because some of us (the majority in fact) have unique names and if my name is somewhere, it’s personal data since there’s only one person with my name in the world AND the name is associated to other information that makes the user identifiable. It’s more frequent for an employee not to have a homonym in a company than to have one. I don’t understand this assumption.
4. Evaluating the behavior of a gone user - not sure how that fits under legitimate interest? Clearly very arguable in some geos.

Last but not least: Gainsight is a sub-processor of its customers when it comes to employee data and customer data. There’s an element of allowing customers to comply with local regulation required in a SaaS context. And let’s remember: when it comes to DSRs and data protection, the regulation that matters is that of the data subject’s country of residence whose data is processed, not that of the processor. 

However, I agree with the idea of flagging the status in the different areas (beyond user management).

Thanks!

You are welcome @alizee 😊
Your insights regarding GDPR are extremely valuable!

@TMaier @Molly.McQ @alizee @Stuart @romihache 

Thanks everyone for your valuable inputs here. Yes, we will consider on the case, of showing up the de-activity status in other application areas.

Just want to elaborate on the use case of having the delete user here and want to seek more opinion. As of today, we can make a user inactive, the entry will be in user management but will not completely remove the user in the user management listing

We have received requests to remove or delete users from user management, as it is becoming difficult to manage over time. The main reason being 

1. During user sync from salesforce or sandboxes, where filters are not properly configured, and by mistake  the entire users gets loaded to user management (which should not have added in first place), and so this leads to large number of in-active users in user management. In such cases, delete users can be considered
2. Also, other use case can be of employee leaving the organisation, 
   1. In case, the company wants to maintain the ex-employee, the user can always be IN-ACTIVE status and there is no need to delete the user
   2. In case, the company has GDPR or other local regulation requirements, and in such cases, removing the PII may be a need, in such case DELETE action can take up to remove the PII information

So, USER - ACTIVE > INACTIVE (reversible to Active) > DELETE (irreversible)

Extending on the point 2(2), on the GDPR, where user needs to be deleted,

• What are your thoughts on the tasks owned by him say CTAs,/Success Plans, does that need to be moved to Manager, if not Super Admin - When delete action is performed, can this be automated that all the tasks owned by him/her will always be moved to Manager by default, - (Note, here i am not talking about the timeline activities or other modules, where he/she has created or modified, such references will be still be with user, probably saying Deleted User going forward)
• How often do you see that users moving to In-active state, is it regular or occasional

@Kartheek I’ll elaborate a response and come back in the thread with it, but probably on Tuesday if that’s OK. Thank you for taking this ask to the fore :).