Document versions VS Smartlink

Hi, I just wanted to ask for your opinions and best practices on how you handle document versions. This is not a specific question about a feature or a problem, more about your experiences and solutions.

On the one hand we have the built in document versions. These are useful if one document version gets replaced by another and can switch its active version at some point. In many cases we have approval workflows which can then be restarted on document level for the new version. We can keep the version history and also the old files that belong to each version - simple and straigt forward.

On the other hand we sometimes need some “extended” logic which cannot be handled by document versions alone. Consider the case if we have a document version which is approved on document level and has to stay approved while another version is prepared and running through a (long term) workflow on its own. For example a product manual which is valid for a product. While using this version we are working on a new one which includes some new product stuff. When beeing approved the old one could be archived or sometimes can be kept for further use.

For this case we would need more functionality on document version level - since this is not possible in this way we can use a multi document approach:

For this case the idea was to create two metadata fields: rev-group and rev-number. The rev-group gets a unique document group number which holds together documents belonging to each other. The rev-number gets increased by any new version. So we can use smart links to find all other versions of the same group.

This was a lot of text, please see the figure below better understand the two approaches:

I’m curious to see how you solve such cases.

Torsten

That is an interesting use case.

Even if workflows were made to operate at the version level I don’t think they would help much in your scenario. Best to group the different documents as a unit as you proposed with a smart link or with an index and then track the changes both independently and as a group.

The reason for this:

The logic for the workflow implementation was to make it usable for the most amount of cases. To do this, we simplified as many situations as possible to the most common denominators:

  • The document is the business unit
  • The document file is the content
  • The document version is the way the content is exposed

If we update the workflow to operate on the version, then the version becomes a business object, and all other features must also be updated to operate on it: tags, metadata, smart links, etc.

From the technical point of view is possible, Mayan itself is a development platform (and we have built a contract manager, an inventory system, and others on top of it) but it will change the identity of the project and the indented purpose of tool.

3 Likes

Thanks for this explaination Roberto, I totally agree and I’m absolutely convinced with the model structure, which is very well designed and efficient. I know that most of the cases can be handled with it.

I’m just interested in best practices, real-life showcases and alternative points of view (than mine) how other users have implemented such cases. I am sure that there are already well-working approaches.

You mentioned the contract manager as an example. How do you deal with contract revisions there, how/when are they added as a version? Are they revised outside Mayan and added as a completed/finished document? Are they updated inside while having an older version active?

Maybe there are some well-working implementations of advanced revisioning getting by with a single document as business object and maybe using some intelligent tagging to show that the document is approved - but also a new one progressing but not yet approved.

1 Like

I’m just interested in best practices, real-life showcases and alternative points of view (than mine) how other users have implemented such cases. I am sure that there are already well-working approaches.

This is a good topic to an in-depth article. Will try to replicate a scenario based on some of our support experiences.

You mentioned the contract manager as an example. How do you deal with contract revisions there, how/when are they added as a version? Are they revised outside Mayan and added as a completed/finished document? Are they updated inside while having an older version active?

This is an entire custom solution built using Mayan as a platform that creates the Contract object and allows running workflows against contracts. This cannot be done with Mayan as it ships. Eventually the hope is to merge this project into Mayan as a single codebase. We have some experimental code that allows switching Mayan into different modes and this is sponsored work, but it is still in the early development stages.

Can’t show much, but here is the gist of what can is possible using Mayan as a development platform.

The project is the main object and it contains contracts which are normal Mayan documents. This leverages document versions as contract versions (for revisions and change orders). Which I think is close to what you want to accomplish.

This is all done with a single custom app.