Setting Up Records Management in SharePoint Server 2007

To configure records management in SharePoint Server 2007, you begin by defining the content types that will be used to classify records throughout your enterprise. You then create a site based on the Records Center site template and configure the methods you will use to route documents to this site after they have been classified. Finally, you create information policies within the Records Center site to apply the rules dictated in the file plan. The following is a summary of the steps you will follow:

1. Create content types, and deploy them as site content types or features.

2. Create a separate Web application to host the Records Repository.

3. Create a new site collection in the Web application using the Records Center site template.

4. Create a new document library in the Records Center site for each record type or set of similar record types.

5. Define required fields (columns) on the document libraries.

6. Define Information Management Policies to implement the file plan rules.

7. Configure the series entries in the Record Routing list to route documents to the correct document library in the site.

The following sections provide more details concerning these steps.

Creating and Managing Content Types

A content type is a data element plus a pre-defined set of metadata. In this discussion, you can think of a content type as a collection of settings that can be applied to a document to categorize its content. Content types are essential to the proper functioning of your Records Center because documents submitted to the Records Center are automatically organized by filing them into a specific document library according to their content type. To ensure that all records are routed correctly, you must configure your enterprise content types strategy before implementing your Records Center.

In a traditional file plan, record classifications are tracked by using identification keys or codes that organize the records files for easy browsing. For example, a file could be given a "record locator id" such as IT-05-DOC-001, which could be understood as: file number "1" of the "DOC" format in department "05" in the "IT" division. These classification designators are often used to create a hierarchical structure of folders into which files can be organized. In SharePoint Server 2007, the recommended classification approach is to apply a specific content type to each document before it is submitted to the Records Center.

For every record type in your file plan, you'll likely need a corresponding content type that users can apply to the documents. You'll want to create a document-to-content type mapping database so that you will know which record types use which content type. In a large environment, it is very conceivable that you'll have thousands of content types.

Content types support inheritance, allowing you to base a new content type on an existing content type. In this way, you can define a single content type with specific attributes and create a derived content type based on it. You can then add new attributes to the new content type to extend the definition. In some cases, you might want to create several derived content types from the same parent type to distinguish different documents that otherwise have the same attributes. For example, the content types Financial Statement and Fiscal Report might be two sub-types of the parent type Finance Document that were created to distinguish the two types. Each type could then be routed into a different document library in the Records Center, or they could be grouped together.

Inheritance for content types works only within site collections, not between them. You can create parent and child relationships between content types either within the same site or between a parent site and a child site. However, if you have several source sites that will submit to the Records Repository, you need to re-create the content types in every site collection. A more efficient approach might be to develop the content types as SharePoint Server 2007 features that can be deployed to the server and made available in every site collection. A feature is a set of files and configuration settings that can be installed on a server so it can be available as an optional feature in every site collection. When a content type is defined in a feature, it can then be enabled or disabled in individual site collections as needed. This ensures that content types are uniform across the environment and are deployed only in the appropriate site collections.

More Info 

For more information on content types and features, see Chapter 15, "Managing Content Types."

For content to be correctly routed and stored in the Records Repository, users must apply the appropriate content types to documents before they are submitted to the Records Repository. If users upload existing documents to a document library and the library is configured with multiple content types, users will have the option to select a content type for the document on the document properties screen, as shown in Figure 10-1.

Figure 10-1: Selecting a content type for an uploaded document

Alternatively, users can create new content directly from Content Type templates by selecting the content type from the New menu in the document library. In both cases, the user must provide values for any required data fields associated with the content type. Content managers in each site collection should periodically review documents to ensure that they are being assigned the appropriate content types, as defined by the file plan.

Creating the Records Center

The Records Center site is used in conjunction with content types in SharePoint Server 2007 to implement a file plan. The Records Center site has been designed for use as the storage location for the official copies of all records in your organization. That does not mean that the file will be the only copy-there might be other copies of a document in other sites, but the copy in the Records Repository should never be changed.

It is recommended that you create the Records Repository site on a separate Web application, with the Repository template selected for the root site collection. One reason for adopting this approach is that it ensures complete security separation between the Records Repository site and any other sites. The security on the Records Repository site should be more restrictive than on other sites, with very few users having edit privileges. Another advantage of using a separate Web application is that it uses a separate SQL Server database for all data stored in the application. This approach allows you to back up and restore the Records Repository on a different schedule from other sites. Additionally, having the Records Repository in a separate application makes it easy to set up indexing of content on a separate schedule.

Although you can create multiple sites based on the Records Center site template, you can configure only one target site for each Web application as the default destination for users to send records to. Therefore, if you have configured multiple Web applications in your SharePoint farm, you can configure each application to submit files to a different Records Repository or you can have them all send files to one Records Center. Configuring multiple repositories in your farm is appropriate for situations where the documents in one records store must remain isolated from those in other record stores. In most other scenarios, it is much easier to manage your records, place holds on them, and generate reports if they are all in one site.

The Records Center contains a number of specialized features that make it easy to use as a records management site. Figure 10-2 shows a new site created from the Records Center site template that contains the following features:

