Building a Better Retention Schedule (Part 2)

We've started work on how we think our new retention schedule should work. The diagram below (click on the image for a larger view) illustrates the relationship between data tables for the database which (budgets permitting) will run it.



It's similar to the data relationships in our current retention schedule database, however there are a number of tweaks that we've made:

State as part of the Retention Rule is new. Previously we've had fairly narrow retention instructions (e.g. Review after 3 Years). State allows us to be more specific about what that actually means. Our current thinking is that the values for State would be: Maximum (a record must be kept no longer than), Minimum (a record must be kept no less than), Required (a record must be kept for exactly) and Advisory (we don't really care, but here's some guidance just so you don't end up swamped in unnecessary records).

Genre is something I'm willing to bet wouldn't be found on most retention schedules. We certainly haven't had it on ours in the past. Previously our retention schedule only managed the BBC's written records. Now we're expanding it to manage elements created as part of the programme making function such as rushes, stock shots, finished programmes, reversions of programmes and so on. Different types of programmes in the BBC have different retention requirements (e.g. dramas would be considered more important than gameshows). The Genre field will allow us to be able to differentiate between these types of programmes. At least that's the current thinking - we're still deciding whether this is the most appropriate way to deal with the issue.

The Local Record Type and Local Retention Rule are not completely new, but we haven't managed them in this way before. However, the background to that will probably take me more than a paragraph to explain, so I'll save that for a later blog entry.