Deleting application accounts should be performed only in specific instances. The most important instance, of course, is that you no longer care about that person's history of activity in your data. However, most data gets created with associations back to an account. The better option is almost always to 'deactivate' them. But that's easier said than done properly.
I just completed some related stories so I thought I would share the issue and the resolution. In this Mendix application all accounts are assigned multiple roles that are associated back to other accounts, creating a recursive account hierarchy within the entity. Perhaps I'll cover what all of that means in another post. But for the purposes of this post, suffice to say there are dependencies (read "associations") between not only accounts, but the data created in the system by these accounts based on those roles.
If an Application Administrator (role) has the rights to 'Delete' an account, all of the associated data, current and historical, will lose the association to that account and create orphan relationships throughout all of the formerly associated data. Not only will the data get corrupted, but the account hierarchies dependent on these associations between accounts will as well. Once gone, there isn't any way to recreate that user with the same GUID and restore all of those relationships (note: There are tools that can manage this on the database side but not directly in the application side). The only resolution without direct database access would be to restore from a backup and hope you didn't lose too much data in the process.
Therefore, don't give Application Administrators the option to 'Delete' accounts; save that for you System Administrators only who understand the impacts of such a change. Deactivate them while dealing with the associated data.
The right way to deal with associated data and ensure the account can't logon to make changes in the app is to utilize the 'Active' toggle in the Account_Edit (or custom) page. If you toggle that off, the user can no longer log onto the application. Simple enough, right? But there's more you should consider.
There are two things I do when developing this for the Application Administrators:
- Create a custom 'Remove' microflow button in the User Role Reference Set to determine what data is going to get affected and deal with it directly or indirectly through instructions.
- Create an On-Change microflow for the 'Active' toggle that determines if the user still has roles assigned. If so, it toggles the account back to active and tells the Application Administrators to remove the roles first so that the associated data is cared for during the 'Remove' microflow you just built.
On this recent application story, I iterate through the selected User Roles that were chosen to be removed, grab all of the data they are currently responsible for, and reassign it to the person that sent it to them. This ensures the data gets managed and the original sender, who is notified it came back to them because of this change, gets to send it along the workflow following the updated associated pathways. That's how I dealt with the data.
The affected associated accounts get retrieved and 'flagged' with a custom Boolean that is used to show an exclamation mark next to those accounts. This is so the Application Administrator knows to review those flagged accounts. The Application Administrator is also shown a message at the end of the User Role removal process informing them of these changes and instructing them to take the appropriate action on the flagged accounts.
Lastly, if an Application Administrator tried to deactivate an account that still has roles assigned, the On-Change microflow described above kicks in and makes sure the data and associated accounts are dealt with first. Only accounts with no roles can be deactivated. For the record, if you remove all roles, a user can't logon anyway so toggling this becomes moot and as I type this I realize I could just toggle it off with a quick check at the end of the "RemoveUserRole" microflow to see if all have been removed and toggle it automatically for appearances.
There are lots of ways to engineer solutions to any business requirement. I hope sharing this helps someone else think about Account deletion in a new light...before the problems of deletion occur!