nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can Automation set the Team field when an issue is assigned?

Mark.Stewart

Using Advanced Roadmaps we have set up a Shared Team with 2 people in it. I would like to set the Team field in an issue when one of these people is assigned to an issue.

Otherwise it becomes a manual task to update the Team field which seems redundant as we already know what team they are in.

Automation would need to look up if this person is in a Team and then set the Team field.

Assumes that a person can only be assigned to 1 team.

Comments

Simmo_9kntn7

Hi @Mark.Stewart

I'm afraid that this isn't possible at the moment. While it might be possible to set the Team field via Automation, there isn't any means for looking up if that person is in a Team at this time.

Cheers,

Simeon.

Curt Holley

This can definitely be solved with Automation for Jira (if you have?)

Trigger= Issue Created

User condition (where you add all the team members)

Action = Edit issue (currently needs to configured via the more options section with a bit of json) see below

Note: you need to know your teams number

Dave

Hey @Mark.Stewart ,

I just wanted to provide some context around the absence of the direct linking between assignee and team. At one stage (back when Advanced Roadmaps was originally being developed as Portfolio for Jira 3.0 on Server) we were considering having tighter coupling between fields.... So for example you'd only be able to assign a sprint from the issue source associated to the assigned team, etc.

However we decided not to implement this as there was no way of enforcing this from the issue screens. So whilst we could prevent this within the plan interface (or provide automatic setting features) we wouldn't have the same ability within the issue screen.

One approach we have considered is both adding warnings (i.e. "hey you've assigned this issue to an assignee who isn't a member of the assigned team") and the ability to request smart "fixes" (i.e. "I'll assign the team that this assignee belongs to").

Of course there are always edge cases ... for example, there is nothing that stops an assignee being a member of more than one team (both within the tool, and in reality) so then you have to decide which team to assign.

We are keen to understand how customers want to get the most out of teams though and whether or not you'd like to have the option of this tighter association between team and assignee (as well as team and issue source).

One thing I'm particularly interested in at the moment is how you might be using teams in relation to issue sources? For example could a team be associated by multiple issue sources and would you also want to see that association reflected directly on that issue source - i.e would you want to see the team displayed and configured on the boards themselves and not just within plans?)

Regards,

Dave

Mark.Stewart

Thanks Dave.

Totally get that you do not want to have tight coupling which is why I was going down the automation path.

Our organisation has 4 teams that will be working on BAU changes / minor enhancements. We want to use the Dependency Report to show any blockers between teams.

We are still in the process of setting up the plan but the approach I am taking is to have 1 team associated with 1 issue source ie. 1 board for each team where the board JQL is Team = {teamid}.

I am also displaying the Team on the Jira board. The users are familiar with assigning users so I was hoping to look up the Team they are assigned to and automatically assign the Team. Of course this assumes that a person can only be assigned to 1 team.

I need to investigate and test the feedback from Curt Holley (comment above) but currently suspect there is no way to do this. If that is the case then I will look at a process change to set the Team field when the issue is created.

Simmo_9kntn7

@Mark.Stewart

I'm from the Automation team so I can tell you that we don't have native support for it and I'm not familiar with the make up of their field but if it is in a fairly normal format then such an approach as suggested will work.

Best way to figure it out is to have a look at the REST view of an issue with the field set on it, eg XXXXX.atlassian.net/rest/api/2/issue/BIO-13?expand=names

You then can replicate that in the advanced section of the edit action. For example, if it is of the form:

{ "id": "6" }

then in your edit action you'd do:

{
    "fields": {
       "XXXXXXX": {
          "id": "6"
       }
    } 
}

It can take a bit of fiddling to find the right format. It might be a 6 without the quotes or it could be in the format as suggested by Curt.

If you get stuck, post here and we can help. We just can't help you find mappings or anything, but we might be able to set the field if you can figure out the value

Mark.Stewart

Curt,

thanks for the feedback. I can update the Team value. That's all good.

What I want to do is lookup the Team value of the person who has been assigned to an issue and then assign that value to the Team field. This avoids users having to update both the Assignee and Team fields as we already know what Team a person is assigned to (assuming a person can only be assigned to 1 team).

As per Simeon's response I don't think this is currently possible.

I will look to a process change to set the Team value when the issues are first created.

Thanks again.

Dave

Thanks for providing that additional info @Mark.Stewart - it's really valuable!

One quick follow up question:

I am also displaying the Team on the Jira board

...do you mean you've given the board a name that directly maps to the team name?

One of the things I'm exploring is whether or not there would be value in setting team association directly in the board configuration and having the team name automatically displayed and having the board filter be updated to only include issues assigned to the team (this would obviously be optional). If such a capability was available would that be something you'd use?

