In the context of SharePoint, a record is an electronic file or content that has been stamped at a specific time and place as a record of business. Stamping a document in SharePoint as a record consists of assigning a Document ID and, more importantly, declaring the document as a record. Content includes the body of all documents and its associated metadata, making it an immutable document that if modified either nullifies itself as a record or becomes a separate record from the original. The primary concern for management of these records is to provide evidence of an organization’s business activity.

This definition, while relevant, does not contain the whole picture. How you achieve records management is just as important as what it is. Many organizations do not have the concept or formal practice of managing records. All organizations should explore the benefits derived from the principles of records management. These include but are not limited to the ability to dispose of records that no longer have a business benefit or purpose. Most organizations simply stockpile both physical and electronic records because they see the cost and risk of maintaining records beyond the appropriate retention period outweigh the costs and structure required to implement the procedures and system configurations needed. If your organization has intentionally established the structures for records management, it is in a good position to configure SharePoint to support the records management policies, retention schedule, and disposition practices.

In conjunction with the formal definition of records management, there are principles that are widely accepted for developing a records management program. We have outlined these principles to establish a baseline of understanding for your organization. You might find that referring back to these will be helpful when deciding how records management will best fit into your ECM project.

Records management has a specific life cycle. As part of your records program, we recommend that you document and publish the life cycle outlined in Figure 8-1 as a formal process and policy that must be adhered to by the organization.

Figure 8-1. Records life cycle.

When you understand the principles behind establishing a formal records management program, you will want to start planning for the activities related to the practice of records management in your organization.

In most cases, the primary driver for establishing a records management program is an organization’s need to comply with industry or regulatory-specific rules. These organizations are in an industry or field that has strict rules about how records are handled, and there is substantial risk associated with not properly taking care of their documents. Organizations not in a regulated field, or in a risky business, can also benefit from records management by achieving better organization and work habits related to content that would help to eliminate waste and inefficiencies.

There are two sides of the records management coin. The benefits for maintaining compliance and reducing the amount of records that are maintained can be counterbalanced with the amount of effort required to implement and maintain a proper records management program. This is often seen as slowing down business operations and not providing enough of a hard dollar return on investment. For smaller organizations, enterprise content management and records management can be one and the same. In theory, ECM is less strict, but in reality, 90 percent of properly established ECM systems incorporate records management as an integral part of the entire solution.

If you find yourself in the category of company that is smaller, in an unregulated business, and that does not have a compelling need for records management, this section is still useful to review and understand. The principles of records management correlate with proper uploading of content to SharePoint. We covered the process and benefits of establishing good content usage and practices in Chapter 6. For the user community that will be working with SharePoint, the organizational habits of records management can be a fantastic driver for change management. At a minimum, you should consider a subset of the functionality that might be useful for your business, especially when considering legal risk.

Documents created by the organization are not only an asset, but they also pose a potential risk. Some organizations feel that the historical value of documents outweighs the benefit of destroying records that have no real business value or functional purpose. There is no sentimentality in records management; either you need the records for compliance or you don’t. More often than not, records that are kept beyond a specifically needed period of time become a liability. They could be leaked to your competition, causing your organization to lose valuable intellectual property (or cause embarrassment). It could be content that an employee created that is destructive to the organization. In the opposite risk case, problems could arise because you did not properly manage your records and did not keep critical business documents that were later required.

In some organizations, all documents are records; in others, only a very specific handful of documents are considered records. In either case, calling a document a record implies very specific storage, security, handling, and life span, whereas all nonrecord documents should be disposed of immediately after their transient value is obtained.

SharePoint 2013 and its predecessor, SharePoint 2010, have a lot of functionality around records management and offer tremendous flexibility for how the platform can be used in a hybrid ECM and records management system, in strictly a records center, or where records management principles are utilized as just a subset of ECM.

In SharePoint, we talk about records management from the perspective of records management features and functionality, followed by processes and procedures. In the remaining portions of this chapter, we will take a look at both of these elements and apply them to the features in SharePoint that make them possible, and we will look at how the processes are executed with those features. But first, we will go into some detail about the power and detail of a retention schedule.

A retention schedule is a detailed listing of the organization’s critical operational, historical, or compliance-related content. In many regulated industries, the retention schedule is determined in advance and modified on a biannual or less frequent basis.

The beauty of a retention schedule is that it can be used to determine the following:

Because organizations that have a retention schedule tend to be driven by strict compliance, there is no deviating from the retention schedule, which means that SharePoint should be set up to be consistent with the retention schedules already established.

