5 examples of document versioning
Many modern organizations pay less attention to document version control than companies did when they first deployed enterprise content management systems two decades ago.
As most new ECM deployments have migrated to cloud environments, version control for document storage has become less of an IT priority. Therefore, business priorities drive version control requirements rather than IT teams, although they are directly involved in ECM acquisitions and deployments.
For simple collaborative documents, keeping the last 50 or 500 copies is viable. Yet organizations often forget how long they need to keep each release, and that some iterations are more important than others. Organizations should view version control as a tool, not just a feature to be enabled.
Document versioning examples
Content teams can take several approaches to versioning documents. Each approach corresponds to specific business needs, and organizations often use multiple approaches based on different business requirements.
The following five high-level strategies are suitable for most business cases.
Auto-save balance. A basic, incremental versioning scheme makes sense for content that someone has yet to finalize, especially content with multiple editors.
Most cloud-based systems allow 50 or more versions. That amount may seem like a lot, but when autosave keeps creating new drafts and collaborators are editing the document simultaneously, even 500 copies can happen quickly. Organizations must balance auto-saving and versioning to ensure users can retrieve past work.
Iterative documentation. The documentation often has its own versioning scheme or a link to an external numbering system. Employees can use both major versions — 1.0, 2.0, etc. — and minor ones — 2.0, 2.1, etc. — to see which iteration correlates to which state of the editing process.
Organizations often use minor releases for iterative drafts, while major releases represent final, approved documents. Then content teams can purge minor copies, which become useless when the major version is released.
Documents checked. For controlled documents, the organization has an official version of a document. Even if one is more recent, all the other copies are either a draft or a historical document. When an approved version becomes the current version, content teams can place it in a central location and it becomes the source of truth going forward. Content teams should keep a history of these copies to show when each release was effective if questions about past states arise.
While this approach is akin to iterative documentation, controlled documentation has a single location for the official release and archives previous official releases. These approaches also differ in the effective date, as the published versions remain valid for a certain period of time. If content teams know which was official at any given time, this release can help with audit trails.
Labeling. In this scenario, content teams can tag specific versions to represent status and relevance. This approach allows users to find a specific version for a particular state in the editing process.
Although “approved”, “original”, and “current” are obvious labels, other naming conventions may be useful. For example, a team can use “CEO comments” to follow up on a document where the CEO gave specific advice. Labels can also mark major variations of a document. If an HR policy applies to employees in a specific country, the HR department can tag the document to specify that location. Specific tags can ensure that content teams don’t mistakenly purge older, useful documents.
Purge old versions. This example is part of most version control approaches. Old drafts lack value to organizations, and unsanctioned or unofficial statements risk losing context and causing confusion.
Even for collaborative content, content teams should consider whether to keep all drafts at all times. Organizations can benefit from a strategy to eliminate obsolete and unnecessary documents and know which older versions to keep. Labeling and major releases also come into play here. If the ECM system does not support these features, content teams can move key versions from working directories to a publishing or archive location.
Not all document types can fit in a specific compartment. Sometimes content teams need a hybrid approach. Yet, when these teams understand the purposes of different types of documents, they can identify the right release management approach.
Questions to ask before deployment
When choosing the appropriate document versioning strategy, content teams should ask several questions up front. These questions are:
- What objective does the organization want to achieve? Knowing the goal is the most critical step. Sometimes the goal is to revise older versions as documents evolve. Other times, organizations want to keep specific versions.
- What does the organization’s ECM software do by default? The default behavior shows a vendor’s plan when they implemented versioning. If the software allows 50 or more versions, the vendor is likely planning for collaborative content. Additionally, versioning of formal processes may require additional effort. Adopting a new ECM service to improve release management rarely pays off. Content teams therefore need to understand the functionality of their software to build a strategy.
- Where should people look for documents? Content teams need to determine where employees should look for official releases and whether everyone should have access to drafts. For authorized employees, content teams should keep search simple.
- How important are old versions? If older versions are of little value after a week or month, organizations can benefit from a strategy to remove or hide these documents.
- Can content teams automate the release management strategy? Content teams can succeed with automation. Requiring multiple people to take extra steps and follow specific version controls is risky. People forget, rush, and maybe don’t see the point of taking the extra step. An unfollowing versioning strategy is worse than not having one.
Content teams need to fully understand the needs of their organization and the resources they already have. If an organization’s current ECM tool cannot meet its needs without significant effort, that tool may not be up to snuff in other ways, such as version control.
Teams also need to consider the business requirements of different departments to ensure that versioning meets everyone’s needs and doesn’t just create multiple copies of the same document.