How to create workflow and automation to assign tickets in my Jira service portal to specific board?

[Youmna Alomari]

Can you guide how to create a workflow to have specific tickets in my Jira service project to show up in a Jira software board? 

[Trudy Claspill · Accepted solution]

Hello @Youmna Alomari 

Jira Service Management in Cloud has its own "board view" feature.

Are you trying to make the issues display in another board?

If so, the JSM issues would need to conform to the criteria specified in the filter for that board. What is the filter for the board where you want the issues to display? That would be found by viewing that board, then clicking the ... button in the upper right corner of the board, and select Configure board. In the new screen you would choose the General option and scroll down to find the Filter Query.

You would need to either update the JSM issues to match the filter criteria, or change the filter so that it will include the JSM issues.

[Youmna Alomari]

I'm trying to have some of the new tickets opened in my Client support Jira project to show up in another Jira software board and assigned to a specific team member. 

[Trudy Claspill]

Do you want the original JSM issue to show in the board, or do you want to clone the JSM issue and create a separate issue in the Software project to show in the Software project's board?

[Youmna Alomari]

Some of the original issues created to show in my teams board.

[Trudy Claspill]

Please show us the query used by the board where you want the JSM issues to be displayed.

[Youmna Alomari]

Filter Query

( project = Align OR project = ama1 OR project = BCBSM OR project = Endurance OR project = Fender OR project = Genpact OR project = GFS OR project = Kindercare OR project = "Northern Safety" OR project = "RBFF SEO" OR project = "Spectrum Reach" OR project = "Tommy Bahama" OR project = Whitetail OR project = "ME&I Platoon Team" ) AND "Platoon Team[Checkboxes]" = Yes ORDER BY Rank ASC

[Youmna Alomari]

I want any issue created in my client support Jira project to automatically appear on another Jira board if the ticket belongs to the team assigned to that board. 

[Trudy Claspill]

Is your client support Jira project one of the ones listed in the filter? If not, the query will need to be modified to add the client support Jira project to it. 

In your client support Jira project are you using the "Platoon Team" checkbox field?

[Youmna Alomari]

No, It's not listed in the Filter Query. I'm assuming I can add that in the Quick filters section in my project settings? 

Yes, we are using a checkbox field. However, when the field is checked, the ticket does not appear on the Platoon board, which is where I want Platoon tickets to be displayed.

[Trudy Claspill]

The board will display only issues that match the filter. If the client support project is not in the list of projects in the Filter Query on the General page of the Board configuration.

You must change that Filter Query to include the project. The Quick filters are a way to apply a filter to what is already included in the Board by the Board's Filter Query. Changing the Quick Filters will not solve the problem.

On the General page of the Board's configuration, above where you found the Filter Query, you will find the name of the filter. And near the filter name there may be a link labeled Edit Filter. If you click on that it will take you to a screen where you can edit the filter. However you may not have permission to save the changes back to the original filter, if you are not the owner of the filter or a designated editor of the filter. In that case you have the following options:

1. Contact the filter owner and ask them to change it.

2. Contact a Jira Administrator and ask them to change the filter, or make you the filter owner so you can change it.

3. After you change the filter, change it under a new name and then change the board to use the new filter.

[Youmna Alomari]

Ok, I've updated the filter query and included the client support project. However, I'm a bit confused about the last step you mentioned: "change it under a new name and then change the board to use the new filter" Are you suggesting that I rename the board? And how do I go about changing the board to use the new filter? 

I'm still getting the hang of things since my lead recently left the company. Any guidance you can offer would be greatly appreciated! 

[Trudy Claspill]

Hello @Youmna Alomari 

Those were not three steps, those were three options. You would execute only one of them.

Based on your last screen image you have successfully updated the filter that is used by the board (either using option 1 or option 2). 

The next thing you need to review is the Columns configuration.

When you add a project to a board, if the issues in that project have different statuses then you will need to map them to columns on your board.

The new statuses would appear in an area marked "Unmapped statuses".