A typical retention schedule will be segmented into a records series. Each document or content item will be associated with a unique alphanumeric identifier that can be used to categorize documents by retention period. The retention schedule should also include, at a minimum, the type of document, specific records status, and what department they are associated with. Pay attention to this because it can be used as an indication of IA already at work in the organization. If the retention schedule also includes the metadata that each record should have, this can be leveraged as an indication of content types and the columns in each content type. The document life cycle or retention period can be used to determine the information management policies set on each content type. If the content is identified as vital or privileged, this can help you as you establish your content security model. Unless the organization has internal security policies—for example, for management—the retention schedules security criteria can be used as the only security required for the records and your ECM solution.

As you can see, this defines 90 percent of what is done in ECM implementations; therefore, the retention schedule, when identified up front, is a huge help. However, if the retention schedule is not observed until later, this can also cause big issues during SharePoint deployment and usually results in project delay or a restart.

Because of its power, we recommend that organizations take on the practice of creating a retention schedule for themselves, whether or not they are in a regulated industry. The following considerations can help your organization decide whether to build out a records management program:

Not only will an organization that goes through this exercise have a better sense of its content, it will have a large portion of the ECM planning done. Much of the heavy lifting will be done, and the organization will have already established the right state of mind that comes from properly managing and organizing content.

To help you visualize what a retention schedule looks like, we have included an example from a municipal government, as illustrated in Table 8-1. This is meant as a resource for you to see what other organizations have done. This is not a one size fits all. Although any retention schedule should contain familiar elements, all situations are unique and we recommend that you exercise your own judgment to prepare a retention schedule that meets your requirements.

If you look at the City Attorney item in Table 8-1, you can see from this retention schedule that they will have five content types for legal services requests, correspondence, briefs, research, and court decisions. Correspondence and Legal Services Requests will have management information policies that will be set to dispose of these documents two years after their declaration as a record. Court Decisions, Briefs, and Research will have an information management policy that will be set to dispose of the documents three years after the matter close date, which means that they will need a custom column of the matter close date as a date field (in their SharePoint 2013 system). All the documents for the City Attorney appear to be historical, which might affect the IA of their site collection or site.

In the case of the City Manager/Airport department, the Gate Access Application is set to be a confidential document, which means that in the site collection security for the Airport, we should consider tighter security for these documents. This is a good example of the method we would use to leverage the retention schedule to help provide the details we need for IA, content types, retention schedule, and, possibly, site security.

We recommend that organizations start up front with a formal records management program and records inventory, all the way through to developing the retention schedule. After a retention schedule has been identified, planning of specific SharePoint functionality will follow suit and incorporate all the elements of this activity.

We are assuming that all the standard ECM features that we have recommended are enabled for your SharePoint farm. In addition, there are additional sets of records management-specific features that can be used. These provide the functionality in SharePoint that allow you to perform core records management functions. We have outlined specific steps to follow, to enable the following features:

The records center acts as a type of template or starting point. All documents saved in a site provisioned with this template are automatically declared as a record. No nonrecord documents will be stored in a records center. Usually, organizations will not have more than one records center, and they will provision more based only on size constraints, not security. This site is typically accessible only to content managers or records managers. After a records center site is created based on your IA, you will create libraries consistent with other sites. The libraries that can be unique could be hold libraries or libraries for very specific types of records, such as board, council, or executive team records.

In-place records declaration is usually the alternative to a records center, where instead of all documents in a site being declared a record automatically, the user or automated workflows decide when a document is a record, and nonrecords can live with records.

Figure 8-2. Records center site.

Follow the seven steps outlined and illustrated in Figure 8-3, Figure 8-4, and Figure 8-5, respectively, to enable in-place records management.

Figure 8-6. Library Record Declaration Settings dialog box.

You will have to repeat steps 5–7 on all libraries in the sites and site collection where you want the feature enabled. When enabled, when you select a document in a library, you will have the option to click the new Declare Record button on the File tab of the ribbon, as shown in Figure 8-7. When you do so, the document will be stamped with the time, location, and content. This means that it cannot be moved or edited unless it is undeclared as a record.

Figure 8-7. Declare Record button.

After a record is declared, users will notice a little lock symbol on the file icon, as shown in Figure 8-8. As you can see, this record is living with nonrecords.

Figure 8-8. Records and nonrecords.

In-place records can also be declared via workflows or the content organizer feature in an automated fashion.

