Contributor(s): Amber Smith, Jeff Davison, Laura Bruck
The value of any database is in its data. Here are some housekeeping tips to help you retain data while keeping your database tidy. Before you delete information, consider some alternatives below.
Users & Staff
When a staff member is no longer employed with you, we encourage you to revoke the User ID instead of deleting. Once a user is deleted, you cannot search user activity. Check out our Best Practice article Protecting Your Data When a Staff Member Leaves for more details.
If the User ID was matched to a staff member, revoking access from the database will also keep them from being able to login to the Staff Portal. Change the staff member’s status inactive on the Summary tab of the Staff record instead of deleting. Deleted staff members can be recovered by our Development Team, but there is a fee to recover information.
Many of your drop-down lists have the option to hide, which is always preferable to deleting. It is best to create new drop-down list values, rather than editing. If you would like to change an existing value, support has the ability to mass change some drop-down list values for you.
Use caution when changing or deleting existing drop-down lists as this can affect the ability to report or search by that value.
When would you need to change drop-down list values? Here are some possible scenarios to demonstrate how this might apply to you.
You are no longer offering a program that you had when you set up Jackrabbit. No need to delete the Category 1 - you can simply hide the value from your users and customers to prevent future use.
It is time to transition your classes to a new session and your ‘old’ classes have ended. The old class session value found in your drop-down lists can be hidden from users and customers to prevent use hereafter. Note: hiding the session value in your drop-down list does not hide the session of classes. See Archive Classes below.
You can choose which users have permission to delete or edit transactions. All users with this ability should be aware of how either task can affect a family’s account. It is best to edit a transaction rather than delete. However, if the transaction was created in error, deleting is appropriate. Transactions can be restored - contact Support for assistance.
Every once in awhile, you may find that you have two families in your database that are the same. It is best practice to merge duplicate families. Not only will this consolidate enrollment and transaction history into one account, but it will also decrease confusion for your database users and your customers.
When in Doubt, Don’t Delete!
Sometimes deleting is necessary but often there is another solution that would better suit your long-term needs. If you must delete, make sure to run a report and save the information on your computer or make a note (i.e. when deleting a transaction) in case you need to refer to it in the future.
Not sure what to do? Contact Support anytime for further guidance.