Records Management User Guide

cancel
Showing results for 
Search instead for 
Did you mean: 

Records Management User Guide

resplin
Intermediate
0 0 14.2K

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com

Records Management

IMPORTANT
The module described here is NOT the interface recently certified against DOD 5015.2.
If you're looking for the certified module, please start here: Records_Management


Note: The Alfresco Record Management AMP is an example implementation and is unsupported.

Table of Contents

Overview

Alongside Release 1.4, the Alfresco Records Management module is an extension of the core Alfresco Enterprise Content Management system for managing the life cycle of electronic and other types of records. The records management capabilities are accessible from all Alfresco interfaces, such as the web client, virtual file system and file serving servlets, because the functionality is implemented as extensions to the core content services.

The Alfresco Records Management module is implemented as a separate domain model with new mixins for records, records folders and file plans. In addition, there are JavaScript procedures located in the Data Dictionary/Scripts space with other standard scripts. There are space templates for fileplans with attached rules and actions. Finally, there are some time-based procedures for invoking various cutoff, hold and disposition actions.

DOD 5015.2 Structure

The Alfresco Records Management capabilities are modeled to support the US Department of Defense 5015.2 Records Management standards. These standards are used to evaluate the capabilities of Records Management Applications and define the requirements for managing records within the department.

Finding the DOD 5015.2 Test Data

The software is distributed in the file alfresco-recordsmanagement.amp which can be downloaded from: http://sourceforge.net/project/showfiles.php?group_id=143373

The DOD 5015.2 test suite is made available as an example of how to use the Alfresco records management module.
Test data is automatically loaded after MMT on the AMP file, and restarting the alfresco server.

  • Go to the 'Company Home'
  • There you will see Records Space.

This contains:

  • DOD Records Space - file plans laid out based upon the 5015.2 test suite
  • A Transfer Space - area for files to be transferred or archived
  • A User Space - for the users specified in the 5015.2 test suite

And as contents:

  • A PDF file description of the DOD 5015.2 specification
  • A word file containing the DOD 5015.2 test plan

initial_record_space.gif

File Plans

File Plans are a description of the plans for the following record services:

  • numbering
  • classification
  • disposition (transfer of records and/or the ultimate destruction of the record)
  • other metadata population of records. .

Records are usually grouped according to their file plan, so file plans are implemented as folders (extended spaces) with a 'rma:filePlan' type. This type contains all the metadata definitions for implementing the life cycles of the records contained in the folders. The file plan also carries with it a set of rules for evaluating new records that are entered into the file plan.

Please note: (as of v1.3) Fileplans seem not intended to be cascading. So a fileplan may contain records and record folders.

fileplan.gif

File Plan Metadata

File plans are modeled using the metadata of the space, so the values are set using the Properties dialog of the file plan.  The metadata type for the rma:filePlan mixin includes the following core data:

PropertyDescriptionDatatype
rma:recordCategoryIdentifierRecord Category Identifiertext
rma:dispositionAuthorityDisposition Authority - a reference number to the regulations that govern the dispositiontext
rmaSmiley TongueermanentRecordIndicatorPermanent Record Indicator - should never be deletedboolean
rma:dispositionInstructionsDisposition Instructions - a human readable description of how the records associated with the file plan will be handledtext
rma:containsRecordFoldersContains Records Foldersboolean
rma:defaultMediaTypeDefault Media Format - made available to simplify data entry for the record and is usually electronic or papercategory
rma:defaultMarkingListDefault Marking List - handling and classification information that are printed at the bottom of the record, such as UNCLASSIFIED or NOCONTRACTcategory
rma:defaultOriginatingOrganizationDefault Originating Org - made available to simplify data entry for the record and assumes that originating organizations are the same for the information in the file plantext

[ToDo : What about the 'permanent record id' checkbox next to ?]

Vital Record Information

The rma:fileplan type can mark files stored in it as vital records.  Vital records must be reviewed on a periodic basis such as annually or quarterly. 

PropertyDescriptionDatatype
rma:vitalRecordIndicatorVital Record Indicatorboolean
rma:vitalRecordReviewPeriodVital Record Review Periodcategory

Record  Cutoff Information

