I had the opportunity to present on Records Management at this years SharePoint Saturday in Cape Town. (I will be doing a “SharePoint Saturday 3 cities tour” wrap up after SharePoint Saturday Durban next week so watch this space). Anyhow, back to the topic at hand. My session title was around getting your Records Center NARS Compliant. So if you are not in South Africa, this does not apply to you.
The Abstract is as follows:
SharePoint provides organisations with the capability of managing the lifecycle of content created within business. The National Archives and Records Service in South Africa determines legislation pertaining to all this Records Management. This session covers the following:
- What document management in SharePoint caters for
- How policies are applied to documents
- How retention and disposal schedules manage and route documents within libraries
- How physical documents can be managed within a repository
- What NARS defines for metadata and compliance
Companies continue to not know when to destroy documents and it is with this in mind that SharePoint provides Information managers with a concise view of the creation to destruction of content within the organisation.
I did have the “graveyard” shift on the day A.K.A. the last session of the day so my room was not exactly full but nonetheless we had a great discussion on a.) how best to build a records center, b.) what the benefits and c.) the pitfalls of various designs are and also why i choose the path for the build.
Just some background to the session. Last year, Team Ninja (The guys that i work with and I) had to migrate content from Hummingbird to SharePoint 2013. Now Hummingbird is actually used by NARS as their EDRMS (electronic document and records managment solution) product so it made logical sense to mirror the required fields from the product across to SharePoint.
This was no small task as Hummingbirds table structure in the database was rather misleading. After our developer managed to iron out all the kinks in the schema, we were good to go.
So, how did we build the end product; let me break that down for you:
Base Content Type
This was so that all the other content types could inherit the necessary columns (i’ll get back to why in a bit)
We need to structure the main series of the fileplan inside the records center and the easiest way was to create a record library per main series
Information Management Policies
Each content type represented a retention and disposal schedule which is why we created a base content type that every other content type inherited from for the standard columns and the each content type could have its own management policy. That way, we did not have to use folders!!
We created the following types:
- A20 – archive are 20 years
- D5 – Delete after 5 years
- D10 – Delete after 10 years
- D15 – Delete after 15 years
- 999 – Keep indefinitely
From a navigation perspective, it was much easier to represent entering the Main Series through promoted links as they can be wrapped in jQuery to render 5 x 4 on a page
This was built in the term store for easy assignment when selecting the content type. For those hummingbirders, this helps with the term (needs classification).
As this is default out of the box functionality, we did not need to replicate this feature.
- Record Series Indicator
- FilePlan Number (Concatenated as this differs from the actual fileplan number)
- Document Type
- Sub File Number
- Retention Schedule (So that records officers could see it in the view)
The process for declaring a record formed part of a workflow that sent the document to the drop off library in the records center which then, the records officer, would classify and then document was routed to the corresponding record library.
AND thats is. The tool that was built was super easy to use as well. We call it HummingPoint (More to follow about this). Hit me up on my social feed for more information. It also does fileshare migration :-).
Have a look at my slides for more info.
Be cool, My Ninjas