You need to drag-and-drop the status blocks from that area into the appropriate columns to the right so that the issues in those statuses will display on your board and in your Backlog (if you are using the Backlog screen). Issues in a status that is in the "Unmapped statuses" area will not display in either the board or the Backlog.

If you are new to Jira and/or new to administering the different features of Jira, I also recommend that you check out the Atlassian University site for the free training courses that are available there:

https://university.atlassian.com

[Youmna Alomari]

Thank you! This worked! And the issue did appear on my other board. I thought I will need to create a workflow in order for this to work! 

[Trudy Claspill]

I'm glad I was able to help you.

If my responses helped you solve your requirement, please consider clicking on the Accept Answer button at the top of my responses. That will mark your post as Solved and assist other users searching for answers about similar problems.

[Youmna Alomari]

Hi, 

Circling back to this post. My tickets from (BCS board) are now showing in (Platoon board). However, the workflow for my (BCS tickets) differs from those in the (Platoon board), causing an issue with moving the (BCS tickets) to a different column. Can you advise on how to align the workflow of my tickets from a different board with the workflow in another board?

Thank you, 

[Trudy Claspill]

Hello @Youmna Alomari 

What is the specific problem you are encountering?

[Youmna Alomari]

The Platoon board is configured with swimlanes, but I'm encountering difficulty moving my BCS tickets to another column.

[Trudy Claspill]

Hello Youmna,

Are you trying to drag the card to a different swimlane at the same time that you move it to another column? That would not be allowed.

A swimlane is a horizontal grouping of issues based on a common value (blue box).

You should be able to move issues to another column in the same swimlane (green arrow).

But you can't move an issue to a column in a different swimlane (red arrow).

If that doesn't address your question, please provide a more detailed description of exactly what you are doing when you try to move a card to another column and exactly what happens when you do try that. Saying that you "encounter difficulty" doesn't tell me what is actually happening. Screen images or a video would be very helpful to understand your problem.

[Youmna Alomari]

Hey Trudy, 

When attempting to move my ticket from the 'In Progress' column to 'QA 3', I encounter an issue. This ticket originated from another board and has a different workflow assigned to it compared to tickets originally created in this board.

[Trudy Claspill]

What is the current Status of the issue you are trying to drag to the QA column? What is the Status that you want to change it to? Is that status available in the workflow for the issue you are trying to move?

Can you share with us the Column/Status mapping information for this board? Is that new status mapped to the "QA" column?

Are you able to change the status of that issue to the intended Status if you go directly to that issue and click the Status button/pull down?

[Youmna Alomari]

Pending to QA3 for example, the status is not available in the workflow for this issue. 

No, I'm unable to change the issue status to the intended status from the dropdown list. This ticket originated from a different board that has a different workflow.

[Trudy Claspill]

You cannot change an issue to a Status that is not part of its workflow. An issue can have only one workflow applied to it. You can combine issues that have different workflows in one board, which is what you have done, but the issues still can follow only their own workflow.

[Youmna Alomari]

In that case, I'm unable to change the issue workflow to match the ones in the current board.

[Trudy Claspill]

That is correct.

The BCS tickets/issues displayed in the Platoon board will follow their own workflow.

Why do you need to change the workflow of the BCS tickets?

Maybe you would be better off cloning the BCS tickets to make new issues in the software project(s) that are included in the Platoon board. Those new issues would follow the workflows of their parent project(s).

[Youmna Alomari]

A user in our Platoon board is unable to move the BCS tickets to the next column, although they can move other Platoon tickets as usual. They believed they could do so. 

So if they clone a BCS ticket located in the Platoon board, will the ticket essentially have the same workflow as the Platoon ones?

[Trudy Claspill]

The native Clone function will not allow you to make a copy of an issue into a different project. The user would have to use the Clone function to make a copy of the BCS ticket in the BCS project, and then use the Move function to move that copy to one of the Software projects that is otherwise part of the Platoon board.  As part of the Move process the user would have to specify an Issue Type that is available in the destination project - the copied BCS ticket being moved would have to get a new Issue Type as part of the Move process.

The moved issue would then adhere to the Workflow for that issue type in the destination project.