Records in a file plan are cutoff periodically to simplify the handling of records for lifecycle management.  File plan specifies whether the records are to be cutoff or not, what event might trigger the cutoff.  The event can be a timer or a discretionary action, i.e. obsolescence or being superseded.  After being cutoff, records may be held for a period, transferred or destroyed.

PropertyDescriptionDatatype
fileplan_cutoff.gif
rmaSmiley TonguerocessCutoffProcess Cutoffboolean
rma:eventTriggerEvent Triggertext
rma:cutoffPeriodCutoff Periodcategory
rma:cutoffOnObsoleteCutoff When Obsoleteboolean
rma:cutoffOnsupersededCutoff When Supersededboolean

Record Holding or Retention Period Information

After being cutoff, records may be held for a period of time before further disposition is handled. Normally this period is measured in years. Metadata in rma:fileplan indicates whether to process a hold or not. If a hold is not process, further disposition is handled immediately, such as destruction. A hold can be discretionary, such as after a change of command, and thus must be monitored manually. The discretionary hold flag allows the records management module to track these manual checks.

PropertyDescriptionDatatype
rmaSmiley TonguerocessHoldProcess Holdboolean
rma:holdPeriodHold Period in Yearsfloat
rma:discretionaryHoldDiscretionary Holdboolean

Records Transfer Information

After being held for the mandatory period of time or upon the lifting of a records freeze, a record manage may be transferred to a records holding area or other records retention area. The rma:fileplan determines how and where a record will be transferred and in what size blocks for organizational purposes. Upon execution of records transfer, the records and their metadata are moved to the space indicated where upon the agency can use the space export to move the records to the appropriate authority.

PropertyDescriptionDatatype
rmaSmiley TonguerocessTransferProcess Transferboolean
rma:defaultTransferLocationTransfer Locationtext
rma:transferBlockSizeTransfer Blocksize in Yearsfloat

Records Accession Information

Records to be held permanently must be ultimately be transferred to the national records authority. In the US, this is the National Archives and Records Administration or NARA. The rma:fileplan specifies an area for accession transfer and the size of blocks in years for organizational purposes.

PropertyDescriptionDatatype
rmaSmiley TonguerocessAccessionProcess Accessionboolean
rma:accessionLocationAccession Locationtext
rma:accessionBlockSizeAccession Blocksize in Yearsfloat

Records Destruction Information

If records in a file plan are to be destroyed, they are marked in the Alfresco system to be permanently destroyed so that all information, metadata and physical trace is removed and cannot be recovered.

PropertyDescriptionDatatype
rmaSmiley TonguerocessDestructionProcess Destructionboolean

Miscellaneous Lifecycle Metadata

Additional information is maintained to simplify the handling of records. This includes a counter for the records in a fileplan.

PropertyDescriptionDatatype
rma:filePlanNoteNote for presenting any other handing information for the usertext
rma:recordCounterRecord Counterint

User Defined Information

A simple user defined mixin for records called rma:userSpecifiedData. The base definition has privacy act information used in the DOD 5015.2 tests. Any data can be specified.

Creating a File Plan v 2.0

The way to create a file plan has changed from v 2.0

To create a file plan follow these steps:

  • Click the Create menu
  • Select 'Advanced Space Wizard'
  • Select 'From scratch' and press 'Next'
  • Select the 'File Plan' space option and press 'Next'
  • Fill in the name, title and description of the file plan using a name and description that helps navigation between many file plans
  • Select 'Next' then 'Finish' to create the file plan
  • On the new file plan, choose 'View Details'
  • Click the 'Edit' button on the Properties
  • Enter the metadata according to the requirements of the file plan
  • Click 'OK' and the file plan is ready to process records

Records

Records are content items entered into a file plan. Records can be of any mime type and can be of any content type. In addition, other aspects are also allowed. Rules attached to the file plan automatically attach a 'rma:record' aspect to the record and fill in metadata according to the definitions in the file plan.

Managing record life cycle is done through the file plan properties and the metadata associated with the record. The Records Management Module adds aspects for each stage of the lifecycle and this data, mainly dates, can be managed using the standard properties dialog, which has been extended for records aspects.

Record Metadata

