Documentation workflow in Confluence with drafts, publishing, and history

[Lene Riis Jeppesen]

I need your help and hope you have a moment to read through this.

We’re facing a versioning and documentation history challenge in Confluence and are hoping for an elegant solution. Here's the workflow we aim to support:

We have released a product with corresponding Confluence documentation, which is officially published (no longer in draft).

We’re now developing a new version of the product. The end result will be similar, but the technical structure is different.

In this process, we want to create a new draft of the existing documentation, which we’ll work on during the development phase.

Once the new version is ready, this draft should be published and replace the old documentation, so the latest version becomes the official one. The history of the previous version must be preserved.

We want the ability to revert the new documentation back to draft and restore the previous version to published status, in case the draft is published by mistake.

We’d also like to be able to start a separate draft based on the current published documentation, in case we need to update it independently of the version currently in development (like a “branch”).

Most importantly, we want to maintain documentation history within a single document flow and avoid creating separate documents per version, as that fragments the history and makes it harder to follow.

Questions:
A) Is this kind of workflow possible with Confluence Cloud?
B) How can we best manage rollback and parallel drafts?
C) Does anyone have experience with plugins that support this kind of setup?
D) Are there best practices for versioning and publishing that help preserve document history and make it easy to switch between versions?

Any input is welcome – solutions, workarounds, or personal experience 🙏
Thanks so much for reading this far!

[Kristian Klima]

Hi @Lene Riis Jeppesen 

This is my favorite topic :) 

I've just published "Product docs reloaded - semantic versioning meets continuous delivery" today which does address your goal.

Scroll Versions is not available for Cloud but there is Scroll Documents (same company, K15t). Long story short, does pretty much the same thing just differently.

Basically, you have one 'permanent' working version of you space (a scroll document). Once it's in the final state, you create a 'snapshot' of that document = a new version, say 2.0.

Then you continue working in 'working version' on 2.1. Once you're happy, you create a another snapshot = new version.

Important - snapshots are editable page by page.

Whether you make your documentation available via Scroll Viewport (examples of our Viewport sites are in that linked article) or in Confluence, you are in charge of which version remains the last one and/or visible.

In my linked article, I can revert to any previous version of my documentation at any point. If you want to learn more about that particular setup, feel free to ping me on LinkedIn.

This is just an overview - the exact setup would depend on details of your requirements, and I don't want to copy Scroll Docs documentation here :) 

You can take it on another level mixing in other apps (for workflow, approval, space synchronization - more on that here) but based on your description, Scroll Documents will do exactly what you need. 

[Umer Sohail _K15t_]

Thanks @Lene Riis Jeppesen for the question and @Marc - Devoteam and @Kristian Klima for recommending our app.

This is Umer from K15t. I'm the Product Marketing Manager for Scroll Documents (the Cloud counterpart of Scroll Versions).

That's a common challenge you're facing when it comes to versioning product docs in Confluence and exactly where Scroll Documents for Confluence Cloud shines.

Scroll Documents streamlines your Confluence documentation lifecycle by helping you create and compare versions, track changes and version history, and even tailor content for specific audiences and languages.

I'll try to quickly address your questions:

How to manage parallel drafts

When you create a new Scroll document, the app creates a “working version” of your documentation. This would be a complete copy of your current published docs, allowing your team to work on it in draft mode, isolated from the live content.

Once your new version is ready, you can publish the working version directly over the old one. Scroll Documents handles this seamlessly, making the new version the official published one while preserving past versions of your content.


How to centrally maintain documentation history

Instead of creating separate spaces or duplicating pages manually, you can access and manage all versions centrally using the Document Manager and customize their order and location.

How to manage version rollbacks

You can delete a specific version or the entire document. You can also save and publish a new version based on an already existing version and overwrite individual pages between versions. 


If this sounds that's something you're looking for, I would recommend scheduling a demo with one of our experts to discuss your needs in detail.  Or you can try the app for free for 30 days.


Other recommended resources:

- Intro documentation on how to get started.
- Guide on creating product documentation.
- Guide on creating modular product manuals in Confluence.


Of course, feel free to reply here in case you have more questions. 

P.S. Since you also requested for best practices on maintaining product documentation in Confluence, here's a link to our free documentation guide and our YouTube channel with hours of free content.

Cheers!

[Marc - Devoteam]

HI @Lene Riis Jeppesen 

This will require a 3rd part app from the marketplace, like scroll versions.

Ootb this is not an option.

[Lene Riis Jeppesen]

Can I use scroll version for Cloud?

[Yulia Lenina (AppFox)]

Hi @Lene Riis Jeppesen

welcome to the Community and thank you for your question.

First off, you'll not be able to do this with the native Confluence feature set, unfortunately - it will require an additional app with support of cross-space publishing, version history and multi-stage workflows.

General best practice is to separate drafts from ready documents, putting them in dedicated spaces. Then, after the document is approved, it automatically publishes to a Master Space where it's visible for the wider audience. Meanwhile, in the Source Space, you can work on this document to make changes, which go live only after the approval process. At the same time you can incorporate a minor/major versioning separate from versions in Confluence, and it will be visible when, who, and what changes were done, with version numbers.

You can do all of this with our app, Workflows for Confluence. If you're interested to learn more, please feel free to book a demo here and our team will happily to show you how it works and how you can apply it to your processes!