#usnatarchives
The problem of automating government records has actually been solved for years. Enterprise resource management systems (ERMSs) have existed for decades and records management is commonly “baked into” content management inside every modern ERMS.
The way these systems track content to records is that content (documents, reporting, analysis, etc.) generated inside of ERMSs is defined relative to the purpose of the system. Because the “types of content” created inside each system is pre-defined and known for a specific purpose, a direct match can then be drawn between what the created content is and its appropriate record series, which then further defines its records disposition, disposition authority, and from which can be derived the disposition date.
For example, in any common acquisition-related ERMS system, document templates for each phase of the procurement are generated internal to the system. If, for instance, a statement of work (SOW) or an independent government cost estimate (IGCE) is necessary, the ERMS acquisition system is designed to provide the template for each, editable and store-able inside the system. Once the content type of either SOW or IGCE is selected, the ERMS instantly knows that these documents are aligned to a specific Record Series: 1.1-011; Series Title: Financial Management and Reporting Records; Disposition: Destroy when business use ceases; and, Authority: DAA-GRS-2013-0003-0002. If a different content type with a different retention disposition is chosen, the system is programmed to assign the respective record disposition details. Workflows assign data elements to the respective records-related fields, calculate disposition dates, notify users of pending dispositions, and delete documents as defined by the disposition authority.
Likewise, if a government employee logs into an agency’s HR management system to create an evaluation for a subordinate, upon creation inside the system the record is immediately tagged with the records information of Record Series: 2.2-030; Series Title: Employee Management Records; Disposition: Temporary: Destroy when 2 years old or 2 years after item is approved or disapproved, whichever is later, but longer retention is authorized if required for business use; Disposition Authority: DAA-GRS2017-0007- 0003.
Which content gets managed as records?
Outside of ERMSs, understanding which government content must be managed as records is as much the problem as understanding…”how to do it” – (how to manage content as records, which I’ll explain here).
When thinking about the totality of information created by any government agency, it is simplest to think of content in terms of its Purpose.
First, there are two primary purposes to all information created for any government agency. Those purposes are “Business” and “Mission”.
The mission side includes all content related to the specific mission of the agency: All content related to diplomacy for the State Department, international development for USAID, law enforcement for the FBI, intel for agencies in the IC, etc. The business side includes all the content common to every agency: Acquisition content, Finance content, Human Resource content, Logistics content, Security content, IT content, etc.
The mission side of government agency content is commonly handled by ERMSs, which, as explained, contain the benefit to records managers of handling the records management of mission documents within the system. These systems can even go as far as migrating their records content and file plans to agency Records Management Offices upon notification of the annual requirement. But, I digress.
This is not to say that all agency “mission” content is created inside of ERMSs. Legacy paper records, for example, once digitized, have few existing ERMSs designed for their intake, organization, or metadata requirements. This “mission” content often gets stored in out-of-the-way places where it languishes in records accountability.
Nor should it be assumed that “Business” content is created solely outside of ERMSs. On the contrary, not all, but many agencies have ERMSs for acquisition or finance or manpower and other business related functions.
Assuming records management for all (business and mission-related) ERMS-managed content is handled internally by the ERMS, what remains to be automated and managed for records accountability is all the content, both mission and business, not handled by some ERMS. Everything!
Where is this content?
When thinking about a system to manage records of content NOT included in some ERMS, the design must include a means to manage ALL digital content existing outside of ERMSs, like content existing on organizational shared drives, and content existing on personal profile storage (commonly, H: drives or Z: drives), and content existing on third party storage, like CDs and thumb drives. In addition, all content currently in a non-digital state which in time will be digitized and require electronic records accountability must be considered. These include all paper documents, maps, film, etc., bound someday to be digitized. Consideration of methodologies for the creation of random content types to accommodate new electronic media is necessary in development of the program.
All content already existing in electronic format anywhere outside of an ERMS and all newly digitized legacy content from any media must be considered for inclusion in the capture. This content is known as Unstructured Content.
How does the content get managed?
95%+ of government agencies have Microsoft SharePoint as their default enterprise content management system. By “default”, I mean that the unrestricted, default system provided to agency workforce users for the management of their unstructured content is SharePoint. (There are other CMSs out there used by government agencies, but the approach to content management is similar if not exactly the same internally for them as it is for SharePoint.)
This does not mean that SharePoint at any agency is set up properly for managing content for records management as I’ve described it. If you’re reading this, it may be you who is responsible for configuring your CMS to manage records. If so, you should realize that the problem causing agencies to fail with SharePoint (and any content management system) is that, unlike the ERMSs which know the content they create, organizations within agencies often do not. The operational tempo of most government organizations exceeds the organization’s ability to define systemic organizational processes, to determine specific content types for each organization respectively, and to allow the organization to define unique templates for each content type. All things possible in SharePoint’s cousins – the business-related and mission-related ERMSs.
First…you define your content types. What content types does your organization create? Rather than discuss the mission of any government agency, we’ll just look at the business content types. (How to figure out your organizational-specific content types requires an entire new article. Hint: The secret lies in your shared drives. Let me know in the comments if your interested in a post with that information.) The analysis I performed revealed that the business content types most commonly created over the past 5 years (I chose this number. I could have gone back farther) in my organization are:
Accomplishments, Action Items, Action Plans, Briefings-Presentations, Contingency Operations-specific documents, Datacalls, Manpower-specific documents, Org Charts, Performance Measures, Standard Operating Procedures, Strategy-related documents, Official Taskings, and Weekly Reports, among others.
One could argue that any of these could hold mission related information and that’s true. Content types, however, can remain singular and still be relative to the content repositories they support. For example, a content repository (called a List or Library in SharePoint) for business-related Manpower can contain the same Briefing-Presentation content type as for a mission-related Strategy library. Records management is relative to each content type. Content types can be both specific and general, as specific as a Workforce Requirements document or as general as a Briefing-Presentation. The objective is to create as few content types as possible and reuse them across the system, but in cases where a Briefing-Presentation content type is necessary for something certainly mission-related, like, Strategy, for instance, the content type workflow can be changed at the content type in its library to align with the records requirement of the library’s purpose.
Content types should be as specific as possible. Having a content type called “Budget” is far too general, since under budget there are multiple specific documents used for programming, executing, and tracking government dollars, all with different metadata requirements. Looking in budget’s subfolders on the shared drive and sorting by date in descending order will get one started.
Once specific content types are defined, it is time to align them to their records association. This is done by visiting the National Archives General Records Schedule (https://www.archives.gov/records-mgmt/grs.html) to find a records definition which aligns with the defined content type defined.
(When gathering this information, I’d recommend a table format, something like:
|Content Type|Record Series|Series Title|Disposition|Disposition Date|Disposition Authority|
In time, as new content types get added, they can and should be tracked similarly.)
Finally getting to the Content Management System.
When all of this prep work is done, which is no small accomplishment, it is finally time to turn to SharePoint. As I said, SharePoint does not come OOB configured for records management. In order for the records relevant fields to be added, they must first be created as custom columns. Not only the custom columns of record series, series title, disposition, disposition date, and disposition authority, need to be created, but also any other fields that are necessary for all items existing on the CMS. In the government, this usually includes the government-relative fields of Fiscal Year, Month, Quarter, and some type of Status or Stage (Draft, Final, etc.).
When the required columns are created, SharePoint then awaits the creation of custom content types. In most cases, the unstructured content types revealed in the shared drive analysis showed the bulk of the organization’s content was in document form. Therefore, custom “Document” content types must be created. When creating the content types, the option to “Add from existing columns” must be clicked to add the previously-created custom columns.
(A neat feature that needs mentioning is the ‘Advanced Settings’ option. Under this option, a specific document template can be uploaded and used uniquely for the content type. If a new document is created having chosen this specific content type, the MS Office suite document type will open, formatted as required.)
Here’s where the magic happens!
While it’s completely possible to perform this step with SharePoint Designer, I am fortunate that my agency purchased Nintex Workflows. Regardless, each technology can accomplish the same.
In this step, automated workflows are created to “Set a field value” and “Calculate a date”. These are in quotes because they are the names of steps inside the workflow designers. “Set a field value” is used to set automatically all the text fields, Records Series, Series Title, Disposition, and Disposition Authority. The Disposition Date field must first have its date calculated, saved to a variable, and then set the same way as the text fields.
Once all workflows are developed, again the user must return to the previously-created content types. This time, though, the user should click the ‘Workflow Settings’ option on the content type configuration page. Here, the workflow specific to this content type gets chosen and assigned.
How it all works!
Ok…now with all the custom columns built and assigned to content types, and with document templates uploaded to the Advanced Settings of each, and workflows to assign records management field data are created and assigned to the content types, the site’s libraries must be created.
Once a library is created, the Library Settings must be edited. Here, the user chooses ‘Advanced Settings’ and says yes to the first question, “Allow the management of content types.” After saving, the page returns to the content type settings page. In the mid-section of the page, the option to “Add from existing content types” should be chosen. Here, content types relative to the purpose of the library must be selected. For example, if this is the library for the organization’s Admin group, possibly the content types of Briefing-Presentation, Org Charts, and Personnel Rosters would be chosen as content types relative to the operation of Admin. Operations may share the content type of Briefing-Presentation with Admin, but instead of Personnel Rosters and Org Charts might require content types for Contingency Operations and Weekly Reports. Various content types can be chosen for different libraries. Lists and libraries with the same content types, likely hold very similar content.
It should be noted that the default content type can be changed for each library. In the event that hundreds or more documents must be moved into a library at once and because all newly-created documents arrive first as the default content type, users would do well to change the library’s default content type to that of the content to be deposited.
Once completed and the library is established with assigned content types, it’s time to watch the action. Create a page with a view for the library’s default content type and all its “working metadata” (creator, created date, type, name, fiscal year, month, quarter, stage, etc.) and a second view for Records and the records relevant fields. Then, open Windows Explorer, grab some files and drop them in. Allow the workflows to run and watch the workflows populate the records-relative fields.
Q.E.D.