How to set up publishing workflow in Confluence

Jana Volencova

Hello,

I am curious how you use Confluence to publish end user documentation.

The scenario is that we need to have a working version (restricted to internal staff where we prepare updates and run reviews for several months) and then we need to publish all of the contents (= typically the whole space) on a given date. When I say "publish" I mean putting this content into a space which is available to anonymous users.

We have used the system of two spaces: we work in an "internal" space and then copy it to the "public" space (which was previously completely emptied). This has a a serious drawback that with each publishing we get new page IDs in the public space and so links and bookmarks keep getting broken.

I tested several plugins, including Scroll Documents, Comala Publishing and Space Sync and each had some limitations.

So I'd be grateful for any tips how to run the publishing procedure. Thank you.

Kristian Klima_gtcuat

Hello @Jana Volencova (Ahoj, Jano )

At Emplifi, we're using several apps together

• Comala Document Approval
• Comala Publishing
• Scroll Documents + Scroll Variants
• Scroll Viewport

In a nutshell.

• two spaces are set up for Comala Publishing. Source and Target
• Comala Publishing is set up to sync ALL page's metadata
• In Source, we have Document Approval set up to have 2 steps. Review and Approved.
• Both spaces have the exact same Scroll Document setup with Two variants. Public and Private - we're doing 'conditional content'

All work takes place in the Source space. Once the page is ready, we move it to Approved, this triggers Comala Publishing and the page is synced to the Target space.

Target space is used as a source for Scroll Viewport to build two documentation sites. Public and Internal (Internal site is behind SSO which allows all Emplifiers to access the content even without a Confluence seat).

Why two sites? Well, our Source space also features stuff we don't wanna share publicly. So we label it for Scroll Variants and Scroll Viewport takes the cue and only uses the properly labelled content for each of the two sites.

Benefits of the setup.

• we can work on any number of pages at any moment (keeping them in 'Review') without ANY impact on the Target doc (and by extension on our two sites)
• there are minimal dependencies across pages - we can literally make changes to the Target (the sites) 50 times a day if needed so we're not tied to release cycles, sprints or anything
• both Source and Target space remained hidden from the public
• we always have a backup space
• we can always deliver the right content to the respective audience while only working in a single Confluence space
• Viewport's links can be made permanent - so they always work and you can set up redirects

(There's more here)

I guess you could do with a redux version of the setup (no Variants or no Viewport) as you can switch variants in Scroll Documents but it's not as elegant.

Let me know if you need more details.