The record metadata adds classification information to the record, and controls the lifecycle of the record. Some of the lifecycle behavior comes from the file plan, and some from the aspects attached to the record.  According to the disposition instructions stored in the file plan, records are retained or destroyed. Aspects attached to the record can cutoff the record for processing, hold the record for future reference and ultimately either transfer the record to another authority or destroy it.

Record Properties.gif

The core aspect for holding metadata for records is the rma:record aspect. This aspect describes the subject matter of the record, the content of the record, handling and processing information of the record.  The metadata stored in the rma:record aspect is:

PropertyDescriptionDatatype
rma:recordIdentifierUnique Record Identifiertext
rma:subjectSubjecttext
rma:formatFormattext
rma:mediaFormatMedia Formatcategory
rma:dateFiledDate Fileddatetime
rmaSmiley TongueublicationDatePublication Datedatetime
rma:dateReceivedDate Receiveddatetime
rmaSmiley SurprisedriginatorOriginatortext
rmaSmiley SurprisedriginatingOrganizationOriginating Organizationtext
rma:addresseeAddresseetext
rmaSmiley SurprisedtherAddresseesOther Addresseestext
rma:supplementalMarkingListSupplemental Marking Listcategory
rma:isObsoleteObsoleteboolean
rma:recordNoteNotetext

In addition, there are a number of mandatory mixins that get attached as a result of attaching the rma:record mixin. The purpose of these mixins is automatically capture information retrieved from metadata extraction actions and to take advantage of other Alfresco actions such as auditing. The additional aspects include:

cm:auditableAuditing for changes to the record
cm:authorTracking the author and auto-capture of metadata
cm:referencingTracking when a record references another
rma:supersededTracking when a record is superseded by another
rma:userSpecifiedDataMixin for user defined information

Capturing Records

In order to enter records into the system, the clearest way is to simply navigate in the web client to the specific file plan into which the record is to be entered and use the 'Add Content' button to add the record. Assign the name, type and content type as normal. Leave the 'Modify all properties when this page closes' checkbox checked.

After clicking OK, a set of rules in the file plan are executed. These rules modify the record in the following ways:

  • Attaches the record mixin to the document.
  • Extracts any metadata from the record file, such as metadata stored in office documents or PDF.
  • Runs JavaScript actions that populate the metadata and sets security based upon information stored in the file plan
  • Prepends the name with the record id generated using file plan data (If the file plan id is '0031-01', then a document called 'Memorandum to All Personnel.doc' would be renamed to '0031-01-0001 Memorandum to All Personnel.doc'.)
  • The life cycle of the record is calculated based upon disposition information in the file plan

After storing the record and all information is pre-populated, then the properties dialog is presented to the user to fill-in all relevant record information. It is possible to have all record information pre-populated if sufficient information is stored in the file plan.

Using CIFS to Capture Records

It is also possible to create a record by dragging and dropping information using the CIFS interface. This makes it easy to move large numbers of documents and make them records. However, it is not possible to enforce mandatory capture of metadata using this method and is only recommended if there is sufficient information in the file plan to pre-populate record metadata. In addition, the web client URL link in the CIFS interface can be used to view or update record information.

Capturing Microsoft Exchange E-mail Records

Using the CIFS interface, you can drag and drop e-mails from Microsoft Outlook into the file plan space. The Alfresco system will extract the metadata from e-mail files and populate information such as who the e-mail is from, who the recipients are and the subject of the email. It is recommended that the file plan contain all other information or that a workflow be set up to capture any remaining information.

To recover e-mails from the records repository, use the CIFS interface to drag the e-mail files back into Microsoft Outlook.

Managing Record Lifecycles

When the record is entered into the repository and all record properties (from rma:record aspect) have been set, the lifecycle of the record is computed. The lifecycle determines the disposition of the record.  This includes events such as when the records will be cutoff or grouped together, how long the records will be held, and what happens to the record after the hold period expires, such as being transferred to a records holding area or whether they should be destroyed.

The records management module refers to information in the file plan whenever an event occurs to a record. These events can be based upon a timed-event such as an expiry date, an update event such as being marked obsolete or superseded, or a combination of timed and updates events.

Obsolete Records

A record can be marked obsolete either manually (through the UI), or through instructions in the file plan.    To mark a record as obsolete, check the 'Is Obsolete' flag in the properties dialog and save. Upon save, if the file plan determines that records are to be cutoff or deleted, then they will be handled as such.

