Apply new workflow without affecting other JIRA boards

So there's an existing project that associated with a JIRA Board (Board 1). What I want to do is to mirror the issues from the "Accepted/Done" column of Board 1 onto the "To do" column of Board 2. 


I've managed to replicate the issues onto Board 2 by creating a filter. What I want now is to apply a workflow on Board 2 without affecting the status of issues in Board 1. Is is possible for 2 JIRA Boards to have different workflows without affecting each other?


Take note that both Board 1 and 2 are pointing to the same project. And I'm using Kanban for Board 2. 


Thank you!!

1 answer

1 accepted

0 votes
Answer accepted
Jack Brickey Community Champion Jul 17, 2017


Just to be technically clear, boards don't have workflows. Rather issue types have workflows. I'm going to provide some input here but to provide the best answer I would need more info on your use case.

Method 1: Split a single workflow across two boards.

In the past I had a '2-board' system where board 1 belonged to PLM and board 2 to DEV. PLM would move requests from idea (far left column) thru requirements and then to a ready for development status (just left of far right column) of their PLM Kanban board. PLM and DEV would meet weekly to review the issues that were ready for development and if agreed move them to a DEV Backlog status (far right column) As you can probably guess we had one large workflow where the front half had statuses for PLM and the back half had statuses for DEV with one overlapping status/column. Something like this:

  • PLM: NEW --> In Progress --> Req Complete --> RDY4DEV --> DEV Backlog
  • DEV: DEV Backlog --> Under DEV --> Done

So PLM's board had DEV Backlog on far right (PLM's done) and DEV's board had DEV Backlog on far left (development's to do).

Method 2: Leverage two workflows

If you really want two workflows I would use two different issue types each having a different workflow then having the two boards report on the associated issue type. For example:

Issue Type = Feature Request allows PLM to make decisions, work requirements, and mark as ready for development (done).

Issue Type = Apprved Feature allows DEV to develop the feature and eventually move to Done/Closed

In this scenario you can change the issue type either manually or automatically. If you want to retain the issue in the right column then your filter needs to include the issue type for board 2 but only map the  Approved Feature status into the right column. Or you may want to have it disappear all together or you may want a column call Dev backlog on the PLM board. Lots of options here.


I hope this helps and all of the details did not simply confuse you. Let me know if I'm on target or I missed.



Thanks for your inputs, Jack! 

The reason for having 2 Boards is so I can track ticket movement during the development phase and production deployment.

Development would be for the Development Team and if the Product Owner's approval of the ticket. Business Review would be for the tickets (from Development) that need to be reviewed by customers and if accepted by, deploy them to Production.

Simply put, the Development Board would have this flow:
To Do --> In Progress --> In QA --> Accepted

Then for the Business Review Board:
Accepted (from Development) --> Under Review --> Waiting for Deployment to Production --> Deployed to Production

Based on your suggestion, looks like I can use Method 1.

Another question that pops up with Method 1 is -- will I still see the ticket under "Accepted" in the Development Board as I move it across the Business Review Board? I would think not because moving it means changing the ticket status (and ticket status is associated with a column). 

Jack Brickey Community Champion Jul 18, 2017

Yes method one is exactly what I did for your case and you will not see the issue under Accepted in the Dev board UNLESS you add all of the Production status into that column of the Dev board. In other words you control what shows on what board and in what column. If you want it shown map the status to the column. If you do not want a status shown on a board leave the status unmapped.

Please be sure to accept the answer here if it address your question as this helps future searchers.



Great! Thanks for answering all my questions Jack!

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

626 views 0 7
Read article

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