Regards,
Dave

Rudy Holtkamp

For the late arrivers, here is a Tempo blog how to fix this:

https://tempo-io.atlassian.net/wiki/spaces/KB/pages/1822982145/Set+a+Tempo+team+on+Jira+issue+assignment

Wolfgang Seidler

I've tried all different kind of formats, but the automation keeps failing with "Team" not being recognised as valid field.

Failing attempts:

Additional fields contains invalid field(s) in 'update' or 'fields' section: Team

{ "fields": { "customfield_12500": { "id": 4 } } }

{ "fields": { "customfield_12500": { "id": "4" } } }

{ "fields": { "customfield_12500": "4" } }

{ "fields": { "customfield_12500": 4 } }

{ "fields": { "Team": "4" } }

{ "fields": { "Team": { "id": "4" } } }

{ "fields": { "Team": { "id": 4 } } }

{ "fields": { "Team": 4 } }

What am I doing wrong?

Thanks for help!

Rene C. [Atlassian Support]

I believe this is for a different topic. The post is about Advanced Roadmaps teams, not Tempo teams.

Patrick_nqb657

Hi @Wolfgang Seidler,

I've been struggling to get it work using some of the suggestions in this thread as well. Using the custom field ID for Team just didn't work at all (kept erroring, saying that Team needs to be a string). What has worked for me is @Curt Holley format above:

{
"fields": {
"Team": "16"
}
}

For reference, the json for the Team field in my target issue was this:

"customfield_10001":{"id":"16","title":"The Name Of My Team","isShared":true}

Filipi Lima

Hey, folks,

I was exploring this for a client and also out of curiosity and I see you can check the Team value using this smart value:

Disclaimer - tested on Data Center, not Cloud. It should work the same way, though.

{{issue.Team}}

Keep in mind that the customfield value for it is the Team ID, which you can find on:

select * from "AO_82B313_TEAM";

And if you want to set the Team field you'll need to know the ID beforehand. You'll need to use the more options > Additional fields section and use this format like @Simmo shared a while ago:

{
  "fields": {
    "Team": "8"
    }
  }
}

On my simple example, I see if there's a current value for Team and, if empty, set it to "8" which is the Team I want. Here's how it looks:

Slava Gefen

And also in the blog above there is checking against the specific user. The question is: if you have 100 members group, do we need to create 100 conditions for this matter @Rudy Holtkamp ? And if a new member comes, do we also need to update the Automation?

Thanks
Slava

lorenzo.betto

Don't you have an extra closing curly bracket in your example?

Amir Ansari_00dz9f

I found a solution, please follow the below steps. Thank me later

Requirement: Need to automatically assign tickets to specific groups upon creation.

Step1: Create a group by locating the “Teams” option on the navigation bar in Jira.

Step 2: Once you have created the groups, associate the Teams custom field with the desired screens of your project and attach it to the issue view of your ticket from Request Types.

Now we need to setup Jira Automation to automatically assign the ticket to the desired group upon creation.
Step 1: Go to Automation under your project settings and click on Create Rule button.

Step 2: Search and select “issue created” in the trigger section.

Step 3: Click on “IF: Add a condition“ and select “JQL condition“

Step 4: Type in the below highlighted JQL query and click on “Next“.

Query:
issuetype = "[System] Service request with approvals" OR issuetype = "Employee onboarding"

Note: You can find the issue types by going to issue types in your project settings.

Step 5: Click on “THEN: Add an action” and search and select “Edit issue“

Step 6: Under Choose fields to set select “Assignee“

Step 7: Click on “More options“, and uncheck “Send notifications?” and put in the below-mentioned JQL script.

Query:

{
"fields": {
"customfield_10001" : "7ec8fedc-dd3d-4d8c-ba44-231cc605c697"
}
}

Note:
1. The above highlighted customfield_10001 is the customfield id of your team custom field.

