We're building archiving Teams and would love your feedback!

[#1]

Hey folks!

I hope you’re all doing well and thank you for keeping this community so active and engaged 😀

We’re excited to share that we’re working on a highly requested feature: the ability to archive Teams. To make sure we get this right, we’d love to hear your thoughts and feedback.

How archiving is expected to work:

• Once a team is archived, it can no longer be associated with new work - meaning it won’t appear in selection pickers and end users won’t be able to select it.
• The team will remain linked to any work it was previously connected to, preserving historical associations.
  • i.e. all existing connections are maintained 

We’d love your input on a couple of questions:

• Should org admins receive notifications for when a team is archived or unarchived?

  • For context, when a team is deleted or restored, notifications currently go to:

    • The user who performed the action

    • Members of the affected team

    • Org admins

• Do org admins still want to receive notifications for archiving? Or would that just add unnecessary notification noise? (considering archiving is going to happen much more frequently then deletion/restoration)

  • So far, we haven’t received much negative feedback about org admins getting emails for team deletions/restorations (in fact, I heard from many of you that you wanted all the email notifications), but we’d love to hear about your experiences.

Look forward to your feedback. If you have anything else you'd like to suggest/comment on, please drop it below in the comments and be sure to tag me @April Chi .

[Jared Schmitt]

Hi @April Chi 

While I'm not sure if I will use the archiving functionality very often, my 2 cents on the topic:

• Notifications are great, as long as you can turn them off. Would be great if admins can configure if they want to receive them or not.
• Additional API endpoints would be really appreciated by all premium/enterprise customers. Operations I can think of are "List archived teams", "Archive team by id/name", "Unarchive team by id/name".
• Will archived teams disappear in a user's profile section? It might be confusing if one sees all active and archived teams a user is currently in.

[Dave Mathijs]

• Should org admins receive notifications for when a team is archived or unarchived?
  Yes, org admins should continue to receive notifications as it is a cross-app feature.

• Do org admins still want to receive notifications for archiving?
  Yes, same answer as the previous question.

+ the same questions as @Jared Schmitt 

Is Team creation, editing, archiving, deletion also added to the Audit Log?

[James Rickards _SN_]

This is great. We had a need to archive teams! It'll help remove the clutter.

Currently as a solo admin, I don't want emails about me archiving teams. I know, I did it. However, I vote for you to send them anyway, so the system is consistent with how archiving of Jira Sites and Confluence Sites works. Consistency is important! If, in the future such notifications are made configurable, it should be done for all products/apps from a central location.

Thinking from when I worked with enterprise scale orgs, my 2c is that it is more important to capture sufficient data in the Security Event logs.  This would enable the SIEM to detect and alert any unexpected pattern of archiving / deleting allowing a timely response to an insider threat.  Whilst these are often black swan scenarios, if you work for an org with millions of dollars of IP and core business processes running inside Jira / JSM, the financial consequences of a trusted admin going rogue are severe enough to warrant effort to mitigate.

"Zero Trust" also means also not trusting that you'll be in your right mind at all times, and setting up systems to monitor both yourself and your peers.

[April Chi]

Hey @Jared Schmitt ,

Thank you for the feedback! Appreciate it and helps a lot.

• Notifications are great, as long as you can turn them off. Would be great if admins can configure if they want to receive them or not.

Unfortunately, configurability for Team notifications don't exist today so if archiving teams sent a notification to org admins, the workaround would be for you to set filters in your emails. 

• Additional API endpoints would be really appreciated by all premium/enterprise customers. Operations I can think of are "List archived teams", "Archive team by id/name", "Unarchive team by id/name".

We are in indeed providing this! You will be able to archive and unarchive teams through bulk, and also in the existing get all teams API, there'll be an attribute for archived teams.

• Will archived teams disappear in a user's profile section? It might be confusing if one sees all active and archived teams a user is currently in.

I agree it'd be confusing and add too much clutter. For this reason, archived teams won't show up in user profiles. You'll be able to search for them though. 

[April Chi]

• Should org admins receive notifications for when a team is archived or unarchived?
  Yes, org admins should continue to receive notifications as it is a cross-app feature.

• Do org admins still want to receive notifications for archiving?
  Yes, same answer as the previous question.

+ the same questions as @Jared Schmitt 

Is Team creation, editing, archiving, deletion also added to the Audit Log?

Hey @Dave Mathijs , noted, thank you for the feedback. Yes, Team creation, editing and deletion are already events in the audit log (provided you have Atlassian Guard Standard/Premium). Archiving/unarchiving Teams will also be fired in the audit log so you can track it.

[April Chi]

This is great. We had a need to archive teams! It'll help remove the clutter.

Currently as a solo admin, I don't want emails about me archiving teams. I know, I did it. However, I vote for you to send them anyway, so the system is consistent with how archiving of Jira Sites and Confluence Sites works. Consistency is important! If, in the future such notifications are made configurable, it should be done for all products/apps from a central location.

Thinking from when I worked with enterprise scale orgs, my 2c is that it is more important to capture sufficient data in the Security Event logs.  This would enable the SIEM to detect and alert any unexpected pattern of archiving / deleting allowing a timely response to an insider threat.  Whilst these are often black swan scenarios, if you work for an org with millions of dollars of IP and core business processes running inside Jira / JSM, the financial consequences of a trusted admin going rogue are severe enough to warrant effort to mitigate.

"Zero Trust" also means also not trusting that you'll be in your right mind at all times, and setting up systems to monitor both yourself and your peers.

Hey @James Rickards _SN_ , thanks for the feedback! That makes sense, we'll take that into account. FYI archiving/unarchiving teams will also be fired in audit logs so you can track them. Here are Team events that are currently available in the audit log.

[Rune Rasmussen]

As an org admin I would like notifications about teams archived by someone who is not me.
No need to tell me about the things I've done.

Will archived Teams still be selectable when making new JQLs?
I can see the value of doing a review of work items where an archived team is selected but the item is still open.
Something along the lines of "statuscategory != Done AND Team = "The old team (Archived)".
The autocomplete feature of JQL could add the "(Archived)" suffix to the Team name to make it clear that you are now finding things related to an archived Team.

We've recently run into a similar problem in Jira Assets with deactivated users selected in User attributes.
We can't filter on deactivated users easily because they don't they don't show up in the basic or advanced filter options.

[Josh]

I'm a little late to the party here but wanted to voice support for @Rune Rasmussen 's request about how archival impacts JQL. I'm in 100% support of what has been outlined here.