There is quite a bit of focus this morning on Technote 1316457 Removing users from Lotus Connections, according to the Technote:
Once a person is entered into the Connections system they should never be removed.
Now lets look at this a little deeper, except for in certain exceptional cases do you really want to delete users from Connections? I don’t think so, part of the value of Lotus Connections is to be able to preserve the tacit knowledge of employees who retire or otherwise leave the company, imagine you take on a new role in an organization and have access to your predecessors Communities, Activities, Blogs, Dogears, and yes even their profile to see who their colleagues were (which will probably differ from the formal org chart). The Technote goes on to reference SPR JHUG7DKS73 open to investigate this issue, and while I believe that there should be a way to remove a user if needed, it is not a showstopper to implementing Lotus Connections, user deletions should be the exception not the rule. In the case above where a division is splitting off, I am sure there are more challenges in splitting off a division then simply removing the employees from Lotus Connections, I am sure that it is just one more item on a list of things to figure out. Now when keeping employees who left the organization one thing that is apparent is that you might need to display a different subset of data for an active employee compared to a non-active employee who might no longer have such information as a Phone Number, e-mail address, reporting structure. This is supported in Lotus Connections you can add different profile types and customize them to display different data for different people, this is fairly easy to do. So yes, there should be a way to remove an employee, but I don’t think it is a showstopper.
Mitch, I wholeheartedly agree with you. It may be a good idea to have some type of removal, but a lot of things can get messed up. Consider that there is an enterprise activity in which 50 people are participating. If employee information is scrubbed when one of these people leaves, then what should be done with the information? In the backend database tables there are a lot of joins that occur to link the creator ID of a record to the display name that should be used. Making the activity still exist AND show who created it would require that information to still exist in the tables. I can’t imagine that it would be desirable to completely rid the system of user accounts. Even if blogs still existed for the user, that shouldn’t be a problem. There would, assuredly, be some information in there that may provide value to the company extending further than the employment or role of any employee.
I agree outright removal is problematic.
What about some inactive/active flag? Greyed text for the name?
Oh boy.. I’m going to have to figure out who wrote that. Perhaps, there’s no out-of-the-box way to remove a user, but it should be pretty straightforward with a SQL query… SQL DELETE .. FROM … and cascade down. Perhaps the Technote should say…”you can delete users from Lotus Connections, but you have to figure out the SQL query yourself”.. ?
When someone leaves a company that uses Domino, do you go into every discussion database and email they ever sent and erase their name?
I assure you that the same people that called it a “showstopper” would be shocked and appalled if someone’s public facing social communications were deleted after their departure.
In fact, come to think of it, they were { Link }
Pardon my stepping into the other area of your life, and asking what might be a dumb question.
At a certain point, do you start running into storage & performance issues? If you’re maintaining thousands of inactive records (assuming you haven’t dumped it all into a segregated inactive area) doesn’t that potentially get in the way of your active users and their experience? Having to bear the load of (to borrow a records management concept) thousands of non-current business records could at some point affect performance, couldn’t it?
I’ll hang up and listen to your answer.