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 for a possible lifecycle for an HR Complaint:
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:
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’s the basic aspects that we created in Alfresco that was important to the layout of the system:
- Group sites
- Document library within each group site
- Document types
- Record Declaration
- Seamless User Interaction
- Records Management (RM) Module (aka RM repository or File Plan)
- Workflows for certain documents and records
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.
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.
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.
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 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.
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 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 did’t want them having to go look for their documents in 2 places. We did’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 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.
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.
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.)
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.
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.)
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.
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