• A document library named Unclassified Records, which will act as the default location for any file that does not match a routing record.

• A Record Routing list, which contains rules that define which document library a file is routed to when it is sent to the Records Center. This list has a default entry for the Unclassified Records library.

• A Missing Properties document library, which serves as the entry point for users to fill in missing metadata in submitted files.

• A Records Pending Submission library, which serves as a temporary storage location for records that are missing required metadata.

• A Holds list, which is used to create and manage overrides that suspend expiration policies on records.

• A Submitted E-mail Records list, which is used to temporarily store received e-mail records.

• A built-in reference to the Records Repository Web Service, which is used to submit files from other sites to the Records Center.

Figure 10-2: A new Records Center site

Creating Document Libraries

Document libraries serve as the storage locations for files in the Records Repository. Although you can configure only one target repository for each Web application, you can configure multiple document libraries to receive files. Each library can hold one type of file or many different types, depending on how you want to group files for browsing and navigation. Files will be automatically routed into the document libraries based on the locations you configure in the Record Routing list. Although you can create folders within document libraries, they cannot be used as destination locations in the record routing entries. Files can be routed only to document libraries, not to folders within the libraries.

More Info 

For more details on creating document libraries and list columns, see Chapter 9, "Document Management."

You do not need to enable versioning in the document libraries in the Records Repository site. The Records Repository Web Service, which copies documents to the Records Repository, automatically creates new versions when they are submitted and appends a randomly generated identifier to distinguish them. For example, if two versions of the file "FS501 - ChangeRequestsGuidelines.doc" are sent to the Records Repository, they will be stored with unique names, as shown in Figure 10-3.

Figure 10-3: Automatic versioning of records

Defining Metadata

When you plan the document libraries to create, consider what types of metadata you want to track for documents that are stored in the library. If there are columns of data already associated with a document in the source site, you should create the same columns on the destination document library in the Records Repository. Otherwise, the metadata will be copied into the library but it will not be accessible through the Web site pages. You can also create additional columns to track metadata that is required by your file plan but which might not be present on the original document. For example, you might want to assign to the file an identification number that is generated by an external document tracking system. The user would then be prompted for this number when she sends the document to the Records Repository.

When a document is submitted to the Records Repository, the Record Routing list is queried to determine the series type (the routing rule, described later in the chapter in the section titled "Configuring the Record Routing Document Library") that identifies which document library the file belongs in. That library is then queried to retrieve a list of columns that constitute the metadata that will be associated with the file. Existing document metadata that matches columns in the document library is automatically promoted and stored in the library columns. If there are metadata columns that are not already populated with data, the user is presented with the Missing Properties page to provide the missing values, as shown in Figure 10-4. If the user fails to provide any required values or clicks Cancel on the Missing Properties page, the file is not sent to the Records Center but record entries are placed in the Records Pending Submission library and the Missing Properties library in the Records Center site. The entry in the Records Pending Submission library identifies the source file and the target library it should be routed to and the Missing Properties entry indicates the column values that still need to be populated.

Figure 10-4: The Missing Properties page

Note 

Although you can configure the document libraries in the Records Repository site with the same Content Types that the source libraries have, the content type association is not carried over to the Records Repository site.

Defining Information Management Policies

Information management policies are sets of rules that govern the automated management of documents, such as how long a file should be retained or which actions on the file should be audited. Each rule in a policy is a policy feature. Policies in a records management system are configured by records managers to reflect the file plan requirements. The value of storing files in separate document libraries becomes obvious when you start designing the information management policies that you will apply to each library.

There are two recommended approaches for implementing policies in the Records Repository: create individual policies for each document library if the requirements are unique to the content in each library, or create Site Collection policies to cover an entire set of record types and apply them to several document libraries as needed. You can either apply one policy for the entire document library or, if you configure the document library to allow multiple content types, you can apply a separate policy to each content type. The following section describes the policy features that are available in SharePoint Server 2007.

Expiration

The Enable Expiration policy feature allows you to specify how long a document is retained in the Records Center and to control what happens to it at the end of its life cycle. When you select the Enable Expiration policy feature, as shown in Figure 10-5, you have the option to set an expiration time based on when the file was created (that is, when it was copied into the Records Center) or last modified. You can specify values that range from 0 through 500 years, from 0 through 6000 months, or from 0 through 182,500 days from the date selected. Alternatively, you can choose to have the expiration date set either by a custom application or through a workflow process running on the document itself. You can define what action SharePoint will take on the document once the expiration date has passed. An action could be to delete only the document or to delete the record and submission information, or to initiate a workflow to gather input as to how the document should be disposed of.

Figure 10-5: The Enable Expiration policy feature

Auditing

The Enable Auditing policy feature allows you to feature log events and operations performed on documents and list items. The auditing feature not only tracks operations performed by users but also those of SharePoint itself and any custom code or Web services that access the document programmatically. See Figure 10-6 for the types of operations that can be audited.

Figure 10-6: The Enable Auditing policy feature

