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     

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! 

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?

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!

@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

Hi @Kartheek :

From my perspective with a quick internal sense check:

• What to do with tasks, success plans, CTAS etc.:
  • We almost always have someone on the account (either a pool of resources or an individual) so I would say ideally, assigned to a resource pool or the new person on the account. Maybe we could create a resource pool for these cases, even though people should clean-up their To Dos before leaving. If there’s a lag between person inactivated and new assignment, reassign to the admin (but I would prefer the resource pool). 
  • When there’s a lag: assigned to the admin, but with a special status
• How often do you see users moving to inactive?
  • When someone leaves the organization (CS)
  • When someone from Sales that is an internal collaborator loses SFDC access (either because they left the org or some other cause for losing SFDC access)
  • When sometimes gets horizontally promoted - though at this point it doesn’t require deletion, just inactivation

I don’t know how frequent that is but that’s the same rate as the employee churn rate for the organization, which may differ department to department and month to month.