You can now automate your workflows with Atlassian Teams!

[#1]

Hey Automation Community 👋

Happy to announce that you can now use Atlassian Teams natively in automation rules to keep your workflows scalable and accurate.

Gone are the days of using workarounds such as hardcoding your `teamId`.

What's new?

Easily route issues and assign work to the right team with:

New automation actions

• Edit work item: When a work item is created in Team Mobile's board, set Team Mobile so work is tracked accurately.

• Field value changed: When a Team is set for a work item, move work item to that team’s board and notify them.

• Create work item: When an alert is created, create a work item and assign to Team Mobile.

• Clone work item: When 'cross-team' label is added, clone the work item into Mobile Team’s board and set team field to Team Mobile on cloned work item.

New automation conditions

• Work item fields condition: If team field is Team Mobile, then add a comment mentioning the Team Mobile engineering lead.

New automation triggers

• Field value changed: When Team field value is changed, move it to the newly assigned Team’s board.

• Member added or removed: When a member is added to the team, send them a welcome email with all onboarding materials. **currently only available in Confluence Cloud, Jira Cloud coming in March

How do I use it?

1. Go to Project settings → Automation (or Global automation).

2. Create a rule - select one of the trigger or actions shared above to use Teams in automations!

What's next?

• Assign work item to user in a team: If work item is assigned to Team Mobile, then assign this ticket to David who is in Team Mobile.

• User condition: For work item assigned to Team Mobile, ensure the assignee is in Team Mobile.

Tell us what you think

We’d love to see how you use this:

• What rules are you building with the Teams and in what product?

• What other Team-based automation would help your workflows?

Share your examples and feedback in the comments so we can keep improving this experience!

[Dirk Ronsmans]

Awesome! Love how you guys are working on all these smaller things that really make a difference!Things like this just make working with Automation (and Teams) so much easier and straightforward.

We are mainly adopting Teams in JSM projects to assign work to L1/L2/L3 Teams.

Unfortunatly adoption is being halted a bit due to:

• not being able to limit what teams are available in a specific space
• linking/limiting Assignee to the Team that is set on a work item
• block creating of teams unless you are an admin (and often having teams with duplicate names)

Therefor at the moment we only use the Team automation to set another field to a specific User Group on which we limit the value of assignee through the permission scheme

[Todd Thomas]

Wonderful news!

Once the Team field supports multiple teams, can be used in dashboard gadgets, permissions, notifications, and security levels, we'll be excited to take advantage of it. For now, we have to rely on the Components field since it supports multiple components (which act like teams).

[Dave Mathijs]

I totally agree with all of the feedback by @Dirk Ronsmans  +1

[Rune Rasmussen]

This is great news.

One big automation rule we have today is used to map services/tools/systems to teams.

When a work item is created set the "IT Team" field depending on what the "IT Service" field was set as.
Every queue in our JSM Space is at minimum based on a value from the "IT Team" field.

What we want to do is start using the Teams rather than our IT Team field.
With this we're one step closer to being able to do that.

Next on our wish list is being able to make custom "Teams picker" fields AND being able to define which Teams are available in a field.
Being able to control who can create new teams, edit/manage existing teams
Being able to add "Teams" attributes in Assets.

With all that in place we could:
Create every supported service/tool/system in Assets and give them a "Support team" attribute.
Automation could set the correct Team on item creation.
Update queue JQLs to use Teams rather than our custom field.
Ensure that tickets do not accidentally get delegated to a Team that doesn't actually work in a given Space.

Besides all that, it would be neat to create/edit Teams through automation.
Currently a Team can be linked to a single group, but sometimes a Team could consist of members of multiple groups, or some other common denominators/attributes.
Linking Teams to Groups today is a manual task. Being able to link through Automation would be helpful.

For Spaces it would be helpful if Teams could be connected to Spaces/content.
This could help in sending out reminders to check up on old/stale content, default to a new content owner if the current owners account becomes inactive (they leave the company).
This would help in both Jira and Confluence.
Ticket not updated for a week? Notify Assignee.
Ticket unassigned? Notify Team lead.
Ticket not updated for two weeks? Notify Team lead.

Page content not read/updated for more than six months? Notify content owner.
Account gets deactivated? Change content owner to Team Lead.

[Tim Posselwhite]

Cool. 

Are we able to automate move work item to another space/project now as well?

[__ Jimi Wikman]

Awesome!!
This is a much-welcome addition to the automations to kick off 2026!

I love it!

[Darryl Lee]

OMG @Dirk Ronsmans they *still* haven't dealt with Unique Team Naming yet? I thought they would've resolved that when they the option to sync with Groups working.

(I refuse to do any work with Teams until they fix that. Also, what even could you even do with Teams in Jira or Confluence with regards to JQL, CQL, Workflows, and until today, Automation?)

I can't believe they considered it an MVP when you could have like 10 Teams all named "Project Central Dev Team".

"Oh it's fine. People will always check to see if there's an existing team with that name first."

1. No they won't.

2. You know what's really good at doing that kind of thing? Yeah that's right, software.

[__ Jimi Wikman]

Maybe we should separate the feedback for the Automation from the problems the Teams field has?

Adding this as an automation is great, but the usage will depend on what problems you encounter with a field like the Teams field that is still struggling to find its place between users and groups (and yes, it struggles with technical implementation as well as mentioned here).

@April Chi perhaps you can pass something internally that there is a lot of feedback for the Teams team, so they might want to bring in some of these here and add a research post to get more feedback?