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

Best practices for seperate IT teams within same project

Eric Bjerke

Hello!

I am working on implementing a service desk for our IT department and adding it to our existing company portal. We are transitioning away from ServiceNow. Within our IT project work items will come in and I would like only one portion of our IT team (IT Specialists) to receive notifications on them. From there, if they deem the work item needs to go to another group within our department (ie one of a few different development groups), what is the best way to accomplish this? What would be an ideal method to allow them to assign it to another group, not necessarily a specific person?

I have come up with countless different ways to do this, but none seem to be perfect. I am looking for suggestions and best practices if anyone could give me some suggestions, that would be greatly appreciated!

Accepted answers

Eugenio Onofre_v78igo

Hi @Eric Bjerke

Welcome to the Atlassian Community!

Sounds like you're already putting a lot of thought into the setup — totally get how tricky it can be to find the perfect flow when transitioning from a platform like ServiceNow.

One common and flexible approach in Jira Service Management is to use Components or a custom "Group" field to represent the different teams (e.g., IT Specialists, Dev Group A, Dev Group .

Another possible approach would be to use the default "Team" field. Here is more information about Atlassian Teams:
https://support.atlassian.com/atlassian-account/docs/what-is-an-atlassian-team/

You can then pair this with Automation rules to notify only the right group based on that field's value — and even assign the issue to a shared queue or triage board for that team.

For example:

IT Specialists receive all incoming tickets by default.
If they decide a ticket needs to go to another team, they simply update the "Group" or the "Team" field to the appropriate team.
An automation rule can then @mention the correct group, move it to a different queue, or update visibility — without assigning it to a specific person.

Best Regards,
Eugenio

All comments

Eugenio Onofre_v78igo

Hi @Eric Bjerke

Welcome to the Atlassian Community!

Sounds like you're already putting a lot of thought into the setup — totally get how tricky it can be to find the perfect flow when transitioning from a platform like ServiceNow.

One common and flexible approach in Jira Service Management is to use Components or a custom "Group" field to represent the different teams (e.g., IT Specialists, Dev Group A, Dev Group .

Another possible approach would be to use the default "Team" field. Here is more information about Atlassian Teams:
https://support.atlassian.com/atlassian-account/docs/what-is-an-atlassian-team/

You can then pair this with Automation rules to notify only the right group based on that field's value — and even assign the issue to a shared queue or triage board for that team.

For example:

IT Specialists receive all incoming tickets by default.
If they decide a ticket needs to go to another team, they simply update the "Group" or the "Team" field to the appropriate team.
An automation rule can then @mention the correct group, move it to a different queue, or update visibility — without assigning it to a specific person.

Best Regards,
Eugenio

Eric Bjerke

@Eugenio Onofrethank you for the fast response!! The custom group field was my initial plan I was pursuing, good to hear that is one of your suggestions. Is there any advantage or disadvantage of this method over components?

One more question on this method, what would be the ideal method for the "To" field for sending email notifications within automations? What you "hardcode" each users email address here, or is there a location a method to build a group of team members then just reference that team?

Thank you,
Eric

Eugenio Onofre_v78igo

Hey @Eric Bjerke

Components are great if you're sticking with default Jira functionality. They allow for default assignees and reporting, but aren't super flexible for dynamic notifications. Custom group/team field gives you more control and flexibility — especially if you want to build automations around specific teams without assigning issues directly to individuals.

So if routing and notifications are your focus (rather than reporting or assignee logic), the custom group field tends to be more powerful.

About the "to" field, You're right — by default, Jira doesn’t have a built-in way to send emails to a dynamic group of users unless you hardcode addresses in the rule, or you reference users stored in a custom field (like an assignee or reporter)

I would suggest creating a User Picker (multi-user) custom field — e.g., “Team Members”. When a group is selected (like Dev Team A), use an Automation rule to populate that custom user field with the team’s members (using branching logic or smart values). Then in the email action, set the "To" field as: {{#issue.customfield_XXXXX}}{{emailAddress}},{{/}}

Alternatively, if you're open to using third-party apps like Automation Toolbox or ScriptRunner, they let you reference Jira groups or project roles more easily in notifications.

Please don't forget to vote and accept this answer in case it helps you!

Eric Bjerke

Thank you!! That is exactly the help and suggestions I was looking for!!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management