Superseding Records

One record may supersede another. When this happens, the record that is superseded should be marked referring to the superseding record.  This is a two step process.  First, click 'Superceded' Action to the right of the record.

NewRecordAction.gif

The record will be marked superceded, and a new properties section will appear.   Use the search to select the record that supersedes this one. Upon save, the file plan determines whether the record should be cutoff or deleted.

record_supercede_properties.gif

Vital Records

If the file plan indicates that records associated with it are vital records, then a vital record review aspect is added and computed to the record. The aspect manages the previous and next review period. When the previous review is set, on update the next review period is automatically computed for the next date. This period is determined by the file plan. A report or query is used to determine which vital records in a file plan are due for review.

The information contained in the rma:vitalrecord aspect includes:

PropertyDescriptionDatatype
rma:isVitalRecordVital Recordboolean
rmaSmiley TonguerevReviewDateLast Review Datedatetime
rma:nextReviewDateNext Review Datedatetime

Cutoff

The cutoff of a record is determined by the definition in the file plan. If the process cutoff flag is set in the file plan, then the record is cutoff when its time has expired, if it is obsolete or if it has been superseded, depending on the information in the file plan.

If the process cutoff flag has been set in the file plan, the file plan adds and computes the rma:cutoffable aspect to the record. The aspect stores what criteria are required to cut a record off and when a cutoff has been processed.

A cutoff can be executed either by a timed process that looks for expiry periods in the cutoff date, a cutoff as a result of a record being marked as obsolete or superseded, or by a discretionary cutoff. A discretionary cutoff, such as cutting off a record upon change of command, can be executed by marking the cutoff now flag and saving. For records to be removed or transferred immediately, the cutoff period should be set to zero and records will be cutoff immediately leading to the next lifecycle state.

When a record has been cutoff, the Alfresco records management module determines the next state based upon the file plan associated with the record: hold, transfer or destruction. The aspect for that lifecycle state is applied and calculated by the records management module.

The rma:cutoffable aspect contains the following metadata:

PropertyDescriptionDatatype
rma:cutoffExecutedCutoff Executed - whether cutoff has been executedboolean
rma:cutoffNowCutoff Now - flag to execute cutoff nowboolean
rma:cutoffDateTimeCutoff Date - the time at which cutoff is scheduled - usually measured in months or yearsdatetime
rma:cutoffEventCutoff Event - event that forces cutofftext
rma:cutoffObsoleteCutoff On Obsolete - flag to determine whether to cutoff when record is obsoleteboolean
rma:cutoffSupersededCutoff On Superseded - flag to determine whether to cutoff when record is supersededboolean

Record Hold or Retention

A record may be held for a certain period of time prior to being deleted or transferred. Whether the record is held is determined by the file plan. After the cutoff, if a hold is applicable, then the rma:holdable aspect is applied to the record and the hold date is calculated based upon data in the file plan. If the period of the hold is discretionary, such as being based upon a human interpreted event, then a flag is set to track whether these events have occurred.

A hold can be extended at the discretion of those responsible for managing the record. This is set by setting the freeze flag on the hold aspect.

If a hold is not discretionary and no freeze is in effect, a timer will expire the hold and move the record to the next phase of the lifecycle which is either transfer or destruction.

The metadata in the rma:holdable aspect includes:

PropertyDescriptionDatatype
rma:holdExecutedHold Executedboolean
rma:holdUntilHold Untildatetime
rma:holdIsDiscretionaryDiscretionary Holdboolean
rma:holdUntilEventHold Until Eventtext
rma:freezeFreezeboolean

Transfer

If after a hold, a record is to be transferred according to its file plan, then records management module automatically moves the record to a temporary holding area awaiting transfer. Typically records are transferred to a central records management location or another agency. After completion of the hold, the rma:transferable aspect is attached to the record and the transfer location and date for transfer are computed. A timed process is used move records to the transfer area.

Transferring the record is a manual step from the holding area. The standard Alfresco export mechanism or a JCR export can be used to package records in a form that is easy to load in a central location.

The metadata associated with the rma:transferable aspect includes:

