This documentation relates to the latest version of Confluence.
If you are using an earlier version, please go to the documentation home page and select the relevant version.

Approval Workflow

All Versions
Click for all versions
Confluence 2.9 Documentation

Index

This page describes the details of an approval workflow.

  • Users may be members of an 'author' group which is allowed to edit pages, an 'approver' group which is allowed to approve edited pages, or both groups (in which case they can't approve their own changes) or neither (in which case they are just consumers of the content).
  • When an 'author' edits a page, the page goes into a 'editing in progress' state.
  • When an author views an 'editing in progress' page, they are presented with an option to submit the page for review. This puts the page into the 'waiting for approval' state.
  • Members of the approver group have access to a page in confluence which automatically lists the pages waiting for approval.
  • When an 'approver' visits a 'waiting for approval' page, they are presented with options to accept or reject the changes. If they accept the changes, the page goes to the 'accepted' state, where pages spend most of their life, otherwise it goes to the 'rejected' state.
  • Members of the 'author' group have access to a page in Confluence where they can see all the pages which they edited which have been rejected, or are waiting for approval. They don't see pages other authors have edited.
  • When an author visits a page in the 'rejected' or 'waiting for approval' state, they have the option of withdrawing the change, which moves the page to the accepted state, and rolls back to the most recent approved version.
  • When an author edits a page in the rejected state, it moves to the 'editing in progress' state.

All of this can be done with the Workflow Plugin Prototype.

But we probably also want to show consumers the most recently approved version of a page, not the one currently under review. Without core Confluence changes, the best we can do is show users a banner which says "This content is being reviewed. The most recent approved content is here".

Labels:

Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.
  1. Sep 13, 2005

    Dan Hardiker says:

    Instead of displaying a message asking the user to redirect, why not output java...

    Instead of displaying a message asking the user to redirect, why not output javascript to change the document.location.href or (if you can) output a redirection header?

    Although the page itself isnt being rendered in the first load, its better than asking for user interaction to show the desired page.

    1. Sep 13, 2005

      Guy Fraser says:

      Why not just output the most recently approved version of a page should the logg...

      Why not just output the most recently approved version of a page should the logged in (or anonymous) user not be allowed to see an "under development" page? That would also be nicer when a search engine happens to pop by as the search engine would get meaningful results. I presume that if there are no approved vesions of a page then the page will not appear to people who can not see "under construction" pages, even in children lists, etc.

      1. Feb 10, 2006

        P. Payette says:

        This should be an option, not a default setting. The reason is that it may, in s...

        This should be an option, not a default setting. The reason is that it may, in some cases, be desirable to deliver work-in-progress information to anonymous users.

  2. Feb 12, 2006

    Jed Wesley-Smith says:

    I would presume that the whole Approval Workflow would be an optional setting, a...

    I would presume that the whole Approval Workflow would be an optional setting, as it goes against the general wiki philosophy of having free and open acces to modify information as much as possible. Once you have an Approval Workflow for a page you generally would presume that unauthorised users would only see the authorised version. If it is desirable in some cases then why do you need an Approval Workflow at all?

    1. Apr 09, 2007

      James Mortimer says:

      Well. for one use case, we'd like to have a built in 'draft' mode, where version...

      Well. for one use case, we'd like to have a built in 'draft' mode, where version A of a document is the community accepted version, for the 'data consumers', and yet everyone, including perhaps anonymous, could edit the 'draft' version (for the collaborators). Once enough changes have been made, the draft could be tagged/approved as the current accepted version. Any authorized user could, optionally, look at future 'beta' versions of the content. In this way, also, a number of pages that need to be synched because they reference each other could be updated individually but then 'released' in tandem. This could operate like 'tags' and 'releases' in a SVN or CVS environment. In fact, multi-threaded development of pages, with merging, would be helpful for larger, more complex content.

      1. Apr 09, 2007

        Charles Miller says:

        The versioning in Confluence is useful for tracking how a page has changed over ...

        The versioning in Confluence is useful for tracking how a page has changed over time, but is not sufficiently advanced enough to support things like tagging or versioning effectively. For example attachments are versioned separately to pages. So if you modify an image on a page, you're modifying it for all that page's history.

        My idea for tackling this process was a little different: Document Staging

        1. Apr 10, 2007

          James Mortimer says:

          Thanks Charles. The DEVNET:Document Staging looks very interesting, feasible in ...

          Thanks Charles. The Document Staging looks very interesting, feasible in the current framework with minimal changes, and addresses my immediate needs so I'd probably start using that right away if it were available. But more importantly, as per the 'approval workflows' discussion here, I'm concerned that the long term vision might not be broad enough and that it would be just a quick-fix for a few simple use cases. Especially since we have hundreds of spaces and many, if not most, of them would desire some sort of approval process, I fear the administrative burden of creating and configuring two spaces for each space might prove overwhelming.

          Thanks for linking these two discussions.

    2. Apr 10, 2007

      David Nessl says:

      An "approvals" workflow is sometimes necessary in a real business environment.&n...

      An "approvals" workflow is sometimes necessary in a real business environment.  For example, it's a requirement for ISO 9000 quality management repositories, thus such a capability would widen Confluence's audience significantly.  Although my company is not ISO 9000, we use Confluence but have to keep our attachments in a CVS repository where we use "commitinfo" exits to enforce an approvals workflow; if Confluence had approvals, we could move all our documents into Confluence. 

      If Atlassian really wanted to market Confluence for ISO 9000 and the like, we'd also need to start talking about templates for work records associated with each document, and how to manage filled-out instances of templates associated with each real work assignment.  (Could probably be done pretty easily in several ways.)

      1. Apr 12, 2007

        Nicholas Ilacqua says:

        Feature requests can be made at

        Feature requests can be made at http://jira.atlassian.com  Is this what you had in mind: http://jira.atlassian.com/browse/CONF-1916  If it is please vote for it, otherwise try searching yourself. You might need to create a login.

  3. Jul 17, 2007

    Roberto Dominguez says:

    Have a look at the Approvals Workflow Plugin CONFEXT:Approvals Workflow Plugin. ...

    Have a look at the Approvals Workflow Plugin. It's my take at the issue. It addresses most of the use case described above in a very simple way.

    Any feedback will be greatly appreciated.

Add Comment