Hi all,
Can I check to see what is the best practice to manage users (historic staff that may have left the organisation)?
Currently we lock the account, but users still appear when assigning cases/workflows, do you know if it is ok to delete a user or will this effect the historic cases created.
@jennifer.thorpe Having a means of separating locked vs deactivated would help you here. Locks can happen due to inactivity or password attempts vs a deactivation being a business led decision. Having an event based subset or even using a status field will allow you to create subsets with definition to limit to active users on relation selectors such as on assigning cases. You can then have your active subsets on forms but leave them off on searches (if you wish) so you can still search by historical data.
Another typical practice we use in projects is to consider the GDPR requirements here, specifically around the right to forget. If a user has left an organisation then we would typically build an obfuscation method separately to the deactivation so deactivated users become a subset to who can be “forgotten”. This obfuscation can be as simple as clearing property history and setting the name to “Deleted User” and genericising the username to something like deleted.user. This way you aren’t left blanks across your applications where a user has been deleted and instead see Deleted User.
Personally I never normally just have a delete for anything that is relatable data as it can “compromise” you data integrity or at least the perception of. Having a process behind it which either obfuscates or reassigns data to a record of choice or a special record maintains that integrity. This is all however a business led decision and how okay you are with having blanks where you would otherwise expect some data about a user. Be sure if you go down the delete route you rule processes etc. account for this so you do not end up down a dead end trying to complete a task about a record that’s no longer on the other end.
Hope this helps.