The overall provisioning process is relatively straightforward in Microsoft Teams and is generally handled through one of three mechanisms:

• The end user creates a new team from the Microsoft Teams interface.
• The end user creates a new team from an existing Office 365 Group.
• Developers or IT staff deploy an application frontend to manage the Teams request and deployment process.

While the actual mechanics of deploying and configuring a Team can be very straightforward, there are several planning activities that most organizations will want to engage before starting wide deployment and adoption of Teams. We'll cover some of these common governance activities at a high level:

• Team or group naming policies: You can configure group naming policies that include adding prefixes or suffixes based on values stored in Azure AD attributes, such as names, as well as lists of blocked words that can't be used in group or team names. These settings are configured in the Azure AD portal, as shown here:

• Guest access: Part of your Teams governance policy may include limiting guest access and their rights. You will learn more about managing Guest access in Chapter 15, Planning Identity and Authentication for Teams.
• Usage policies: Most organizations require users comply with an "Acceptable Usage Policy" when using corporate assets. A link to a web page containing usage policies can be configured as an Azure Active Directory settings template for Office 365 Groups. Usage policies are managed via the Azure AD PowerShell.
• Data classifications: Many organizations, especially those in regulated industries, make decisions that depend on the classification of data. You can create data classification labels that can be selected when creating Office 365 Groups or Teams, and then implement automation in the form of scripts or functions to ensure groups and teams comply with your organizational classifications. One example of a classification and accompanying policy might dictate that groups that are classified as "Highly Confidential" are not allowed to have external guests. 

• Team creation limitations: By default, all users can create and manage Office 365 Groups and Teams. However, this may be undesirable for some organizations. Through the Azure Active Directory portal, you can limit who can create Office 365 Groups and Teams to a subset of users (such as service desk personnel) or build (or purchase) and deploy an application that requests and creates groups on a user's behalf. Group and team creation limits can be managed through Azure AD PowerShell or the Azure AD Portal.
• Approved apps: Depending on your organization, you may wish to allow or prevent certain applications from being connected to the Teams environment or restrict those policies to certain users in your organization. App policies were covered earlier in this chapter and are configured through the Microsoft Teams admin center.
• Team or group expiration policies: As previously mentioned, all users can create teams and groups by default. This may lead to a significant amount of unused groups. Group expiration policies can be used to cull unused groups by requiring users to confirm they still need groups or teams after certain periods of time. Group expiration policies are configured through the Azure AD Portal, as shown here:

• Retention policies: Retention policies can be used to preserve data in the event of accidental or malicious data destruction. Retention policies can also be used to preserve data that might normally be lost through the normal course of conducting business (such as group or team retirement or user separation from an organization). Retention policies for Teams, Office 365 Groups, and other data types are configured and managed through the Security & Compliance center.

While each organization will have different governance goals and requirements, the process for gathering requirements and documenting the business will be consistent.

In the next section, we'll look at using Teams templates to create consistent-looking Teams.