VIDEO – How to Manually Declare a Record within Alfresco

Recently our team has been asked several questions about how to best utilize Alfresco Records Management for their various government and business needs. In response to that, our in-house Records Management specialist, Deja Nichols, will be posting a series of tutorial blogs that will show various ways to utilize Alfresco’s records management features.

For today’s video, Deja will be illustrating how to manually declare a record within Alfresco.

Stay tuned for more videos!

Alfresco Records Management: An Approach to Implementation Part II

Alfresco Records Management: An Approach to Implementation Part II

In the 1st part of this blog “Alfresco Records Management; An Approach to Implementation – PART 1,” I went over the business case and planning phase for a medium-sized agency that wanted a seamless records management configuration, leveraging Alfresco’ s Enterprise Content Management (ECM) system and Records Management (RM) Module.

To figure out how we wanted to go about design and implementation and how to configure the system properly, we need to get an idea of the basic lifecycle of our documents and records. We needed to see where we were going. To build a castle, you need to know how much total space, land you need etc. What are all the materials you need? What is it going to cost?  Even if it’s just a general idea, it’s best to map out what you want, what is required for the whole project first. You can’t just start out with one room of a castle and “see where it takes you.” I have personally seen that it is the same with building ECM and RM systems. Different documents can have different life cycles but here is a general example of a possible lifecycle for an HR Complaint:HR Document Lifecycle Example

In this blog, Part 2, I’m going to go over our last two general aspects, how we set up and implemented Alfresco in order to accomplish our ideal records management configuration:

  • Configuration
  • Implementation

Steps for creating a Records Management program

In order to best describe our configuration and implementation phase, I want to go over some very basic aspects of how things were set up in Alfresco. Although we had an older version of Alfresco, most of this was out of the box with little configuration. So here are the basic aspects that we created in Alfresco that was important to the layout of the system:

  1. Group sites
  2. Document library within each group site
  3. Document types
  4. Metadata
  5. Record Declaration
  6. Seamless User Interaction
  7. Records Management (RM) Module  (aka RM repository or File Plan)
  8. Workflows for certain documents and records

Alfresco group sites example

Alfresco Group Sites

To break it down let’s start with the basic structure of our company. Like most companies, we have a hierarchical structure, about seven different departments and about 200 employees. Every employee belongs to one department, so we set up each department with a “group site” in Alfresco. (Human Resources Site, Finance Site, Legal Site etc…this is an out of the box feature in Alfresco)

Alfresco Document Library

Each department group site has its own file repository. In Alfresco it is called a “Document Library,” which, per our records policies, was deemed to be the single-source repository for all of that departments’ electronic documents.

Document Types

Each document library can be set up with a unique set of “Document Types” to categorize documents into your file taxonomy. They can also be unique per group sites’ document library. (For example, the Human Resources document library may have “Employee Contracts” and “Resumes” as two possible document types, but Finance may have “Vendor Contracts” and “Invoices” etc.)

The idea was that, upon an employee uploading a document to their department’s document library, they were prompted to select a document type. You can also set up a sub-document type if that was necessary per the retention schedule or file taxonomy.

Metadata

Then, we configured the system to require the user to enter in any applicable metadata for the document they are uploading. (As required by our documents matrix in PART 1). Some of our documents needed to have extra properties (metadata) to help with mapping it to the correct location for retention purposes. Example, for a document type “Resume” we wanted to add the following metadata: “Name of Employee” so that the system knew which records management folder to put it in (which I will go over in more detail later in this blog). Each record uploaded typically only needed one extra piece of information to correctly categorize it for records management purposes.

Alfresco Records Management home page

Record Declaration

The last step when uploading a document that we configured the system to be able to handle was to declare the document an official record, which only showed up on document types that had a retention policy associated with it. If they chose a document type that was predetermined to be a record (as opposed to a non-record), then the user was given the option to choose whether or not the document they were uploading should be declared as an official record. What this means is that if this document was “complete” and ready as an “official record,” then checking that box would immediately declare it an official record upon ingestion. But if the document was still a “work in progress,” and not yet an official “record,” the user could simply leave the box unchecked and declare the document an official record at a later date, when it is fully completed. (Example: If the document type is a “Contract,” and it is still being worked on when it was uploaded, they would not check the “declare record” box, upon ingestion. But, then after some time, when that contract gets officially signed, they can declare it a record at that time).

