You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I have been tasked to improve the flow of a current requests board that we have set up and part of doing this is having tickets be moved from one board to the other.
Ticket comes into board A, it gets to the Approved stage, at this point we have an Actions button as part of our work flow, depending on what is selected the ticket should in effect move across to another board.
What happens currently is using Deep Clone the ticket fields are cloned to the destination board. But what is required now is the ticket only sits in that destination board. Otherwise it gets quite messy dealing with 2 different tickets for the same thing.
Is it possible to do this? If not is there an alternative solution.
Any help would be great.
Hi @Mihir Ruparelia ,
This is definitely something that can be done. First, I just want to call attention to the difference between Jira Projects and Jira Boards.
Workspaces for one or more teams that contain related issues
The visual board + backlog which displays a set of issues from a JQL filter
Moving an issue from Project A into Project B can be done manually (through the Move operation) or automatically via Jira's native automation tool. Jira Boards on the other hand, can display issues belonging to multiple projects since they are powered by a JQL filter.
In your use case, TICKET-001 comes into Board A. A board from another project can still display this issue (while TICKET-001 continues to live in its original project) once a certain condition has been met. If the "action" is to change its status or a custom field value, Board B's JQL just needs to include this in its query. In addition, you can modify Board A's JQL so that this issue no longer displays on it (even though the issue still lives in this project)
Alternatively, you can use Jira's automation to specify that when X Action happens, Y Issue should move to Z Project. This will likely need to be configured by a Jira Administrator in the Global Automation menu since the scope affects more than a single Jira Project.
@Michael Andolfatto thank you for this, so I have been doing some digging on this and looking at the automation there is an option to clone the ticket.
As opposed to moving a ticket, is this correct?
The idea being once a ticket has transition to status X or status Y that ticket should "move" to the board.
I have attached what I came up with. Any thoughts or advise would be much appreciated.
Hi @Mihir Ruparelia ,
That should work, but I would recommend testing this with sample data first. It looks like the Move operation is not actually supported via Jira's automation, so the structure you have to resolve the original (or delete it) is what's recommended instead.
Hello @Mihir Ruparelia ,
On our JSM project we have several rules that transfer tickets from one team to the other (2 different boards).
Once the ticket is transferred, its ref number changes so we are wondering whether there is any way the new ref number can be be somehow grabbed and added to a comment in the automation rule for the reporter to see?
This is because reporters may chase their tickets with the 2nd team but only have the initial ref number, and the 2nd team doesn't have access to the 1st team's board.