To view the audit log, open the Site Settings of the Records Repository site (or the root site in the site collection if the Records Repository is a subsite). In the Site Collection Administration section, click the Audit Log Reports link. Doing this displays a page that lists each of the audit reports produced. You can click the Run A Custom Report link to manually specify the parameters for a report, or click on any of the predefined reports to generate a Microsoft Office Excel-based report of the audit log data.

Labeling

The Enable Labels policy feature enables SharePoint Server 2007 to automatically generate searchable text areas that are based on a formula that can include static text and document metadata. This feature allows you to insert a line of text or an external value into the document as an image in much the same way that a label is affixed to a document for filing. For example, an organization might want to attach a label to a project document that includes the document ID number and the date it was filed. You define the formula that generates the label by using metadata-based identifiers in conjunction with descriptive text, and SharePoint creates the label for each document added to the document library.

To enable the label feature, select the Enable Labels feature and enter a formula by combining text with valid column names inside curly brackets, as shown in Figure 10-7.

Figure 10-7: The Enable Labels policy feature

In this example, the formula Document ID: {Document ID} generates the label Document ID: IT-05-DOC-001 (as shown in Figure 10-8), where the custom column Document ID holds the value IT-05-DOC-001. When you select the Prompt Users To Insert A Label Before Saving Or Printing option (shown in Figure 10-7), users are given the option to insert the label into the document when they save or print the document. If the label is intended to become a permanent feature of the document, use the Prevent Changes To Labels After They Are Added option (also shown in Figure 10-7) to keep the label from changing in the document. If the label is not inserted into the document, it is still visible from the document properties window when a user selects View Properties from the document drop-down menu in the document library.

Figure 10-8: Records Center-label and barcode

Important 

Labels and barcodes are generated when the document is added to the document library. If these policies are applied to a document library with existing documents, they will not display the label or barcode. Making changes to the document or to its properties triggers SharePoint to generate the label and barcode.

Barcoding

The Enable Barcodes feature can help you mark and track both the physical and electronic versions of a document. Instead of a text label, a barcode provides a unique ten-digit identifier generated by SharePoint Server 2007 and rendered as an image. (Refer back to Figure 10-8.) After the barcode is generated, you can view it by selecting View Properties from the document context menu. As with the Enable Labels feature, you can prompt users to insert the barcode into the document when they save or print the document. The barcode component that ships with SharePoint Server 2007 generates barcodes compatible with the "Code 39" barcode symbology (formally known as ANSI/AIM BC1-1995). SharePoint Server 2007 provides an extensible plug-in model for barcode components that can be used to add custom barcode generators.

Best Practices 

A best practice when using labels and barcodes is to place them in either the header or footer of the document so that they appear on every page and don't cover existing text.

Form Conversion for Archiving

Enable Form Conversion For Archiving is a policy feature that generates an image of a completed form for permanent archiving. This feature is used primarily with InfoPath forms to convert the XML format into a fully rendered document that is no longer dependent on active style sheets or a specific XML parsing engine. To use this policy feature, you must first enable the Document Conversions Launcher Service and the Document Conversions Load Balancer Service. For details on these services, see Chapter 9. When you enable archiving in the policy, you must also select an image format for the output, as shown in Figure 10-9. The format options are PNG, EMF, and TIFF.

Figure 10-9: The Enable Form Conversion For Archiving policy feature

Configuring the Record Routing Document Library

The Record Routing document library is a special-purpose list in the Records Repository that evaluates every document sent to the site and routes it to the appropriate document library. Each item in the list is called a record series and acts as a business rule that evaluates the content type of the document and directs it to a single document library. The record series allows records managers to configure the Records Repository so that records are automatically organized as they are sent to the site. You can make changes to the routing rules and repository structure without needing to make changes to the originating document sites or content types.

When a document arrives in the Records Repository, its content type is matched to the names and aliases defined in the record series entries in the record routing table. Only the content type name is used in this matching, not the name of the file or any other metadata. If no match is found for the content type name, the routing series inspects the inheritance tree of the content type and attempts to find a match with the name of the parent content types of the document. Therefore, you can create record series that target base content types or derived content types of documents, depending on how granular the library structure of your repository is.

To create a new record series, open the Record Routing document library and click New on the menu bar. A new Record Routing page appears, as shown in Figure 10-10. You populate this page with the following information:

• Title The record series title matches the name of the content type or any parent content type.

• Description This is a short description of the record series entry that appears in the list. It helps records managers document the series.

• Location This is the target document library that the document will be routed to. This must be only the relative path name of the library and cannot include the names of folders in the path. For example, if all documents of a given content type will be stored in the Project Files document library, you enter project files in the Location text box.

• Aliases If you want to use the same record series to route documents of several different content types that aren't related by inheritance, you can list the additional content types as aliases. For example, if the record series Title is Accounting, you can enter Finance/Billing into the Aliases list and the records series then routes any documents with a content type of Finance or Billing to the same document library as those of Accounting.

Figure 10-10: New record series

If the content type of the document does not match any record series entry, the document is routed to the library designated by the Default record series. There is always one- and only one-Default record series in the Record Routing list. The Records Center site template includes the Unclassified Records document library and a record series of the same name with its Default set to true.