Transitioning to Built-In Revision History

The revision history currently stored within documents can be easily transitioned to be managed via the metadata card.

To start using this feature, the Metadata Administrator must decide which Document Types should require Revision History and then enable the corresponding setting. To allow a gradual rollout and control over when this feature is activated, all existing Document Types are set to “No” by default. This gives you the flexibility to choose when and how to integrate Revision History into your workflows.

To do this:

1. Navigate to Masterdata views > Document Types
2. Select the document type you wish to change
3. Under State Transition, click on Update Document Type
4. Set the Requires Revision History field to “Yes”

When you enable this feature, users must complete the “Changes in This Version” field before submitting documents of the selected types for approval. This requirement ensures that any recent changes are documented.

1. For Draft Documents: The new requirement takes effect immediately, but refreshing the metadata card will require a state change. This can be easily achieved by clicking the “Reassign to New Author(s) State Transition by the Process Manager or Responsible Person of affected documents. Then, users must fill in the “Changes in This Version” field to proceed with the approval process.
2. For Released Documents: The requirement applies when the document is next updated. At that point, users must complete the “Changes in This Version” field to document the latest changes.

If a document has existing revision history, here’s what you need to do the first time it is submitted for approval under this new requirement:

1. Locate the revision history table in the document. Copy its content.
2. The template below can be used to capture previously tracked changes. When copying the original revision table, start from the bottom of the template (in XYZ order) as the latest version history will always be added at the top.
3. Once reformatted, insert the copied revision history into the “Changes in This Version” field in the document’s metadata. This ensures all previous revisions are preserved in the new system.

Once the revision history has been copied to the metadata, you can remove the old table from the document. This step helps keep the document clean and prevents redundancy.

When the new document version is released, all prior changes will be captured in the latest approved revision, both as a metadata field and as an additional page within the released version of the document.

Any templates in your SimplerQMS vault that contain document-based revision history should be evaluated when the setting is enabled and the tables should be removed. This will prevent any future documents to require the document embedded table to be filled in, and promotes the use of the metadata based revision history.

Procedures where the revision history process is described should also undergo updates one the feature is turned on on relevant document types.

By following these steps, you ensure a seamless transition to the updated process while preserving the complete history of document changes from previous versions.