How do you apply baseline in confluence/jira?

Hopefully I am not the only one struggling with this issue regarding baselines. What I'm trying to achieve is just a versioned document that links to a set of versioned JIRA issues. Doesn't sound to hard to achieve but how do you lock those issues from being edited so that a certain baseline always reflect a certain version of the issues it holds links to?

Detailed description of the problem.

On day one I create this Confluence page that contains requirement specifications using the "Product Requirements Blueprint"-approach described in the Atlassian documentation. This page holds a table pointing out several product requirement documents which in turn contains several links to JIRA issues where the requirements are described in detail.

Obviously on day one they are all in synch with what we want since this version of the document, version 1, contains the specified requirements as of right now. Then at some later point in time someone discover that one or more of the requirements need to be updated, which is rather common, and they would have to update the requirements issues in JIRA. This is where the problem is. If we change those requirements issues then they are not the same as the ones we added at day one which makes the baseline useless.

As far as I know Confluence has only got individual versioning of pages. Unfortunately that doesn't solve this problem since it points to other documents (through the "Page Properties Report-macro") which in turn contains links to the requirements in JIRA.

The real question is:

How can you achieve a proper baseline handling in JIRA/Confluence whereby the top page, containing the Page Properties Report macro, points at a specific version of the requirements documents which in turn hold specific versions of the requirements issues in JIRA?

Hope this problem description makes sense.

10 answers

Hi Kent Granström , @Alexey Rjeutski [Polontech]

As OBSS we developed a solution for " Baseline ". You can create baselines of your documents based on a date and time. The created baseline set allows you to easily access document versions of that time.

Here is the link to download Baseline for Confluence . You can also read the documentation of the product.

Thank you for your interest!

@Tom Gelhausen, nope, not really. We have come up with a slightly modified approach whereby we export  issues on a certain date into a "baseline-PDF" so we know exactly what a certain set of reqs looked like at a certain point in time. That PDF is then attached to the Confluence page shown as a list of baselines.Baselines.png


There is no common solution for such kind of use case. As a workaround I would advice you to use only links to proper version in confluence, and use versioned link when you connect it to jira ticket. That will give you possibility to see baseline, but will require a set of accuracy from you.

First of all, thanks for your reply.

Unfortunately it doesn't solve my problem. I was hoping that someone would have struggled with this and found a genuine solution to the problem.

Please think about plugin development / ordering. We had the similar request, but client cancelled as there are a lot of hours of development to implement such kind of use case.

First of all, thanks for your reply.

Unfortunately it doesn't solve my problem. I was hoping that someone would have struggled with this and found a genuine solution to the problem

we had the experience with similar (but not exactly your) problem and prepared the technical task according to request of one of our customer - for plugin creation. But we've not implemented it due to cancelation as there is too much hours of development

Perhaps a business case then... Can't be that hard to implement this if no other solution is around.

It's just a case of picking the right versions of some issue specified in a certain baseline but I guess the main problem is that JIRA issues aren't versioned(?) and therefore we can not differenciate between what ever an issue looked like at a certain point in time compared to some other point in time...

Hi @Ege Su İnan

Thanks for the suggested plugin. It is definatelly a step in the direction I want but it doesn't solve the problem with non-versioned JIRA issue. It will work for Confluence documents but if these documents have links to JIRA issues, in our case an issuetype "Requirement", then that requirement can change without the document being changed...

Hi Kent Granström,

Yes this plug-in works only Confluence, but its a step to start, thank you for your interest.

Kind Regards,

Kent Granström, have you found a solution to your problem after all? Could you solve it within JIRA or did you switch to a different tool? I need to do the same thing.


Nope. No solution

I am trying to maintain Baselines for JIRA Issues (a Traceability Matrix), Code Base, and Knowledge Base (many spaces in Confluence), for each Product Release...

Bitbucket/GIT is used for the Code base, so no issues there, beyond the normal configuration management trials of combining components from multiple repository(s) into a single Product Release and Branch Model ...

R4J, Portfolio, and Structure each seem to have varying degrees of Baselines covered but no branching?

The Plug-in mentioned above for Confluence may be a start, but branching and then merging becomes an issue, as well as the links and attachments.

I had hoped someone had an add-on for Confluence that could trigger make use of GIT for page store,... or there might be some way to apply containers for Confluence Instance and to be able to use a separate container version as the "Branch" ...

I currently use a backup and restore model with pgbarman (postgress db) and file system backup that could be used to freeze the Instance in time similar to the Container method but it would require separate licenses to then restart the "Branch" ,...

eh, just thinking out loud ,...

Good thinking man. I thought this would be a piece-of-cake to sort out. Just adding a version to each issue making it possible to point out a certain version of an issue. It would probably be part of a primary key in the database where it would be TEST-1, VER--XYZ. Then in the external macro, just specify what ever issuekey and version of that issue you want and the problem would be solved making it possible to accuratelly setup a proper baseline.


The version number would of course change every time you edit an issue but since the filtering in the macro points to a certain version of an issue, it would not change the result.


Yes, I think, just like Confluence, we can identify the issues with Versions, but those nasty branches for sustaining are the problem ... and possible merges to current development...

Issues and Documents, along with their links and attachments ...

Far more complex than Source Code Baselines and Branch Models,...

Perhaps a Container approach, but the licensing, and the merges are the bear, ...

I did a model similar to this using ClearCase and a Web Interface back in the 90's ...

It allowed "Management" to work on word documents that were maintained in ClearCase but were presented on Web Pages based on a ClearCase Configuration file.

I was able to pull a different version by simply associating the ClearCase Configuration into the Web Page Properties ... and I was able to read the Word docs for presentation, similar to the Confluence Pages. Triggers on save allowed for auto updating the sources in ClearCase ... perhaps it's possible a trigger in Confluence and a few web hooks might provide the means to auto read/save xml pages/attachments from/to GIT ... same could probably be done in JIRA for Issues ... spaces would need to be restorable with NEW unique ids ... dynamic ...

another day ...

I think you're taking on a far more complex issue than what I want to achieve. Perhaps my issue is just one of the steps in yours whereby JIRA issues can be uniquely identified  by issuekey, and a new field, issueversion. 

Agreed, being a developer (and a QA Engineer) I tend to wanting to assure sustainable processes and products ... hence the ability to branch and merge ...

And, most definitely, what you are looking for is an important stage in getting the full process in place ...

I just see that a lot of work goes into manually trying to manage the sustaining end ... and it usually is the point that you want to be most automated to allow quick fixes to happen on legacy releases and not be lost on current processes ... so I try to be sure it is not forgotten in discussions like this, ...

Hi guys,

I have the same problem as Kent written in 2014, four!!! years ago. I also have to baseline JIRA but current I didn't find a possibility. For Confluence current there exists the baseline plug-in, what we are still using.

Best regards


Suggest an answer

Log in or Sign up to answer
Community showcase
Posted Feb 06, 2019 in Confluence

Try out the new editing experience

Hi team, I’m Avinoam, a product manager on Confluence Cloud, and today I’m really excited to let the Community know that all customers can now try out the new editing experience and see some of the ...

782 views 33 5
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you