For us, the word “Complete” was defined per document by the document matrix. Basically, it is “when a document is considered complete” and/or “at which point it becomes the official record.” For us, one example of the declaration criteria was: “After the document (in this case, a contract) was officially approved AND all stakeholders had signed-off on it, it could be declared a record.” For some records, this was not applicable, such as articles of incorporation, bills, financial statements etc. These were automatically official records upon ingestion and immediately sent to the RM module for retention regardless since they were un-editable documents. So obviously anything of that document type was given the option to “declare it a record,” and it was automatically declared after ingestion.

Process for declaring a record

In most cases, we found the user usually knows what they are uploading. They usually upload their own work into the system and they usually know if that work is still “in progress” or “complete” etc.  We also found that it was not even necessary to teach users the document matrix because most of them knew what they were working on like the back of their hand. Thus, this method worked for us and we did not have to turn our end users into Records Managers! They only needed to know 3 basic things:

1. What the document type was (invoice, contract, financial report)

2. What the metadata was (date of document or name of an employee, etc., usually only one piece of extra information was needed)

3. Is it still being edited or otherwise worked on, or can it be declared a record now?

Seamless User Interaction

We wanted our users to be able to see the records in their own context. What I mean is, we didn’t want them having to go look for their documents in 2 places. We didn’t want them to have to worry or even know about the RM module in Alfresco. All they needed to know was that they upload documents to their group site and the RM works behind the scenes. So we set it up so that if they are searching for documents on their group site, documents that were sent to the RM module (from that site) also show up in the search results. They can open it and view it, collaborate on it without ever leaving their group site. (You can also set up a visual indicator on each document as an “official record” so you can tell which ones have been sent.)

Alfresco Records Management in place records declaration

Alfresco Records Management Module

When someone sets up the Alfresco RM module it will allow them to create folders in what is called a “File Plan.” Then the Records Manager can set retention rules (that coincide with the retention schedule) on those folders. From there, the documents can be mapped to the File Plan folders (using the documents matrix as a guide) when a document type and metadata combo is placed on a document and then declared a record. That File Plan folder runs the retention on the documents from there.

Alfresco Records Management module file structure example

 

When the user selects “Yes” to the question “declare official record?” (whether upon ingestion or later declared), it tells the system that this file can now be sent directly to the File Plan in the Alfresco RM Module.

Example

Now let’s take a look at a practical example of how a file gets uploaded into the system and ends up in the file plan and retention policies applied to it. (The characters indicated in green will be our input variables.)

Actor: Wants to upload an old invoice they found into the Finance group site. First enters in the document type: “Invoice.” Next pops up, because “invoice” was selected, the required metadata for the document type “Invoice” which was configured to be “Year.” Actor enters in a year: “2007.” Since “Invoice” doc type has a retention period connected to it, per configuration, the actor sees the checkbox up for “Official Record?.” Actor chooses to “check” the box which = true (or Yes).  Computer: from this input, knows exactly:

  • Where to put this file (was configured to: RM Site/File Plan/Finance/Invoices/2007)
  • When to put it there (was configured to: “Declare Official Record?” yes = immediately an official record = sent to file plan immediately)
  • How long it stays there (Document was placed in the Invoice folder. This file will keep records for current year + 6 years per the rules placed on it by the Records Manager. Also since it was placed in the “2007” folder, the system knows when to start the retention) [current year + 2007 + 6 = 2014]…this document is discarded on Jan 2014.)

Alfresco Records Management uploading a document

 

If a document is not ready to be declared an official record upon ingestion (if you are still editing a contract for example) then one can keep it in the system and declare it a record when it is ready/complete/approved etc.

typical RM life cycle

 

