Some may find this interesting reading for Revenue Canada's records Retention Requirements. It covers areas such as:
|
Web Logs and Shopping Cart Retention Policy |
|
Purge completed carts after "xx" days | After this many days, purge web logs for carts where a patron signed in. Only logs are purged, not actual carts. |
Purge anonymous carts after "xx" days | After this many days, purge web logs for carts which remained anonymous or were not attached to a patron. Only logs are purged, not actual carts. |
Purge misc data after "xx" days | After this many days, purge miscellaneous data entry online that is not confirmed or saved by the patron. |
Purge unconfirmed mail list after "xx" hours |
This represents the amount of time (in hours) that a pending subscribe to a mail list will remain without confirmation to the web email. If a patron does not confirm addition to the mail list in less than the number of hours specified, the patron will be removed from the mail list.
If the patron does confirm they want added to a mail list after the time out, they will be re-added to the mail list in double-opt-in status (for CASL) |
Keep cart content data | Shopping carts have multiple lines that describe what the patron placed in their cart. One data element is a very important part of the checkout process as it contains data about prices, promotions, seats, donation amounts, levels, resources, etc.
When a cart is checked out, this data is copied to the actual tickets, donations, resources, gift certificates and is no longer needed. It is also not needed if carts are abandoned. However, it can take up significant space on a database. We recommend keeping this data for about 14 days or so as part of the audit trail, should AMS have to inspect carts to resolved issues. Other than that, it is worthwhile purging this data. |
Document Retention |
|
Keep etickets/calendar items |
Indicate how long eticket and calendar files attached to emails sent to a patron are to be kept around. This number indicates the number of days after the performance before the eticket data is cleared from the document record.
The document record is kept around to track that the patron was sent the information - it is only the contents that are removed. Removing the content helps reduce the size of the database anf packups significantly. |
Email, Letters and Correspondance HistoryThe settings are for retaining letters and correspondence history sent to patrons. You can now purge data from the part of the database with the most text data (and takes the most space in backups). Letters can be purged 'en masse'. Two exceptions to the mass purge are:
|
|
Keep Printed Letter History for xx days | The default is 0, which means - keep anything printed forever. Set to 1000 to keep any printed letter for 1000 days after it is printed. |
Keep eblast history for xxx days. | The default is 0, which means keep forever. If you set this, then anything sent from the batch email merge, or added to a patron individually by the employee to email later will be deleted. |
Keep web listener emails for xxx days. | Refers to any email originated by the web listener, in response to a customer request. Includs: requests for passwords, confirmation emails, and notes regarding patron info changes. These are less useful. The default is to remove them after 1000 days. Set it to 0 if you want to keep these forever. |
Clear Searchable Notes in letters. | The default is turned on. Letters and eblasts which are sent to people have also contained a text only version (i.e. no html, images). This means there are essentially two copies of each letter kept for each communication with a patron. The field is not used for searching, which allows the field to be emptied (and save space). It is also possible to reconstitute this data if need be. |
Delete history for letters with no merge fields. | Some letter merges and eblasts contain no merge fields. For example, a pure HTML eblast. By tracking that, the history is the same as the original letter. It is possible to always see the content, without needing to track the merged data. Any customized letter would, of course, not be the same as the original letter an not be compressed using this technique. |