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]

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.

[Jana Volencova]

Hi Kristian, 

many thanks for this detailed answer! It is helpful to see that these plugins can be combined together to produce a viable solution. It prompts me to go back in my research and test some of the plugins again - and this time perhaps also reach out to the companies that develop the plugins. Maybe I didn't set everything up properly. 

However, I remain curious if I could build the publishing solution using just Confluence out-of-the-box capabilities. I have been working with Confluence for so long that maybe I might have developed a few blind spots. 

Thank you,

Jana

[Kristian Klima]

Hello Jana,

There are status labels that don't do anything, as far as I know, but you can deploy them as indicators to your workflow which would have to rely on a military levels of discipline ... and I'm still not sure it would by satisfactory.

Update the page, insert the status label and CLOSE rather than update.

So if you change a page that's a part of your public space, the changes will not be visible to end users while the label indicate 'work in progress' = open the page in the edit mode and you'll see the latest edits (which is about as useful as wiper blades on a submarine).

Your current solution (copy pages manually) essentially recreates (to an extent) what the apps are doing and you see that it's far from ideal.

[Jana Volencova]

Hi Kristian, 

ah, page status, I have not thought of this. And I will probably not go this way, as you said "military levels of discipline" and that is hard to achieve. 

Also, I dislike not updating pages once they were modified - people then get confused why they see some content in read mode and different content in edit mode. (We have quite a few contributors, not just dedicated Doc team members.)

[Kristian Klima]

Hello Jana,

My wish list includes:

• ability to see the page's draft content without going into the Edit mode
• functional status labels - if labels is not AS DEFINED, the page, will always displayed the previously AS DEFINED content. In other words, those labels would be usable in APIs so that other apps could use them to trigger/not trigger an action.

Now, that would obviously result in some apps being 'sherlocked' ...

[Linh Pham_Ricksoft_Inc]

Hi @Jana Volencova ,

Since you mentioned that you've tried Space Sync for Confluence, please could you share with me the limitations you're facing?

I'm part of the team developing this add-on. We recently released the auto-sync feature (based on approved content) to accommodate the same workflow as you described. So I'd love to hear your feedback! 

Regards,

Linh

[Jana Volencova]

Hi Linh, 

thank you for reaching out! I tested the add-on last year, so maybe there were some improvements in the meantime. But my notes say: 

1. Seems it cannot publish the whole space. 

2. Labels and comments are not synced.

3. Page order is not maintained.

4. Seems that the destination space has to be populated page by page by this plugin, otherwise the syncing with fails due to duplicate page names.

Best regards, 

Jana

[Linh Pham_Ricksoft_Inc]

Thank you for the detailed feedback @Jana Volencova ! 

We've indeed rolled out lots of improvements that address some of those limitations:

1. Seems it cannot publish the whole space.

- It's possible to copy space with bulk operation, you can also set conditions (by label) to exclude certain pages if needed

2. Labels and comments are not synced.

- Both labels and comments are now supported :D (for more details: What content is synced)  

3. Page order is not maintained.

- Unfortunately, page order is not supported yet

4. Seems that the destination space has to be populated page by page by this plugin, otherwise the syncing with fails due to duplicate page names.

- This is actually a limitation of Confluence, we can't have two pages with the same name in the same space.

Regarding support for publishing workflow, you can achieve it using our new auto-sync feature. I've shared more detailed use case in this blog: Automate content publishing workflow in Confluence 

I hope it's helpful! Please feel free to contact our support portal if you prefer a personal app demo / walkthrough, I'll be more than happy to answer your questions and requests! 

Cheers,

Linh

[Jana Volencova]

Hi Linh, 

thank you for the feedback, there really are improvements! Still the page order seems like a serious drawback to me. But as I wrote above, it is time I revisited all these plugins and ran another series of testing. Space Sync included :-)