Note that if the BCS and Platoon board projects use different fields, there may be some data loss during the move of the copied BCS issue. And there would not be any ongoing synchronization between the original BCS issue and the copied/moved issue.

[Youmna Alomari]

That would create a lot of additional work every time an issue is assigned to someone in the Platoon board.

Thank you for sharing all the information! 

[Trudy Claspill]

Perhaps if we go back to the root issue we can find another solution.

What problem are you trying to solve by displaying the Service Management issues in your Platoon board, which otherwise shows issues from Software projects?

Why do you want to apply a different workflow to the Service Management tickets when they are displayed in the Platoon board? Why is it not viable to process them with their original workflow from the Service Management project?

Are the people who work on issues in the Platoon board also licensed Service Management Agents with access directly to the BCS project? If not, then they would not be able to change the statuses on the BCS tickets displayed in the Platoon board anyhow.

[Youmna Alomari]

We have two distinct boards where our team members address issues. The BCS board is designated for clients to submit tickets, but occasionally, some of these tickets are assigned to the Platoon team for resolution.

[Trudy Claspill]

I see.

But what problem are you trying to solve?

Displaying the BCS issues in the Platoon board does not necessarily mean that Platoon team members can work on the issues. They would need to have JSM Agent licenses and permission to the BCS project, or be Collaborators.

https://support.atlassian.com/jira-service-management-cloud/docs/what-users-and-roles-are-there-in-jira-service-management/

And what problem would you be trying to solve by changing the workflow of the BCS issues?

[Youmna Alomari]

The Platoon board has swimlanes configured and operates with a different workflow compared to the BCS board. When tickets from the BCS are assigned to the Platoon board, users encounter difficulty moving them between columns because the workflow differs from that of the Platoon board.

 They are a different team that does not have access to the BCS board since most tickets are not within their responsibility.

[Trudy Claspill]

I feel that we are having a problem communicating. Either I am not asking my questions clearly, or I am not understanding your answers.

I'm happy to keep trying, and I'm also content to stop pursuing this if you don't see value in working through the miscommunication.

-----------------------

An agile board is just a method to visualize and manipulate issues in 1..n projects. The board does not determine the permissions, fields, screens, or workflows for the issues that are displayed in the project. Those configuration elements are set by the project that contains the issues.

I understand that you have a Service Management project (BCS).

I understand that you want members who have access to the Platoon board (which includes Software projects) to be able to be assigned to the BCS issues.

That seems to be the first element of the problem you are trying to solve.

That issue can't be solved by simply showing the BCS issues in the Platoon board.

In order for user to be able to be assigned to the BCS issues and work on them those users must have a JSM Agent license and must be assigned to a Role in the BCS project.

Are you willing to address that requirement by granting the users the appropriate licenses and access to the BCS project? Or has that requirement already been addressed?

If that requirement has been or can be addressed then we can move on to the next element of the requirement/problem you are trying to solve.

If the users have the appropriate licenses/permissions, they will be constrained to working on the issues in a manner that conforms to the configuration of the BCS project with regard to permissions, screens, fields, and workflows.

You can display the BCS issues in the Platoon board, which may make it convenient for the Platoon team members to work from one board rather than two. But that will not change the configuration of the BCS project/issues.

You would need to map the available statuses for the BCS issues to Columns that are displayed in your Platoon board. The names of the statuses don't have to match the names at the top of the columns. If you want to be able to move a BCS issue to the "QA" column, you must map one of the available BCS issue statuses to that column.

My question at this stage would be why do you need to move the BCS issue to the "QA" column, specifically? If the BCS issues don't have a "QA" status, why do you feel that the issue needs to be able to be placed in that column?

[Youmna Alomari]

Regarding the requirement to grant users appropriate licenses and access to the BCS project, yes, that has been addressed.

I don't necessarily intend to move the issue to the QA column specifically; that was an example. The request pertains to allowing a teammate to move BCS issues between columns within their Platoon board.

And now, I have a couple of questions. If I map BCS issues to the QA column, does that mean they will exclusively move to that QA column? And would this mapping affect the workflow of my issues in the BCS board? Additionally, does this imply that every issue assigned to the Platoon board requires the same mapping process for statuses? Lastly, would you recommend proceeding with this approach?