Based on existing metadata, usually a date, information management policies are the mechanism that decides when a document should be disposed of. For example, a disposition for a contract might be seven years after its termination date. In such a case, the content type will need to have an additional column for the termination date, and then it will need an information management policy created for it. When you built the content types in the ECM Hub, you established these information management policies on a content type level. Ad hoc creation of information management policies should not happen outside of this configuration.

Content audits allow content managers to review documents from a management perspective or if specific content is related to a matter. Content audits can happen on a document level, library level, or even a whole site level. Content audits will show, from the point that the document first arrived in SharePoint, all viewing, modifications, and automated actions taken on the content.

Follow the five steps outlined and illustrated in Figure 8-9, Figure 8-10, and Figure 8-11, respectively, to perform a content audit.

The content organizer is a special type of library that can route or modify content uploaded to it based on metadata rules. Content Organizer is a site level feature, so you must select which sites you would like the content organizer to set up.

Follow the three steps outlined and illustrated in Figure 8-12 to enable the Content Organizer.

Figure 8-12. Activate Content Organizer.

After the feature is enabled, you will immediately notice a new library called the Drop Off Library. We typically recommend that this library be renamed to a friendlier name for your organization, relevant to its function, but for now, we will leave it. Now you can create rules for this library to act on metadata when uploaded to it. First, before creating any rules, the ECM team must decide what the rules will be and document them. This feature can be useful to get users to do the right thing without even knowing it or to make sure that as content is contributed to ECM or Records Management, it goes through the proper processes.

Follow the four steps outlined and illustrated in Figures Figure 8-13 and Figure 8-14 to create a rule.

Figure 8-14. Content Organizer rule settings.

Now that this rule is created, all new documents that are confidential and uploaded to this library will be automatically routed to the proper document library.

Send To locations and Content Deployment paths are a mechanism in SharePoint to move content from one location to another in the farm. The reason this feature is so critical for records management is that content that needs to be administered by a records manager often does not originate as a record in the final location. Many organizations elect to have transient and living content in a less regulated area, but at some point, that content becomes either invalid and disposed of, or it is moved to ECM and/or records management sites for proper management. Send To locations also allow using features such as Content Organizer to its full capacity. The trick with Send To locations and Content Deployment paths is that they require configuration in Central Administration, which should not be open to everyone, and strategically placed drop-off libraries, which end up being the send-to URLs. Therefore, someone with access to Central Administration will have to participate in the set up. In the case of content deployment paths, not only does the path setup happen in Central Administration but so do the scheduled jobs.

For purposes of ECM, we are going to recommend using only Send To locations because they are the most available to the user, the most flexible when it comes to moving a batch of documents or a single one, and they fit nicely with the other features we talk about.

One of the most powerful new features of SharePoint 2013 is the ability to drag documents from one location to another. Now, moving a document from one library to another is as easy as dragging the file from one location into the desired library. This is a small enhancement but one that has huge impact as it relates to other methods of moving content. There are many cases in SharePoint 2010 where you would use Send-to connections or Content deployment paths to move content. Now with SharePoint 2013, you have an additional method; however, it’s important to use the right method for each situation.

Consider the use case of moving content. If it’s simply for the purpose of organization and not records management processes, you can consider allowing just the dragging feature within sites. If you need to move content across sites, related to some business process or enhancement in content contribution, use the Send-to connections. And finally, if you need to move large amounts of content based on a date or other action criteria on a semi-periodic basis, use Content deployment paths.

To set up a Send To location, you must first enable the Content Organizer feature in the various locations where you want to accept content. After you have enabled the Content Organizer feature, follow the nine steps we have outlined and illustrated in Figures Figure 8-15 and Figure 8-16.

We recommend creating send-to locations for the following purposes:

After you have configured your Send To location, you will have a new option on the ribbon, as shown in Figure 8-17, for send-to locations that can be used on individual documents, multiple documents, and even workflows.

Figure 8-17. Send To locations menu.

Another major component of records management is the process of holds and eDiscovery. These features will be covered in detail in Chapter 9. We mention them here because in some organizations, even without the need for eDiscovery, holds are a tool used by records managers to audit and review content. The feature and mechanism for doing a hold and for using eDiscovery are the same but can have different purposes.

