I have worked at iCONECT for over 10 years. That is a long time in any industry, but in this industry it is a miracle really. In my time here I cannot tell you how many panicked calls we’ve received where a delete (tag, panel, user) was performed in a database, or where even the database itself was deleted, which caused havoc for the case. I learned my lesson pretty quickly after accidentally deleting a database. Now, my mantra is:
Hiding Panels and their Objects
Panels hold folders, radio buttons, check boxes, text boxes, calendars, and lists, so deleting a panel is a scary endeavor. So, you can simply remove Display access at the project level and “hide” the panel from all the users. Removing Display access takes the same number of clicks as clicking Delete, but removing Display access keeps all of the information. And, in a week when the decision to ‘remove’ it is reversed, you can display it again. Remember that when you hide the panel, you also hide all of the panel’s objects.
How often have you heard “I accidentally* deleted a folder!” We can delete-proof your folders to protect ourselves against these accidents. For panels that are in Table View (or both Table View and Document View) you need to be sure security is set so a user doesn’t accidently delete a folder.
*I say accidently but there is a warning message and the user has to hold down the Shift key while they click Yes, so I am not sure how much of an ‘accident’ it could be. Nonetheless “accidents” happen, and so we need to protect ourselves against it.
The first step is in the Panels tile, you remove the Delete property from key folders to ensure no user can delete them in Table View. And just like you did with panels, you can remove Display access when asked to ‘delete’ a folder. Remember that deleting a folder (or tag for that matter) doesn’t delete the documents in the database, just the document’s association to the folder (or tag). If the folder (or tag) is deleted “accidentally”, someone will need to go through the Folder Log to figure out which documents were in it, and that will likely be you.
Also, when removing Delete access, you can use the Apply to children of folder checkbox so that current and future subfolders cannot be deleted.
User Profiles: Do you Delete?
Deciding what to do with user profiles can be tricky, especially if you are on Monthly billing, but you have choices. Instead of deleting the user profile, set it to Inactive: an Inactive user cannot access the system, and is therefore not billable. The bonus is that keeping the user account allows you to temporarily access the account to review the user’s personal saved items such as folders and searches.
Databases: A Better Option Than ‘Delete’
This is the biggie. In XERA Manager, the DB Structure tab has TWO Delete buttons: one to delete fields in the database (purple circle) and one to delete the database (red circle), and you can easily forget which button is the right one to delete a field. A database cannot be easily restored if it is deleted.
Deleting a database requires holding down the Shift key and clicking Yes, which helps to prevent accidental database deletion – but not always.
You could create a policy to simply disable databases after a certain period of inactivity (set them to ‘inactive’), rather than deleting them. If you set up this type of policy, a database cannot be accidentally deleted.
Setting a database as Inactive through System Overview tab in XERA Manager, or the Databases tile in Administration is the fastest way to take a database offline. When you make a database inactive, everything remains (Panels, Tags, Security, Rules…), but the database is not accessible by users.
There will be times when you can’t adhere to a 3-month retention policy because of agreements with clients. As a general rule, disabling rather than deleting will save you and your team a lot of sleepless nights. Disabling panels, folders, and even databases lets your users have the experience they want without losing anything – and makes bringing it back again a snap.