In my February 2021 post A brief history of electronic document and records management systems and related standards, I quoted from a presentation by Philip Bantin in 2001 that summarised the difference between the two systems.
- An electronic document management system (EDMS) supported day-to-day use of documents for ongoing business. Among other things, this meant that the records stored in the system could continue to be modified and exist in several versions. Records could also be deleted.
- An electronic records management system (ERMS) was designed to provide a secure repository for authentic and reliable business records. Although it contained the same or similar document management functionality as an EDMS, a key difference was that records stored in an ERMS could not be modified or deleted.
It could be argued that SharePoint began its life in 2001 as an EDMS and began to include ERMS functionality when SharePoint 2010 was released. So, how is it not an EDRMS?
In simple terms, unlike a traditional EDRMS model that was intended to be the repository for all business records, SharePoint is only one of several repositories that are used to store and manage business records. Instead of centralising the storage and management of records, systems such as Microsoft 365 provide centralised management of records wherever they are stored.
The EDRMS model
Almost all EDRM systems since the mid-1990s have had the following characteristics:
- Compliance with a standard. For example, DOD 5015.2 (1997), AS 4390 (1996)/ISO 15489 (2001), ISO 16175 (2010), VERS (1999), MoReq (2001)/MoReq2, etc.
- A relational database (for the various functions, metadata and controls (see diagram below) and a separate file share (for the actual content/records), accessed via a user interface.
- An expectation that most or all (digital) records would be copied from other systems used to create or capture them to the EDRMS for ongoing storage and protection. This outcome might be achieved through integration with other systems, for example to copy emails to the EDRMS.
The integrated EDM/ERM system model was described in the following diagram in 2008 by the International Standards Organisation committee, ISO/TC171/SC2, in its document ‘Document management applications’:
There are two key problems with the EDRMS model:
- They do not (and cannot) realistically capture, store or classify all business records. Emails have remained a problem in this regard for at least two decades. Additionally, there is now a much wider range of born-digital records that remain uncaptured.
- Many of the born-digital records that were copied to the EDRMS continue to exist where they were first created or captured.
Any organisation that has been subject to a legal subpoena or Freedom of Information (FOI) request for records will know the limited extent to which EDRM systems provide evidence of all business activities or decision making.
And yet, almost every organisation has a requirement to manage records. There is clearly a disconnect between the various requirements and standards to keep records and the ability to keep them.
But SharePoint (on its own) is not the answer.
Why isn’t SharePoint an EDRMS?
SharePoint was never promoted or marketed as an EDRM system. It is not even a relational database (see this 2019 post by Sergey Golubenko ‘Why SharePoint is no good as a database‘ for details).
To paraphrase from Tony Redmond’s recent (21 March 2021) post ‘SharePoint Hits 20: Memories and Reflections‘, SharePoint was originally designed to allow content (including page-based content in the form of intranets) to be accessed via the web, thereby replacing network file shares.
In practice, most organisations retained their network file shares, built their intranet using SharePoint, and otherwise used SharePoint to manage only some digital content.
It could be argued SharePoint started out as an EDM system and became more like an ERMS when more recordkeeping capability was introduced in SharePoint 2011. But that doesn’t make it an EDRMS in the traditional sense of being a central repository of business records.
The reality is that records are, have been, and will continue to be created or captured in many places:
- Email systems. In Microsoft 365, Exchange Online mailboxes are also used to store the ‘compliance copy’ of Teams chats messages.
- Network file shares.
- SharePoint, including OneDrive.
- Other online document management systems, including Google Drive.
- Text, chat and instant messages often created in third-party systems, often completely inaccessible or encrypted.
The type and format of a record can vary considerably. For example:
- An emoji.
- A calendar entry.
- A photograph or video recording (including CCTV recording).
- The recording of a meeting, in video or transcript form, or both.
- Virtual reality simulations.
- Social media posts.
- 3D and digital drawings (e.g., via digital whiteboards).
And, of course, all the data in line of business systems.
Instead of trying to save records into a single EDRM system, Microsoft 365 provides the ability to apply controls over the management of most records where they were created or captured – in email (including archived social media and other records), Teams chat, SharePoint, or OneDrive, and Yammer.
Is there a need for an EDRMS?
There is nothing stopping organisations acquiring and implementing traditional EDRM systems, or even setting up some SharePoint sites, to manage certain high value or permanent records, including some records that can be copied from other create/capture systems (such as email).
But there is also a need to address the management of all other records that remain in the systems where they were created or captured.
In most modern organisations, this requires broader controls such as applying minimum retention periods at the backend, monitoring usage and activity, and the proactive management of disposals. Not trying to copy them all to SharePoint.
Featured image: Lorenz Stoer, late 1500s.
Records about the world 
Good explaining article. We use SharePoint as more an online file system but are looking for something better for . We examined a few NAS options such as PaperOffice, Papermerge and LogicalDoc and all failed the briefest of “sniff tests” falling over when pushed or in case Papermerge OCR that did a reasonable job in Portrait mode by figured anything in landscape was Chinese. LogicalDoc sales person could best could be called an online abuse service provider!
We stumbled across bluebox but a challenge anyone from reading their website to establish what they are selling. I put a call in an awaiting a response.
After a lot of thought what we need is data stored in a “direct access file” system like SharePoint but with a metadata engine over the top that can deal with searches and classification of files by metadata with ideally an automatic fill in of metadata based on some AI approach.
As you write emails are a nightmare to track at a corporate level and we have numerous fiefdoms of data that are only understood by the “lord” that built the directory structure. I am rather a terrible “lord” as trouble with directory structure and filenames is you have limits on file and name based on your rather than other’s needs.
Outlook’s search engine is about as annoying it gets as it does not upfront use standard search logic functions but a typical MS knows better when you bypass the simple search. Coming from Unix “grep” would kill most Window based search engines! But Unix is text based in concept and we are in a world of PDF plus Office documents plus the dreaded email.
PDF and OCR is vital as bad as PaperOffice was for reliability they figured out nice OCR and AI metadata completion. Trouble was once a document got past forty pages it would fall over and support did not want to deal with the Australian time-zone issue.
Anyway, good article and has improved my knowledge.