Working with document versions

When a document is declared as a record, it is important to consider the versioning requirements for that document before deciding on a strategy for declaration. Many business scenarios involve documents that are not versioned at all, which makes the issue much easier to manage. But for documents that are versioned, it is helpful to understand how IBM Enterprise Records works in regard to multiple versions of a document. As with many aspects of IBM Enterprise Records, the business requirements determine how you approach documents with versions.

Declaring IBM FileNet document versions

The Content Platform Engine offers the ability to declare a version of a document as a record, or to declare all versions of a document as a record. However, IBM Content Navigator offers a single declare feature for users, which supports the ability to declare a single version of a document, declaring the current version of the document as a record. To declare all versions of a document as a record, either a custom action must be made available in IBM Content Navigator, or an automated record declaration function must be used.

While it is possible to declare records one or more times throughout the life of that document, it is important to understand that each time that a record is declared, whether it references a single version or multiple versions, these versions are locked down by IBM Enterprise Records. Any other versions, major or minor, that have not explicitly been declared, are not locked down and are not under IBM Enterprise Records control. Any future versions that are created of the document are not automatically declared as records just because a previous version of the document is declared as a record.

When a record is declared on existing versions, any subsequent versions must be declared as separate records from the original. There is no way to add subsequent versions to a previously declared record. The guiding principle here is that after a record is declared, it cannot be changed. However, a record can be superseded, which is a useful function when dealing with versioned documents in IBM Enterprise Records.

Typical versioning scenarios

There are several versioning scenarios when declaring documents as records. These documents might not have been versioned yet, are versioned before being declared as records, or are versioned after they are declared as records.

Documents that are not versioned

One of the common scenarios when dealing with record declaration is to declare the first version of the document and prevent any additional versions from being created. In this case, there is no need to be concerned with managing multiple versions. This situation is a typical scenario for scanned documents where you do not expect users to perform a check-out and check-in to create a new version. This scenario also applies to documents that are not added to the IBM FileNet P8 content repository until the final version is produced or for email messages, which are never modified after they have been sent or received.

Example: Inbound customer correspondence

You want to declare as records all inbound customer correspondence related to an insurance claim. Customer correspondence arrives in either paper or email form. Each paper letter is scanned and declared as a record as soon as it is stored in the content repository. Likewise, each piece of email is captured and declared as a record. None of these documents will ever be versioned.

Documents that are versioned before declaration

A typical authoring scenario might involve adding a document to the IBM FileNet Content Platform repository and having the document authors work on the document before declaring a designated final version as a record. In this scenario, you allow designated authors to check out and check in the document as many times as needed to produce a final version. After the final version is checked in, only that version is declared as a record. It is up to the authors, or a process that you define, to clean up any of the draft versions.

Example: Authoring a new contract

You want to author a new contract that will be sent to a customer; only the final version of the contract, the one that is actually sent to the customer, is required to be declared as a record. The authoring process requires multiple revisions by several authors. The authors check out and check in the contract document

many times before the final version is produced. When the primary author checks the final version into the system, the author declares the current (final) version of the contract document as a record and optionally deletes all previous versions. After the final version is declared as a record, the authors can no longer check out and modify the contract document.

A variation of this scenario is to wait until the final version is checked in but to declare all major versions as a single record. There are an unlimited number of possibilities depending on your business requirements and your authoring process. Remember that any versions not declared as records are not under IBM Enterprise Records control and must be managed as appropriate per the business requirements. For example, if you declare all major versions as a record, the minor versions are not automatically deleted. You must decide what you want to do with the minor versions.

Documents that are versioned after declaration

Another scenario might involve a document authoring process where newer versions are created after a specific version is declared as a single record. This example is a common scenario where a single document might be updated periodically to produce an up-to-date version of a particular document. But each time that the document is updated, that version needs to be declared as a record. In this scenario, as soon as the next major or released version has been checked in, the specific version is declared as a record. It is up to the business

requirements to determine what happens with the previously declared versions of the same document. From the IBM Enterprise Records perspective, each version that is declared as a record separately is considered a separate record. The original record from a previous version is never modified.

Example: Procedure documents are updated annually

You have a procedure document for the Human Resources department that must be updated once a year and declared as a record each time. Each year, when the revisions are completed, one of the authors declares the latest version as a record. Each version that has been declared as a record is maintained in the file plan as a separate record.

For this scenario, a common requirement is to supersede the record of the previously declared version. However, the system does not do this step automatically. A user can manually supersede an existing record, or you can write custom code to automate this requirement.