18 June 2024
Dr. Nikola Milanovic
Chief Technology Officer (OPTIMAL SYSTEMS)
A document management system (DMS) is principally designed to store (archive) data, such as digital documents of all kinds and their metadata (information that describes the documents), and to make them searchable and retrievable. This may have been true as late as even a decade ago, but it does not hold anymore: the expectation is that a DMS provides solutions to concrete business problems, and not (just) a technical document repository.
One such problem is how to create digital content, collaborate while doing so and share it. There are, of course, other concrete business cases which a DMS must fulfil today, such as processes for invoice approval, contract management, project management, and many others. They are usually based on enacting business processes using a workflow engine. But today I will focus on content collaboration and not workflows. Partly, because collaborating on content is an orthogonal topic: it’s relevant for many (not all) other business cases for a DMS.
There are several challenges that need to be addressed when creating digital content: storage, versioning, (real-time) collaboration, automated document generation, security, sharing and integration with popular communication and collaboration platforms such as Microsoft 365 or Google Workspace.
Let us start with the last: a DMS should not (and cannot) implement collaboration functionality such as chat, online editing, or videoconferencing. It would be almost absurd if a DMS were to try this. It should provide meaningful interfaces to existing platforms instead. In this article we will use the integration with Microsoft 365 (Teams, Office Online) as an example. The text would not be much different if we chose Google Workspace.
Also, all concrete examples in this article will feature enaio®, which is a document management system provided by OPTIMAL SYSTEMS. The requirements would not be much different if we chose a competitive product.
The first, and most obvious, advantage of using a DMS for collaboration is that it provides a centralized platform in which to store all documents and information which is being collaborated on. No need to track numerous copies of the same document on different local storages or spend time on finding the most recent version. Using the powerful security and versioning control mechanisms of a DMS makes it no longer necessary to store local copies of multiple versions of a document. It is furthermore very easy to restrict access to versions of a document. Using versioning makes it possible to work on many versions of a document at the same time, while “freezing” one version which is published to the outside world. The following figure shows how different document versions (here depicted in enaio®, they are called variants) can coexist as one object in a DMS system:
This avoids the tedious necessity of differentiating document versions using file names or directory structures or some combination thereof.
A DMS can also help when generating content: there is a system of templates with “placeholders” which are filled with “live” data. For example, address data for a contract party or medical results from a laboratory report can be inserted into a document template. In enaio®, this mechanism is called data transfer, and it enables assisted collaboration when generating documents: one user group can create templates, another can import data that feed those templates, and yet another can use templates and data to produce the final documents.
So, now we have documents stored in a DMS, and want to work together on them with colleagues. How to solve concurrency issues? Of course, a DMS can lock a document while one user is working on it. This is good, because it prevents other people from working on it at the same time and guarantees document integrity. But is this really a good thing? Do we really want to pessimistically lock documents and effectively prevent users to collaborate on them? The next thing that will happen with this approach is: people will forget to unlock them when they are finished, so documents will remain locked (or in enaio®: checked out), and thus cannot be edited further. Sounds familiar?
This was the usual problem of the first generation of source code version control systems: in a typical office, you would often hear a shout between developers: “Hey, can you please check in the loader class? Please, please, I want to continue working on it”. Luckily, we got chats at some point, so there was no need to shout at the office anymore. And then we got git. With git, for the first time, it was possible to work efficiently on the same code (among other great things), and the changes were automatically merged. Microsoft 365 (specifically Office Online) as well as Google Workspace can do the same with office documents. So, a DMS needs to simply integrate these functions, instead of locking documents the users are working on.
In enaio®, for example, this integration is implemented very seamlessly:
one version of a document is stored in a DMS. If users want to edit a document, they simply do this in Office Online, directly from enaio® client. Anyone else can join in the session and collaborate in real time—this is a standard Office Online function. Once the last user leaves the editing session, the final version is saved back to enaio®. This is, in my opinion, a great example of combining the centralized storage of a DMS and the flexibility of a cloud service such as Office Online. The DMS remains the “single point of truth” as a document storage.
It also controls access rights. During an editing session, a version of a document “leaves” the DMS and is only transiently saved in a protected storage in Azure. No one else can access this document in Azure. After the editing session expires, the last document version is saved back to enaio®, and the temporary working copy in Azure is deleted. During the editing session, all access rights from enaio® are respected, so there is no information disclosure to unauthorized users. This is truly a “best of both worlds” integration.
Now, we can store documents in a DMS, control access rights and versions and even collaborate on them in real time. How about communication? Of course, every DMS can generate a link to an object and send it via e-mail. But this is so out of date. What we really want is to integrate into modern communication and collaboration platforms, such as Microsoft Teams or Google Chat. Which is exactly what enaio® does with MS Teams, as depicted here:
We acknowledge that people work in Teams and consider it their main collaboration hub. So, instead of trying to replicate the Teams functionality in a DMS, we integrate the DMS functionality into Teams. Therefore, Teams users do not have to leave their communication and collaboration environment, and still profit from a DMS. How is this done?
The figure above shows how to insert a document from enaio® into a Teams conversation. It can be any Teams conversation: a chat, a video call, a recurring meeting. Simply put, a document is added to the context of a conversation, pretty much like any other document is added to the Files tab. Actually, it is quite similar: there is even an enaio® tab in Teams, where you can find all enaio® documents that have been shared in the current context. But there is more: in this tab, you have full access to the Office Online integration! You can start editing an enaio® document, directly in Teams, and the same rules as with the “normal” Office integration apply. Furthermore, you can jump to enaio® from Teams, view the document’s metadata, inspect the document history, or download the document locally (if you need this for whatever reason).
You can continue to use Teams, share documents from a DMS as you wish, while keeping them in a DMS and enjoying all the benefits of this.
There is also another direction: it will happen that users will want to add external documents to Teams. You can of course store those documents in a DMS directly from Teams. In enaio®, they will be stored in a general filing location, after which you can comfortably access them in enaio® client and continue working on them as if you just dragged and dropped them.
The collaboration puzzle is almost complete. We can store documents, control access to them, work on them alone or in collaboration, track changes and versions, even share them transparently via MS Teams—and still enjoy all advantages of one central storage location in a DMS. One piece however remains: how to share a document with people outside of your organization? For example, you want a lawyer to perform a check of a contract before you send it to a partner. Or an architect should check your new room concept?
Surely, you will export such documents from a DMS and share them via e-mail. This is one option, yes. However, you lose almost all benefits of a DMS that way. The document just left your “single-point-of-truth” storage, all changes which happen in between will not be known to the 3rd party (unless you resend the document each time), you have no idea what is going to happen to the document on the other side. So, there has to be a better way, right? There are two.
The first solution is to simply use a Teams integration, as already described. You generate a meeting, share a document, invite external collaborators and work on a document together. The downside is that, after the meeting is closed, external users cannot access the meeting and thus the documents anymore. So, for one-time presentations, a Teams integration may be enough. For a long-term collaboration, a different kind of solution is required. It is based on granting temporary token-based access to a DMS to external users. For enaio®, this solution is called enaio® coLab.
Using enaio® coLab, you as a DMS user, can select a subset of documents and expose them to external users in a controlled manner. This means, you can control which documents are exposed, to whom, for how long and under which access rights. This makes a fine-grained control possible: documents never leave your DMS, and external users are still able to access and modify them. In enaio® coLab, even an Office 365 integration is available, so the circle neatly closes. External users receive one-time tokens and are authenticated either using some known trusted OIDC provider (Google, Microsoft, LinkedIn), or creating an account in enaio® coLab and have it for future use. enaio® coLab also provides the concept of a project room, in which you can collaborate with multiple internal and external users, define rudimentary project milestones and exchange messages.
Share enaio® documents more efficiently and securely: via one platform
But the main purpose remains sharing enaio® documents with external users without those documents ever leaving enaio®. If granted enough rights, external users can even add new documents to the project room, thus effectively adding external documents to your DMS. This can pose certain challenges, such as security risks. Therefore, enaio® coLab also offers a possibility to integrate antivirus solutions for this use case.
To sum it up: a DMS likes to be “in charge”, to be a “single point of truth”, to have the sovereignty over all documents and data. And this is good, as it brings enormous benefits. However, this does not mean that a flexible and dynamic collaboration through smart integration with modern, cloud-based platforms such as Microsoft 365 or Google Workspace is not possible. If anything, integrations such as the one that OPTIMAL SYSTEMS offers between enaio® and Microsoft 365, prove that the sum of one and one sometimes truly equals more than two.
Learn more about DMS and Collaboration?