Site disposition is a brand-new feature of SharePoint 2013, and just like the ability to use information management policies to purge content on specific time frames based on metadata, site disposition behaves the same. This is an incredibly powerful tool to prevent sprawl on team and project sites. It would be extremely uncommon to have the core IA of either the records management sites or the ECM sites disposed, because these sites are not transient. However, a records manager’s job is also to prevent sprawl. If you consider project sites and team sites individually as a document, their existence can produce content that ends up in ECM, but ultimately, when the project ends, the site should be removed.

We have provided an outline of the nine steps you will need to follow for setting up site disposition. This happens in two stages: first the creation of site policies, as illustrated in Figure 8-18, and then the setting of the site disposition date, as illustrated in Figure 8-19.

Site Policies are created at the site collection level, as shown in the following steps:

Let’s step through the decision process regarding what settings to choose over others. There are many approaches that you can take with site disposition. Each situation is unique, and we encourage you to build and configure your site disposition based on your requirements. Following are the positions an organization can take, along with their associated disposition configurations:

The site closure type of “Do not close or delete site automatically” will become read-only if a site owner closes a site using this option. The benefit of such an option is realized if an organization chooses to archive all sites and maintain them for the indefinite future. This will essentially declare the site a record but still make it visible. The danger of this option is for areas where site creation is done rapidly, because this will result in empty and nonsense sites being kept forever.

We advise that taking the flexible or empowered owner approach is essentially the same as using no policies at all. Owners of sites will always be inclined to keep a site open “just in case.” Even if they have the intention of closing the site when it’s time, our experience indicates that they neglect to do so. This results in site sprawl and in a small portion of the sites being treated correctly where another portion is not. In our experience with ECM solutions and records management, it’s not what you get right that hurts you but what you miss, so we are recommending these options be avoided.

The bargained hard line setting has the same problem of the site owner’s ability to postpone, but you can limit the amount of time in days, months, years that a postpone will happen, and because the site closure is set to delete, there is no going back, so the bargained hard line setting works for a well-trained and conscientious site owner. A hard line is the recommended option, and we suggest that all organizations start with this option until it’s a problem. It’s easier to give the users choices than to take them away. For example, in the hard line, the organization must make it very clear how long sites will last for all new project sites and publicize this everywhere. We even recommend that the organization create custom site templates that include this notice in the home page of the site.

In summary, the archive approach should be selectively used only if archive processes have been established and made clear. The empowered owner approaches should never be used. And organizations should start with the hard line approach but move to the bargained hard line if they need to.

Now that the policy is created, we need to apply it. Navigate to the site you want to apply the disposition to, and perform the folllowing three steps as outlined and as illustrated in Figure 8-20. If enabled, this is where the site owner can manually close the site.

Figure 8-20. Site disposition settings.

After you click OK, this page will be updated with the deletion date. This is a good reference for records managers and site owners to keep track of.

After a policy is applied, owners will be able to close the site manually and see the disposition date. If they have been given the option to postpone, they can do so here. If a site has been closed and the retention date has been reached, but the policy allows for it to be read only, it will remain visible in the IA, but new content cannot be added and edits to existing content cannot occur.

Arguably, all features of SharePoint ECM are also features of records management. Content types, MMS, and the metadata model in general are critically important to the records management processes. However, the features we have covered and the steps to configure them are specifically used for records management in SharePoint.

The subtle difference between ECM with records management and ECM without records management is that ECM accommodates living documents as well as documents that will no longer be edited and will be used for reference and consumption only. We have found that this subtle difference has caused a lot of confusion and failure to act on SharePoint ECM projects. The root of the confusion seems to be the records center.

Prior to SharePoint 2010, the ability to lock down individual documents as immutable content with a stamp in time, location, content, and metadata was possible only with a special type of template called the records center.

In the records center, all documents were declared records. This gave a single location for records managers to manage their records, and it walled off records from nonrecords. But this created a problem because it did not provide flexibility and, ultimately, limited the domain of the records and Legal department to only this subset of documents. This created a large opportunity (and risk) for large chunks of content to remain in a digital dump without proper records management.

Starting with SharePoint 2010, a new feature of in-place records management was provided so that you could declare a document as a record and allow it to live with nonrecords. This increased the flexibility, allowing organizations to have records management principles across all ECM components in the farm. But it also begs the question, “When do I use records center over in-place records management?”

This seems like a technology and feature question, but it is not. It is a business question, and it has as much to do with the structure of your organization as it does with how it is implemented. As we showed earlier, any library in any site can essentially be converted to a mini records center where all documents sent there are automatically converted to a record, so it’s not really a one-or-the-other option.