This diagram (above) shows the flow of a typical record lifecycle. Flow: upload, assign doc type and metadata, if not yet record – edit/collaborate, later declare record, retain and discard (if applicable), etc. Upon upload, the document has its entire life already mapped out for it, depending on the configuration of the document types, metadata and file plan. (Please note, there are some official records that are never discarded and have a “Permanent” retention. The file plan can accommodate for these types of files as well and the above model would need to be slightly modified to account for that. You don’t even need to ask if it’s an official record or not on permanent records as discussed earlier in this blog.)

Workflows

Another popular option when declaring a record is to put the document through a workflow that takes it through an approval process, and once the document gets approved via the workflow, it automatically declares itself a record. The system, from that point on, knows all the information it needs in order to retain it, and if applicable, dispose of it per policy.

The creation of workflows is an important step to know what kind of workflows your company needs for records and documents/files, etc. This may be intimately connected to the lifecycle and management of your records so I suggest keeping it in mind when mapping out your system. For more information from Armedia about Workflows in Alfresco, see our Blog Subsection on Alfresco Workflows.

In Closing

This approach is primarily a “day forward” solution. When it comes to migration, there may need to be a different approach so files can be ingested into the new system and arrive at the correct location within Alfresco.

Also, I would like to note that this approach might work best with a customized user interface for more flexibility.

There are many different ways to go about implementing Records Management, and companies need flexible customization that will work for their business processes and records management needs. This method can help you get started on your own configuration and implementation.

For more information on Records management, check out our white paper: “Records Management: An Approach to Getting Started”

To read more Armedia Blogs about Alfresco, See these links: Alfresco Records Management, Alfresco ECM

Alfresco Records Management – An Approach to Implementation Part 1

Implementing Records and Information Management (RIM) can be a juggling act.

Balancing_Components_Of_RIM_Strategy


Many record managers are faced with several major issues in applying RIM best practices to their businesses.  In this two part blog, I want to go over how I helped implement a seamless records management approach in a mid-sized company using Alfresco, an Enterprise Content Management (ECM) system. There are four general aspects I would like to address in these two blogs:

  1. How we structured our vision with company-wide content policy and standards
  2. How we mapped out what documents we had and the requirements around them
  3. How we configured the system so that it worked for us
  4. How we implemented the solution

Steps for Creating a Records Management Program   In this blog, Part 1, I want to start off with how we got organized in order to leverage records management best practices with Alfresco and the Alfresco Records Management (RM) Module. The objective was to meet our complex records management requirements; gain tighter governance on our unstructured data and content silos; and speed up collaboration efforts within the company.

The Problem

One of the situations we faced, with regards to records management, was the amount of unstructured electronic documentation we had and the numerous retention periods for each type. There were physical records that needed to be ingested into the system as well. On top of that we had several repositories that we needed to “sift through” and migrate to the new system.  In a company such as ours, we have many different types of government programs that called for different documentation and retention for each type of program. So the retention schedule was complex and had to cover hundreds of thousands of documentation. We wanted to be sure we could get a handle on our electronic documentation by implementing a retention schedule but we did not want to make every employee into a Records Manager to do so! We wanted every user to be able to upload their documents quickly and let the system handle the life-cycle from there on out! It sounds too good to be true but it can be done!

The Solution:

First let’s dive into the subject of records management and policy. In order to build a castle you better create the blue-prints first. So to build our “castle” our “blue-print activities” were:

1. Defined business policy and best practices for documents, records and emails

  • This defined what the different types of documentation we had company-wide; what was an “official corporate record” and what was just “miscellaneous documentation.” It also detailed out how we would manage emails, hard copy files and storage.

2. Defined record retention schedule and disposition  policy

  • This defined, per our governing bodies, what the laws were pertaining to the retention of each of our official corporate records, electronic or not. It also detailed how long we, as a company, are going to keep non-records and miscellaneous documentation.

3. Defined a record holds policy

  • This defined what the protocol was for any necessary “legal holds” or “Freezes” on records, and under what circumstances.

