Handling of deactivated users

[Jared_Mauch]

Do you tend to keep and leave deactivated users in their home groups and teams or do you remove them? Until now, we've kept deactivated users in their home groups and teams. We've got about 400 deactivated users in our instance, and I'm wondering if we should create a deactivated users group and move them there.

[WibkeKu]

We have created a deactivated users group that they get moved into and I also created a filter for active users and deactivated users. Makes it easier to look at because I really do not want to see all the deactivated users all the time.

[Jared_Mauch]

Using a filter while viewing groups helps. Sadly, some of our users forget that they can apply filters in many cases. It's those users that I could see asking why there's a lot of deactivated users listed in their group and that moving the deactivated users to their own group would help with.

[Nijs_Gold_23]

In that case, you can make the Filter default in the layout template and also educate the users on Filters, Views and Groupings functionality which will be helpful in day-to-day work.

[skyehansen]

I tend to leave deactivated users the way they are. The work that they did usually counts towards these objects in some way, so I'd have to hear from the leaders on why they would want the accounted work to disappear.

I also advocate for users to be deleted. If a user has never logged in, or if a user has never owned objects in the system (submitted requests, been assigned to an object, uploaded files, created objects), we don't tend to allow them to clutter the system.

[Jared_Mauch]

Most of our users have either been assigned to objects, submitted requests, or reviewed and commented on proofs. The only group of users who haven't logged in yet are these ones with an unregistered label next to their names. They seem to be created in the system daily.

[skyehansen]

You may have a different use case than ours.

1) Users in our system may log in and have a "free account" created through SSO, so there are a lot of "mistaken" logins, where for example, users mistake Workday and Workfront (next to each other on the list).

2) I usually try and keep the system cleaner. As workflows age out or get abandoned, we often delete the objects representing the workflow. e.g. a workflow may have had teams, forms, templates, and projects, issues and tasks created. But if through a reorg, the working team is laid off, all of these objects become redundant. So we first delete the projects, issues and tasks. After this, templates, teams and forms (as an example) also show up as being "unused" since we deleted everything using them. Additionally, users start showing up as having a "zero footprint" since we deleted everything that they had been assigned to. It is at this point where you'd have an opportunity to start deleting users.

I have inherited several instances now where this has been the case -- running reports to discover that it has been some years since particular custom forms were used, or discovering that they were never used (instant delete, and if it has been years since they were used, I request the governance team to make a decision for deleting it). After a brief spate of deletion, I usually find user profiles can then be deleted. Your mileage may vary.

[Nijs_Gold_23]

I would prefer to keep their team/group data as is while deactivating the user profile, not to loose track of what they have worked on so far.