This document summarizes the configuration and implementation of an Alfresco records management system for a medium-sized agency. Key aspects included: 1) Creating group sites for each department 2) Adding document libraries for each department site 3) Configuring document types, metadata, and record declaration options 4) Mapping documents to a file plan structure based on their type and metadata for retention scheduling 5) Ensuring users could still access documents through their department sites without knowing about the separate records management module

1. Alfresco Records Management
An Approach to Implementation, Part II
July 22nd, 2014 by Deja Nichols
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:
 Configuration
 Implementation

2. 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:
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
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)
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 m etadata 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 mo re
detail later in this blog). Each record uploaded typically only needed one extra piece of information to correctly categorize it for
records management purposes.

3. 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 docum ent
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 wa s
“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 recor d 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.

4. In most cases, we found the user usually knows what they are uploading. They usually upload their own work into the system an d
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?
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.)
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.

5. 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 reten tion
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.)

6. 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 rec ord –
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 off icial
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 th at
point on, knows all the information it needs in order to retain it, and if applicable, dispose of it per policy.

7. 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