Do you need help mastering the editing process for articles bound for publication in your Confluence? The apps Comala Workflow and Comala Publishing might be the tools you are looking for. This article walks you through how to put in place an approval workflow in Confluence for posts such as blog articles, newsletters, etc.
To use the tools and the workflow properly, you’ll need two spaces: one will serve as the draft during the editing process and can only be accessed by the relevant people until its final approval, while the second page will host the article in its validated format in a public space.
Installing and configuring Comala Workflow
Once the app is installed via the Atlassian Marketplace, you need to set up an instance for the workflow. This can be shared over the entire instance or just a specific space. A new menu Workflows will appear in the Space tools button:
Several different Workflow types are available to use when you install the app. For this blog post, I’ll add an article validation workflow. This can be added through the app’s administration. To define the workflow, use the syntax wiki-markup; while the language is a bit old, the advantage is that it remains easy to use. For more details, please refer to the complete documentation on Comala.
We’ll now define the parameters for the workflow. These parameters should be set up in the instance when using the workflow in a space. This example uses two parameters:
- The first group will define all the Confluence users who will be part of the “editing group.” This parameter will be used in the workflow configuration.
- The second group will define who is the main “editor in chief” of the space and have the additional rights needed for content approval.
As part of our workflow we need to define the different steps. Here we determine the steps for validation from the beginning to the end of the project, and you’ll use the parameters that were previously defined above. You can find more details on the different possibilities offered by the app at this link.
The last aspect that needs to be defined in our workflow are the triggers. These triggers can be used to prompt an action in function to a specific change: assign the page to a user, insert Confluence meta-data, publish the page in a public space, etc.
We will see this part in more detail in the description of the Comala Publishing app.
Once the configuration is completed, Comala Workflow offers the possibility to visualize this configuration in a graph, which can serve as documentation for the workflow.
Setting up the workflow’s instance in the Confluence space
The defined workflow is now available in the space’s administration. Once the workflow has been selected, it will be necessary to set up the instance’s parameters in the specific space:
Here the user pwhite had the role of “editor in chief” for the space and the members of the group “editing group” all have the same name for their role. Thus, each step of the workflow using these parameters will benefit from this initialization.
Using the workflow
Once the workflow has been set up in the instance for the space, users can directly see the status of the page in Confluence. In our example, after editing a proposed article, the first step in our workflow “proposal” is automatically selected for this article.
In the same view, the article can be passed from one status to another until the last validation before publication. This action is visible only to users who have the rights to move the article from one status to another in the workflow (see above in the parameter configuration).
Configure spaces with Comala Publishing
Again, you’ll need to set up two spaces: one that gathers proposals and edits. The second space is open to the public and will bring together all the validated articles. Just like Comala Workflow, a new administration menu is available for this space. Here we have the ‘International’ space as a workspace, while the International Official space, below, contains the validated articles.
When configuring the workflow in Comala Workflow, instruction is made available in the “triggers” part. By simply using the publish-page tag, it will use the previously defined configuration of the target publishing space and will automatically trigger its publication as soon as our page arrives in the ‘Published’ state. Concretely, the page and the set of its child pages will be copied into the space called “Official” which will then be automatically published.
Need more help?
Get in touch with one of our Atlassian certified consultants below!