PropertyDescriptionDatatype
rma:transferExecutedTransfer Executedboolean
rma:transferDateTransfer Datedatetime
rma:transferLocationTransfer Location in xpath syntax; i.e. /app:company_home/cmSmiley Frustratedpace/cmSmiley Frustratedub_x0020_Spacetext

Accession

Accession is the transfer of records to the national records archive for permanent storage. Very similar to the transferable aspect, the rma:accessionable aspect tracks what records have been transferred and on what date it is due.

The metadata associated with rma:accessionable includes:

PropertyDescriptionDatatype
rma:accessionExecutedAccession Executedboolean
rma:accessionDateAccession Datedatetime

Destruction

For records that are due for destruction, the file plan attaches a rma:destructable aspect that computes the date for destruction. This date is generally calculated after the expiry of a hold or cutoff. The aspect manages a destruction date, after which a timer process removes all traces of the record.

In order to ensure complete removal, the sys:temporary aspect is attached, which informs the Alfresco system to remove all traces of the record.

The metadata for rma:destroyable includes:

PropertyDescriptionDatatype
rma:destructionDateDestruction Datedatetime

Records Folders

Sometime records are grouped together due to sharing common cases or studies. To support this, spaces created inside of file plans are considered Record Folders. Record folders can store individual records that are related together. However, lifecycle information and aspects are not applied to the individual records, but to the records folder.

Record folders are created as an ordinary space in a file plan just as individual records are created in the file plan. The record folder space has the rma:record aspect applied to it and all lifecycle stages are calculated on that space. In addition, the records folder is given a unique record id as well. In this way, all records related to a case or study are handled as a whole and either archived or deleted as a whole.

Records associated with a case or study are then stored in the records folder. These records will also have the rma:record aspect added to them, but lifecycles are not calculated on the individual records. The name of the files are automatically generated just as they would be if they were placed in the file plan. However, the record id is derived from the records folder, not the file plan directly. Disposition of records in the record is handled by the record folder.

[ToDo: What happens, if 'Contains records Folders' is not checked in Fileplan metadata]

Query

Metadata from various records aspects is included in the search form to help search for specific records based upon records processing information. Since records are aspects, the original metadata is still searchable.

Searching for Records

To search for records, follow these step:

  1. Click 'Advanced Search' in the search box on the upper right corner of the web client.
  2. Click the 'More search options' triangle.
  3. Click the 'Additional options' triangle. The metadata that begins with 'RM:' is specific to records management.
  4. Fill-in the criteria you are searching for.
  5. Press search.

The results are presented the same as any other search.

Reports

A report is automatically set-up as part of the file plan template in the space templates of the data dictionary. The records report is presented whenever the user enters the file plan space using the FreeMarker Template Engine.

Records overview.gif

Report Definition

This report is defined in /Company Home/Data Dictionary/Presentation Templates/records_report.ftl. This report can also be applied to spaces that contain multiple file plans and aggregate results across multiple file plans. This file can be used as an example of how to set up your own records reports.

The report is broken up into six main areas:

  • Recent Records - records that have recently been added and sorted on the received date
  • Vital Records for Review - records that are due for review in the next week sorted on the review due date
  • Records Due for Cutoff - Records that are due or soon to be due are listed sorted by their cutoff date
  • Records Retention Due for Expiry - These are the records whose hold is due to come off if no freeze is put in place
  • Records Due for Transfer - These are the records due for transfer to a specific location (tbd: add transfer location to report)
  • Records Due for Destruction - These are the records that are due for destruction in the next week or whose destruction is past due, but not deleted

Acting on the Report

In the following example, the report lists out a record due for vital record periodic review. The record has a number of icons and links to perform actions on the records.

records_report.gif

The purpose of the links and icons are as follows:

  • ID and Properties Icon - These list the record id and link directly to the records properties for update of metadata.
  • Title and Content Icon - The title of the document and its related file icon fetch the content directly into the web browser for read-only viewing of the content
  • File Plan Folder and Properties Icon - The name of the file plan and properties icon next to it access the properties of the File Plan, whereas the space icon links directly to the contents of the file plan
  • Originator - Currently for informational purposes only
  • Date Filed - For record identification only
  • Other Dates - Depending on the report, an additional due date is provided related to the action of the report

Scheduled Jobs

Coming soon.

More Information