[Trudy Claspill]

In a board you map issue Status values to the columns.

The Name on the column is not required to match the name of any of the Statuses mapped to that column.

When you drag a card to a column you are telling Jira that you want to change the Status of that card/issue to the Status that is mapped to the destination column.

For example, in the image above, if you drag a card to the QA column you are telling Jira that you want to change the issue's status to "QA".

If the column has more than one Status value mapped to it, like the In Progress column, then when you drag a card to that column you will see areas highlighted for each available Status in that column. You drop the card in the highlighted area to indicate that is the Status to which you want to change the issue.

Now, having said that, a card/issue can be set to only the Status values that are available in the Workflow assigned to the issue's type for the Project in which that issue exists.

When you try to drag a card to a column only the Statuses that are valid for that individual issue will show up. If there are no Statuses mapped to that column that are valid for that card/issue, then you can't move the card to that column.

As we discussed previously, you can change the filter of the board to include the issues from the BCS project.

The first time you make that change the Statuses that are available for the BCS issues that appear in the board will show up on the Columns page in the Unmapped Statuses area, like this:

Each of these Statuses needs to be placed in a column on the board. You can put the Statuses in existing columns or you can make new columns.

The BCS card/issues can then be dragged to the columns that contain a Status that they use in their workflow. The cards cannot be dragged to columns that don't contain a Status that is used by the BCS issue workflow(s).

If I map BCS issues to the QA column, does that mean they will exclusively move to that QA column? And would this mapping affect the workflow of my issues in the BCS board? 

You could move a BCS issue to the QA column only if the QA column has a Status in it that is part of the BCS issue's workflow. Since the BCS issue is still using its own workflow, the workflow of the issue is not affected. But changing the status of the BCS issue in the Platoon board will be reflected in the BCS board. Recall I said the boards are just a way visualize and work with issues. A change you make to an issue in one board will be reflected in all boards where that issue appears. It is the same issue, being shown in multiple locations.

Additionally, does this imply that every issue assigned to the Platoon board requires the same mapping process for statuses? 

I'm not sure what you mean by this question. Every type of issue displayed in the board has an associated Workflow that dictates the Status to which that issue can be set. The Statuses available for all the issues shown in the board, from all their workflows in their respective projects, must be mapped to Columns in the board. If a Status is left in the Unmapped Statuses area, then issues set to that Status will not be displayed on that board.

Lastly, would you recommend proceeding with this approach?

That depends on the problem you are trying to solve. I don't feel that you have given a clear definition of the problem you are trying to solve. Why do you want to display the BCS issue in the Platoon board?

Why not just have those team members work with the issues in the BCS project itself, and in the Board that is available for the BCS project? 

I understand that Platoon team members may be assigned to BCS issues. Do you want to display those BCS issues in the Platoon board because that makes it convenient for those team members? Do you need to consider the work the team members are doing on BCS issues when looking at the work they are also doing in the other projects in the Platoon board? 

I'm not asking about the problems you are trying to solve after you have made changes to show the BCS issues in the Platoon board. I'm asking about the problem you are trying to solve where you think displaying the BCS issues in the Platoon board is the solution.

[Youmna Alomari]

Thank you for sharing this information with me.

Regarding why I want to display the BCS tickets in the Platoon board, this was a request from the Platoon team to do it that way. 

[Trudy Claspill]

As an administrator of Jira systems I have always felt part of my responsibility was to evaluate the requests the Jira users make about changing the configuration of Jira. When the users ask me to make a change I ask "why - what problem are you trying to solve?" Digging into the problem that they are trying to solve can lead to discovering that there is a better solution than the one they proposed.

So, I would encourage you to go back to the Platoon team and ask them - what problem are you trying to solve?

[Youmna Alomari]

I agree with you. However, given that I was unexpectedly assigned to work with Confluence after my lead left, I believed that requests from my teammates could be accommodated, especially since they are familiar with their board.

[Youmna Alomari]

.

[Youmna Alomari]

.