However, if you do commit to the records center, you are locked into a practice that must be maintained and that presents some risk and complexity if you want to undo or remove the features.

To help the organization make the decision about which method to use, here are some of the questions that you should ask the ECM team:

Table 8-2 provides the answers to these questions in the context of the records management system types.

The matrix in Table 8-2 relates a positive response to the questions and what that implies in terms of features. You can see that a “yes” on only questions 3,4,5 has any implication to doing a records center, and only 4 and 5, which are rare scenarios, imply a clear need for using only a records center. If you have a records manager whose scope of influence or effort is only a small subset of highly critical documents, it’s more convenient to remove those documents from the creators’ eyes and put them in a single site collection or site where the records manager can operate. Similarly, if according to the organization’s mandate, living documents are not considered records, it’s important to isolate records from living documents to wall them off.

Most the time, we see that organizations find it hard to justify a records center only. We believe that a “yes” response to question 4 spells some serious problems for the organization, because limiting the scope of a records manager’s manageable content is contrary to the purpose of the role of protecting the organization. And it’s not common for organizations to not consider living documents as serious content.

Therefore, we find that most organizations have in-place records or a hybrid scenario. We would recommend starting with the in-place records management approach, and add hybrid later if needed.

In the hybrid approach, you establish a library in a site where the setting of the library is that all documents in this library are automatically declared as records. The biggest benefit of this feature is that the average users might not need to see documents declared as records on a regular basis, which prevents them from being inundated with a records declaration process or slowing interactions with content that is not considered a record. This can especially be true with our recommended approach of flatter IAs. By moving the documents to a separate library where they can be declared as records automatically but also allowing declaration of records in the spot where they live, the organization has the greatest flexibility.

The problem with the hybrid approach is that it requires thought and intention for some users who might not be familiar with the concepts outlined in this chapter. If it’s a records manager, this is a part of their daily job, but if it is a knowledge worker, this will often be neglected and not followed, resulting in documents that should have been moved to a records library and declared a record.

Again, we recommend starting with the in-place records management approach until such time that declared records of a particular type become troublesome for day-to-day users.

We have covered in detail the features of records management in SharePoint, but what about their application? After all, this is one of the killer problems of SharePoint, where features are easy to throw out to the masses but usage of those features is not contained, nor is correct usage established. The processes themselves are as important as the features that make the processes possible.

In the last chapter, we talked about governance. With the records management portions of SharePoint, governance over features is key. Let’s start with who manages this governance.

In larger organizations, there is no question of who is in charge of the accuracy, consistency, and management of the content. This individual is usually given the title Records Manager or Content Manager. They will be found in all regulated industries and in government.

Looking at smaller nonregulated organizations, the records management position is not common, and it’s unfortunate. Having a role responsible for content shows intent to manage content in the correct way. Without the intent, contributors to the system are considering only their immediate goals with the system, such as uploading or searching for content. These actions add up, usually not in a positive way, to a collection of events that can pollute the content management system.

Our hope would be, even in small organizations that do not have the ability to hire a specific role for a records manager, to establish this as a duty of one of the existing roles. Making it the responsibility of an existing role that the organization does require will allow for some to take ownership of the records manager function. Without this, the organization is at high risk for being unsuccessful with the ECM solution, along with records management.

In addition to the oversight, the interaction and the abilities of users is also very important. SharePoint, with all its flexibility, opens many back doors to doing the wrong thing. For example, workspaces allow users to avoid metadata and records declaration, even if in a records center.

Not only is the organization responsible for planning out records management, the features, and how they will be used, it also, as we described in Chapter 7, needs to plan how those features are governed. Records management done incorrectly is the equivalent of not doing it at all. Here are the top questions to consider when governing the records management features of SharePoint:

As you have seen, a common theme throughout this book has been that ECM and records management features in SharePoint are fantastic. However, the success of the system depends on how you plan for and implement the solution. As you start to understand the relationship of features to one another, the relationship of features to users, and how the system as a whole is governed, it becomes much clearer how you will achieve success. SharePoint projects fail most often because of unclear planning for how the ECM solution will be married to the operational business and functional requirements. This leads to low user adoption and disappointment.

At this point in the book, you have a deep understanding of ECM methodologies, SharePoint ECM features, IA design, and now, records management. In the next chapter, we are going to discuss an extension to records management that we have touched on called eDiscovery and holds. Like records management, it’s not found in all organizations, but the benefits and principles of eDiscovery and holds are useful and relevant to anyone planning an ECM solution in SharePoint.