Microsoft Teams is rapidly becoming a central part of the collaboration story within many organisations. As a direct replacement for Skype for Business, it’s obvious to see why.
Teams really merges two different types of functionality into a single application:
Communications – including chat, audio & video conferencing and more recently telephony
Collaboration – utilising the Office 365 Group model to provide members with channels for content (i.e. documents, videos, images) storage & sharing, task management boards and integration with other online services.
This post focuses on governance within the Collaboration part of Microsoft Teams.
If you only read one part of this blog post: Turn off self-service Group creation
Seriously, if your staff are able to create their own Groups/Teams, then stop reading this blog and disable self-service creation straight away: https://docs.microsoft.com/en-us/office365/admin/create-groups/manage-creation-of-groups
If you decide not to do this, your tenancy is probably already careening out of control. Every organisation I’ve worked with which has allowed staff to create their own Groups has seen a rapid growth of new workspaces (one organisation I’m currently working with has seen more than 1,000 Teams created by staff). The problem is, without any governance in place, your Groups will contain siloed and unclassified content; as an organisation, you simply won’t know for sure what you have or how important it is.
This problem is compounded if you ever want to allow external guests to access your tenant. If you have opened your tenant to external guests and allow self-service Group creation, you will find it very difficult to establish precisely which content people outside your organisation have access to.
Sure, there is a major drawback of disabling self-service creation of new Groups/Teams. If staff can’t create their own workspaces, they will look elsewhere for the tools they need to get on with their jobs. The impact this will have will depend entirely upon the way your staff expect to be able to work but, in many organisations, disabling self-service Group creation can fuel a growth of Shadow IT. This can potentially lead to even less control over your content, so make sure you introduce an alternative creation process. In the short-term, this could be a manual request/creation process (at least you will get to track who owns each workspace and what the intended purpose of each was initially), but in the medium term, you will almost certainly want to set yourself up with a request-approval-provisioning process, to securely and consistently manage the creation of new Groups, Teams and SharePoint sites.
Who should be able to create Teams?
If we’ve disabled self-service Group creation, then by default nobody will be able to create new Teams. The perfect solution is to introduce a controlled provisioning process to allow new Teams to be requested, approved and then created complete with all of the controls you wish to apply. However, another option to consider is to restrict who can create new workspaces to a defined group of users: https://docs.microsoft.com/en-gb/office365/admin/create-groups/manage-creation-of-groups
Sharing with external guests
If your organisation has decided to enable sharing with external guests anywhere within your tenancy, then it’s important to recognise that this setting will be enabled for all new workspaces that are created. As such, if your tenancy allows external guests, each Team (Office 365 Group) will also allow external guests to be added as a Member.
If you wish to limit which workspaces allow external guests then you can disable guest access within specific Groups (and therefore within specific Teams) via PowerShell. Ideally, when each Group is created a decision should be made around whether external guests should be allowed. Thinking about how this works in practice, it’s unlikely that disabling external sharing will be applied consistently via any manual process – effectively, this is another reason why a provisioning process to manage the creation of new workspaces is essential for anyone looking to share with external guests.
Types of Team
There are three different types of Team that can be created:
Org-wide – Only available for organisations with less than 5,000 users (just increased from 2,500 a couple of months ago), Org-wide Teams are designed to provide a space for collaboration across the entire organisation.
Public – These teams are designed to provide shared collaboration spaces to allow groups of users to share content and ideas. By default, anyone (internal) can join the Team as a Member and all members have the ability to add/edit/delete most of the content within the Team. Also note that content in Public teams is searchable by all internal users.
Private – Functioning in a very similar way to Public Teams, except that membership is controlled by the Group Owners and content is shown in search results to anyone except team members. Private Teams are now hidden by default and in the future Owners will have the option to hide them.
Team permissions
Permissions within the Collaboration part of Microsoft Teams are almost entirely based upon access control provided by Office 365 Groups.
At face value, Office 365 Groups has a really simple permissions model. Each Group has only two types of users and for the most part there is no way to modify the permissions that are granted to each:
Owners are effectively Group administrators. They are responsible for overseeing the Group and its associated workloads. Importantly they control the membership of the group and are able to modify anything within the Team (including the ability to delete the Team itself).
Members are granted access to collaboration within the Group’s workloads. However, it should be emphasised that Members aren’t merely consumers of the Group’s content, they are granted the ability to create, edit and delete content within the Group. For example, while they can’t delete the Group’s associated Microsoft Team entirely, they are empowered to delete Channels within the Team – effectively giving them the ability to delete entire conversations and all the files stored within the given Channel.
Importantly, there is no concept of a ‘Visitor’ within an Office 365 Group – as such, you cannot provide specific users with read-only or limited access to the Group’s content.
Within Private Teams, anyone who isn’t a member cannot see any of the content. Effectively, every Private Team is its own information silo.What this means from a governance perspective:
Within both Org-wide and Public Teams, anyone inside your organisation is either already a Member, or can choose to make themselves a member.
By default, all of the Team’s Members can delete any files that are stored within a Team (irrespective of the type of Team that is created)
Team settings that can be configured
Team Owners have a number of different configuration settings, which modify the permissions that are granted within the Team. There are no hard and fast rules to determine how these settings are configured. Rather than go through them all, I’ll pick some of the more important from a governance perspective:
Allow Team Members to:
create and update channels
delete and restore channels
add and remove apps
manage tabs (add, edit, remove)
delete messages posted to the conversation
edit messages posted to the conversation
@mention the entire Team (or one of the channels within the Team)
Allow External Guests to:
create and update channels
delete and restore channels
One great feature is that you can adjust the type of a Team. As such, an Owner could decide to switch their Public Team into a Private or Org-Wide Team.
Other Governance considerations with Teams:
Configuring a group-connected SharePoint team site
One thing that you might want to consider is whether you wish to modify the permissions granted to the SharePoint site collection (which is where the files saved to your Team will reside). I’m personally in favour of slightly reducing the permissions granted to Group Members, by granting them the ability to Contribute (rather than Edit). This change needs to be undertaken after the Team has been created, something that is best handled automatically via a workspace provisioning process. This subtle change, allows Group Members to control content, but not structures – for example, removing their ability to delete Document Libraries, or modify Content Types etc.
Ensure Teams naming conventions
If you allow users to create their own Groups, it’s very likely that you will quickly encounter issues with naming conventions. A typical scenario we see is for a regional HR team to call their new group HR, before the central HR department has got around to creating its own workspace.
One solution for organisations with either an Azure Active Directory Premium P1 license or Azure AD Basic EDU license is to make use of a ‘Groups Naming Policy’ to prefix/suffix groups. This can combine fixed strings with certain AD attributes (derived from the profile of the user who creates the Group). You can also block certain words from being used within the name of a group, which could be especially useful to reserve specific groups and guard against names containing inappropriate language.
Alternatively, the process of ensuring that your Groups/Teams are named consistently can be part of a controlled provisioning process. This could, for example, ensure that naming prefixes/suffixes are applied to all workspaces, and empowers reviewers to ensure that inappropriate names are not approved.
Consider Teams auto-expiry
Again a benefit of Azure AD Premium licences is that one of the Teams governance tools you have at your disposal is the ability to manage the lifecycle of your Office 365 Groups with expiration policies. When an expiration policy is set, Owners of the group are notified that they should consider renewing the group as the date of expiration approaches. If they choose not to, then any group that is not renewed is deleted (with up to 30 days to restore deleted groups if required).
Teams also provides an Archive feature, which allows owners to make their Team read-only, allowing content to be retained and viewed, but not edited. Usefully, archived Teams can be restored as required, making it a great governance tool. Personally, I’d like to extend the archiving capabilities with the ability to trigger immutability upon archive and automating the archive process for inactive workspaces.
Control content retention within Teams
One of the most powerful tools available for governance within Teams, is provided by Office 365 Retention Labels and Retention Policies. These can be used to ensure that content is automatically retained, or automatically disposed, within specific time parameters. If you govern the creation of new Teams and Channels effectively, there is nothing stopping you from setting default Retention Labels on each of the libraries and folders in your group-connected team sites.
To get best value from this, you should probably consider applying default retention labels to each of your different channels, as this will avoid the headache of manual tagging. To ensure consistency and reduce ongoing effort, you might wish to ensure that a process for automatically setting default labels is considered.
Footnotes / References
1 This is the default setting when the Team is created. Group Owners can choose to disable this
2 In theory this is Everyone (except external users), as anyone internal can choose to join the team
3 Private Teams are (currently) hidden, so people outside of the Team cannot choose to join (unless they are added or provided with a code to join the Team). NB, Microsoft has announced that a new ‘discoverability’ setting will be provided for Private Teams which will be introduced from this summer (2019). New Public Teams created after this point will be discoverable by default – hence, non-members will be able to make request to join (which will need approval by one of the Group Owners)
4 Microsoft has just (30/04/2019) announced that Private Teams will be getting a new ‘visibility’ setting, that will determine whether people can find them. Existing Private Teams will continue to be hidden by default; new Private Teams will be created visible but can be subsequently hidden.