4. Defined vital records policy, disaster recovery and offsite storage policy

  • This was a plan that laid out what records were vital for the company, vital to operate on a daily basis. If anything were to happen to these records, this plan laid out a speedy recovery of this information.

In addition to the above activities, for our project, we needed to detail out an additional step: 5. Created a “documents matrix.” This was a simple spreadsheet that tied in all of the RIM and ECM details needed on every document. It listed out every document the company produced and it  included:

  • The name of each document that will be uploaded to the system
  • The document type and any sub document types for those documents/records
  • Document status. (Whether it was an “official record” or not. Not all documents  are “official records” per the retention schedule, so this matrix can help differentiate the two.)
  • Custom metadata that’s needed for each official record (We had at least one “property” – metadata – that was required to be added to a document for retention purposes, which I will go over in more detail later)
  • Originating department and “document owner” for each document/record (those positions in the organization entrusted as the custodian of that record and who had disposition authority over them)
  • Retention schedule (e.g. “Active + 6 years” or “Permanent” or “Current Year +2” etc.)
  • Criteria for becoming an official record (e.g. “when a contract is approved and signed” etc.)

 

Document Matrix. Please Note- This is an example, all information fields may not apply.

Document Matrix. Please Note- This is an example, all information fields may not apply.

Analyzing and documenting within the spreadsheet simplified the configuration of Alfresco + Alfresco RM plug-in to fit our document collaboration and records management needs into one spreadsheet. By researching and fully mapping out which documents  were official records, which ones were not, what to do with the official records, when to do it etc., allowed our project team to customize a seamless records management approach. Moreover, it was important to know: what we have, where it goes and  when does it goes there. Otherwise, it is hard to meet both content management and records management requirements. After creating these policies the next thing to do was get them out to the people responsible for implementing them. The general employees did not need to know the retention schedule but they did receive the policy on what was a “official record,” what is not, what to do with important emails etc. To do this we held workshops with the executives and then held departmental luncheons to discuss the basic policies and guidelines that pertained to them. We stressed how employees needed to know which documents were important for the company and which ones are “OK to shred.” (AKA, what is an “official record” [has legal ramifications] and what is just a “document” [does not have legal ramifications]) This concept is nothing new and most employees already know their own documents cold. They know not to shred a contract and they know that the company weekly plan, that everyone got a copy, of is theirs to keep or shred.  So learning the new policy was not entirely too daunting.

For full comprehensive tips for starting an ECM implementation project see the Armedia whitepaper on “Creating an ECM Advisory Board and Program Charter” by Ronda Ringo.

In closing: Working on the board of my local ARMA Chapter (Association of Records Managers and Administrators) for several years, I’ve noticed companies were having difficulties implementing records management because they were trying to teach their individual employees records management. This puts all the stress and obligation on an individual employee and adds a considerable amount of time and training. This can be a lot of hours lost that can be used for better investments. All employees should not have to become expert Records Managers to be able to manage their electronic content. Setting it up in this way, the only thing our employees need to know was what they already knew, basic details about their documents, and the system does the rest!

 

In my next blog “Alfresco Records Management; An Approach to Implementation – PART 2” I will go over how we used Alfresco and implemented this seamless records management approach.

Slides From Today’s Webinar

In case you missed today’s webinar in which we walked through our ArkCase solution framework with Alfresco Records Management, here are the slides from the presentation!!

 

ArkCase is a web-based, workflow-driven case management software solution designed to help organizations capture, investigate, and manage cases.

Powered by Alfresco, ArkCase provides a complete case management infrastructure to create and manage case information through its lifecycle. From initiation, assignment, investigation, evaluation and disposition ArkCase tracks the case and the relationships to all of the collected information. ArkCase provides pre-built law enforcement and inspector general workflows and data types, and can also support other organization types.

In this webinar, we walked through

  • How to declare a record in Alfresco Records Management within ArkCase
  • How ArkCase delivers easy compliance with Presidential Memorandum on Managing Federal Government Records as well as paperless initiatives

Stay tuned for a recording of the webinar!