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; } } }

On change/update of Assignee in a issue, the Team filed should be autofilled as Assignee belong to.

Ram Sharma

User - A Team - Fly
User -B Team - Samsung

on Assignment of a issue type to User A, the Team Field should be auto field/Auto pick the team - Fly.

similarly in case of change of assignee.

How we can achieve this.

Accepted answers

All comments

Gor Greyan

Hi @Ram Sharma ,
Please provide the type for the Team field, on which it should be autofilled.

Tuncay Senturk _Snapbytes_

Hi @Ram Sharma

I am unsure if I have it correct; however, you can do it with automation.

- Create a rule with the "Issue Assigned" trigger.

- Then add a condition if/else block

-- if (assignee = User A), set team = Fly

-- else if (assignee = User , set team = Samsung

Ram Sharma

@Tuncay Senturk _Snapbytes_
It should pick the team name from Team.

Ram Sharma

Team -

Assigne - A .. check the team Assignee A belong to in the team .

Autofill the Team filed - name of the team.

Gor Greyan

Dear @Ram Sharma

If it the Team field is Select List field, you can input Fly and Samsung values into it, then create an automation.

Trigger - When issue is assigned to a user

If/Else block - Condition, if Assignee is user A

Action - Edit Issue field Team and select option Fly.

Else block - Condition, if Assignee is user B.

Action- Edit issue field Name and select option Samsung.

Let me know, if there is any question.

Trudy P Claspill

@Ram Sharma

A user can belong to multiple Teams. How would you expect Jira to figure out which one to choose?

Also, there is no function provided already as part of Automation to determine the Teams of which a user is a member. A Jira REST API call would have to be made to get that information.

Rick Westbrock

The suggestions to hard-code "if Assignee = User A" are not scalable if there are more than just a couple of users. You could use a lookup table in the rule instead of hard-coding conditions however even then the rule would have to be updated every time a new user is added to the project. And to Trudy's point a user can belong to multiple Teams so an assumption would have to be made for each user that in a specific project their Team would always be the same.