How To Control Publishing of Changes
Not ready yet to bring all content changes to your live site? Learn how you can hold onto changes that are still in progress and publish those changes that are ready for your users to see.
Decide When Changes Should Get Published
Scroll Viewport doesn’t immediately pick up the updates you make on your Confluence pages. This mechanism gives you some leeway when it comes to controlling when changes are published to your live site.
Use the ‘update site’ action deliberately
When a page is updated in Confluence, the already published article in your Viewport help center remains unchanged until you click the 'update site' button. Only then will the changes show up in your live site.
We recommend to make deliberate use of this action. Whether it takes a few days or months, prepare content updates (e.g. for an upcoming product release) with your team privately in Confluence. When you are ready (e.g the product release is out), hit the ‘update’ button and make the changes available to your site visitors.
Decide What Changes Should Get Published
Sometimes editorial workflows can get more complicated. You might need to bring changes on some Confluence pages live (e.g. typos, correction of errors) while holding on to other changes that are still in progress (descriptions of features or improvements that haven’t been released to users yet).
You not only need control over when changes go live but also what exactly goes live.
Find out which of the below approaches suit you best to gain more control over your publishing workflow.
Use Confluence’s ‘draft’ options
When you create a new page or make edits to a page in Confluence and just leave the editor with the 'close' button instead of the 'publish button', you'll end up with page drafts.
Drafts of completely new pages can be retrieved and shared from the ‘drafts’ section in your Confluence homepage.
Drafts of already published pages can be found in their existing location in the page tree. You will see that they show a ‘unpublished changes' label on top. It means that the changes you made have not been published yet and can only be seen if you click into 'edit’ mode.
When you’re ready to go live, simply click ‘publish’ in the Confluence editor, then click ‘update site’ in Viewport.
Use Confluence restriction options
Scroll Viewport is only able to pick up and publish pages that aren’t view restricted for the app.
For newly created pages (pages that are not yet part of your help center), it can help to temporarily hide the page from the Viewport app user using Confluence page restrictions. That way the page (including all its children) is not picked up in your next site update, until you lift the view restrictions again.
We recommend you only use this approach if your page has never been published to your Viewport site before.
If you make changes to a Confluence page that is already part of your site and then apply view restrictions, in your next site update that page will get completely removed from your site.
Please also note that any child pages will inherit view restriction from their parent page.
About to make a beta release? Sometimes there are beta features that only selected users should see. In those case, you can also make use of the to Viewport’s page labels to Exclude Pages From Navigation and Search. That way you’ll still be able to share a direct link with anyone that should see the content.
Sync changes between a draft and published space
Some third-party Atlassian marketplace apps, like Comala Publishing, allow you to sync changes between two Confluence spaces.
This will allow you to create a setup with a differentiated draft and published space. You can use the draft space to draft and review your content. Once finalized or approved, the content can then be synced to the published space.
This published space is the one you can then add as a content source of your Viewport site. This ensures that only the finalized content, and not the content from the draft space, is picked up by Viewport.
Learn how to sync between spaces with Comala Publishing.
Use working copies
Some third-party Atlassian marketplace apps, like Breeze - Document Management, Review & Approval Workflows, allow you create working copies to prepare changes to content without affecting the currently published pages.
When using working copies your pages are cloned into a predefined working copy space. In this space, you can prepare content changes, request approval for these changes and have the changes published back to the original space only after the approval is granted.
Learn how to use approval workflows with Breeze.
Current Limitations
Some teams make use of third-party workflow apps in Confluence to define the status of a Confluence page (e.g ‘in review’, ‘approved’). These apps enhance Confluence’s built-in options and allow you to define how and when a page transitions between statuses.
While Scroll Viewport doesn’t currently integrate directly with any of these workflow statuses, in the long term, we are interested in equipping our current update and publishing process to fit more complex workflow requirements.
If your team is looking for better workflow support, we’re happy to hear more about your specific requirements. Feel free to reach out via our support portal.