You can locate this customfield in the url field of your team customfield page. (Click on the 3 dots on the extreme right and click on "View field Information"

The above highlighted alphanumeric text is the team id (7ec8fedc-dd3d-4d8c-ba44-231cc605c697) of your specific team that you need to set as the default assigned group.
You can locate this team id in url field of your team’s page.

Step 8: Click on “Turn on rule”

Step 9: Create a ticket from the customer portal to see your team automation rule in action.

Dave Furlani_2zy3uu

Actually it can be solved, as other answers below describe, in particular the response from @Amir Ansari below

Maria Jose Villota

@Mark.Stewart I have the same question as you. I have users divided into different Teams and if the assignee of an issue changes, I want Jira to automatically change the Team field as well. I use Teams to group tasks in the Plans view. I reviewed @Amir Ansari 's response below and it only applies when an issue is created, not when an issue is updated. I looked at the Automation options and don't see a way to do this, if you've found a way let me know!

Guy Anela_onntyg

We had a similar request from one of our teams. They requested to have an Automation setup that sets the Team to a specific Team if the Assignee belongs to that Team; otherwise, set it to a default Team. For example, the Project has two teams that work out of it:

Team A (default team)
Team B (team for specialized work)

If the Assignee gets set to a member of Team B, then set the Team to Team B, else set it to Team A.

Here's a screenshot of the overall Automation:

You'll notice that the Automation makes a call to the Teams Members Public API using a Send web request Action. This is used to get the Members of the Team so it can check the Assignee against it. It sends a POST request to the following REST API endpoint...

https://[YOUR CLOUD SITE].atlassian.net/gateway/api/public/teams/v1/org/[ENTER YOUR ORG ID]/teams/{ENTER YOUR TEAM ID]

Again, here's a link to the Teams Members Public API for more information on the endpoint.

Once, it gets the Members, it stores them in a variable using the following Smart Value from the Web Response (See red arrow in the above screenshot).

{{webResponse.body.results.accountId}}

Anyhow, I hope this helps or at least steers you in the right direction. Cheers!

Alexander Jaeger

After much trial and error - this worked for me:

{
"fields": {
"customfield_10800" : "17551"
}
}

I kept getting the error "operation must be string"

In addition to the previous posters - These resources were helpful :

This helped show how the different ways in which I could refer to the value of the field
- LINK
This talks about the issue / solution too that might help those on Cloud w/ JIRA Align
- LINK
Finding how your instance refers to the customfield -
- https://<JIRA BASE URL>/rest/api/2/issue/ISSUEKEY-1234
- ^^make sure the custom field is set in the ISSUE KEY

Amy Chang_299cvs

Trigger: When Value Changed - Assignee

IF: Assignee is one of Person A, or Person B

THEN: Edit Issue Field

Advanced:
- {
  "fields": {
  "customfield_10001": "PUT TEAM ID HERE"
  }
  }

Maria Jose Villota

Thanks Amy! This worked like a charm

For future readers: I followed these instructions to find the custom field ID.

Jen Doherty

Hi @Guy Anela , once I got this working this method was fantastic, thank you for sharing this!

I wasn't very familiar with using APIs in Automation, so I'm sharing some additional info in case others also find it useful.

First, the step to create a base URL smart variable is not needed - Atlassian already has a smart value for this by default of {{baseUrl}}.

Second, to find your org ID, Atlassian's documentation is incorrect. When you are in the Admin console and check the URL from the address bar: https://admin.atlassian.com/o/xxxxxxxxxxxxxxxxxx/overview
The xxxxxxxxxxxxxxxxxx from the URL is your OrgID. There is no fixed prefix "08bc3992-289a-114j" to the OrgID as noted in the documentation.
To find the team ID, it is the encoded string at the end of the team page's URL.

Third, when sending the web request, you will need to include your API token in the headers, as per the Team Public REST API documentation. And don't forget to check the "Delay execution" box so your rule waits for the API response before continuing.

So, your Web request URL will be (with the appropriate [ORG ID] and [TEAM ID] inserted):

{{baseUrl}}/gateway/api/public/teams/v1/org/[ORG ID]/teams/[TEAM ID]/members

Example web request:

Screenshot 2024-06-13 135633.png

Hope this extra info is helpful to others!

Jen Doherty

I have taken @Guy Anela's example and modified it for more than two teams, using a lookup table populated with each Team's ID and a For each loop.

Jira teams automation.png

This version will loop through the created lookup table, calling each team and checking if the assignee is a member, and editing the issue with the team if so.

Some notes:

As previously noted in this thread, you will need your Org ID, your API key, and the ID for each team to make this Automation work.
Don't forget to include your API key authorization in the web request header, and to check the box to delay execution until a response is received.
I've created a variable for the JSON because as noted by @Bill Sheboy in another thread, using smart values inside the JSON in the advanced edit won't work.
The Team issue field in your instance may have a different custom field ID to mine - make sure you've got the right ID by following the Atlassian documentation.
If a user is a member of more than one team in your lookup table, the issue will be assigned to the last team they are a member of in the list. You can control this by listing the teams in your lookup table in a specific order.
- Because of this, my automation has an exception for myself, as I am a member of every team for our project.

I'd like to still make some improvements to this - for example, error handling for the webresponse and also creating an alert or similar if the assignee is not a member of any team. But I hope this is useful for anyone else looking for a solution for this problem. The Atlassian Teams feature could be much more powerful and useful than it currently is with a few changes from Atlassian.