How to keep new issue in the same board in multi-board project

[Jacob Issac]

I have multiple different boards: Ideation, Design, Content, Engineering, QA. And I want members of each board to have the ability to create their own issue. 

But when an issue is created, it goes back to the first board.

How do I allow users to create their own issues and make it stay on the board in which the issue was created?

[Walter Buggenhout · Accepted solution]

Hi @Jacob Issac,

Issues are being created in a project, not in a board. A board is a visualisation of issues in different columns that are linked to statuses.

Based on your description, it seems as if you have a project with an extensive workflow going through the different stages of  Ideation, Design, Content, Engineering and QA. Which makes perfect sense, by the way. Most likely, your boards map to just part of that workflow.

When an issue is created, it will always land in the first status of your workflow, which will always be in Ideation. And so, obviously, every created issue ends up in the ideation board.

If you want the different team members to create their own tickets for their team, you will need to split your process into smaller steps. Either by creating separate Jira projects for each team with dedicated boards. Or by using separate issue types for each type of work in the same project. That way, folks can create dedicated issues for their work.

Hope this helps!

[Jacob Issac]

Thank you @Walter Buggenhout ! We are using a very extensive workflow, and each board deals with issues that concern its team.

But which would you recommend, create separate Jira projects or use separate issue types in the same project?

Thank you!

[Walter Buggenhout]

Hi @Jacob Issac,

There is not something like a golden rule for that. But look at it from 2 angles: how your teams are organised and how the work between your teams is connected.

If your teams are pretty independent and they work on different types of work, it may be a good idea to set up a separate project for each team with even multiple issue types in it. Look at a software team that has Epics, Stories, Bugs and tasks to take care of. Each issue type can have its own specific workflows and screens, which allows you to build a tailored way of working in the tool for each type of work in the real world. But if that same software team is developing 3 different applications that are totally unrelated, it may be a much better idea to create 3 projects: 1 for each application and each having multiple issue types. I am aware that you didn't mention a software team in your specific case, but I am just using the analogy to help explain some things to consider when setting up projects for a certain team.

Finally, when looking at the collaboration between teams, see if your overall process is always connected. I can imagine that you have a high level R&D process in place where you have a workflow consisting of the 5 steps you defined as your teams. An issue type like Initiative / Idea / Project / ... could represent that and help you track your high level progress. I can imagine that the design and engineering work take multiple tasks to complete. So if you can bring those in team projects and link them to that high level initiative, you can track both progress of your initiative and all the tasks related to that. Just mentioning that as I see you mention you are on a premium plan and have advanced roadmaps at your disposal.

[Jacob Issac]

Thank you for that @Walter Buggenhout