This week we launched an archiving process for our Document Management System (DMS). Underlying the process we used a product from Interwoven called WorkSpace Archive Manager (WAM). The WAM tool basically moves an entire electronic file (the documents, emails, folders and the meta-data) from one library to another, in our case from the Matters library to an Archive library.
I intend to blog about our general process and what we discovered working with our lawyers at a later date. The purpose of this post is to point out a bug or should that be a “feature” with the WAM tool. One that will probably cause you problems in the future if you don’t address it before you start.
We found in our analysis that keeping document numbers when moving documents between libraries was essential for the lawyers, especially as these numbers are often used in references on the documents themselves. We did look at using the WAM tools ability to store the document number in a separate “old document number” custom field, but lawyers didn’t like this. They wanted the document number to be the document number, end of!
Basically what this meant was, if you have ready to archive:
- matter 1/1 with document numbers 100 and 101
- matter 1/2 with document numbers 102 and 103
We would want them to appear in the archive with exactly the same matter numbers AND the same document numbers.
If you intend to archive everything in one big batch job and then seal up the archive and never write anything else to it then you’ll probably never hit the bug. But in reality you’ll probably want to archive in phases or even more likely on an ongoing basis. If that’s the case then you’ll likely hit the problem.
So in the example above, say we archived 1/1 one week and 1/2 a few weeks later. We would see the problem occur because we’d need to use two WAM jobs to do this. What happens is that the WAM run will create a webdoc entry in the document table (docmaster) of the archive library for the workspaces/folders using the next available document number (in the example of 1/1 it would use 102 – the next available number).
And this is where the problem occurs, when you come to archive 1/2 and it can’t maintain document numbers as 102 and probably 103 are already in use!
The trick to resolving this is to “seed” your document number in the archive libraries high (we chose 75000000), thus the next available document number for the webdoc entries is 75000001+. This will ensure all the actual document numbers can be maintained as they will unlikely “meet” a duplicate number. To me this is a flaw in the product as when you archive, you’re archiving the folders etc as well and thus surely these should maintain their numbers from the source library too.
It certainly should not go creating new entries in the archive with new numbers!
