Microsoft Teams Governance: Policies & Best Practices

Quick answer: what is Microsoft Teams governance?

Microsoft Teams governance is the set of policies and controls that keep Teams organised and secure: how teams are created, named and expired, who can join, and what security and compliance rules apply. In practice it means five decisions — who can create a team, what it must be called, how long it lives, who can be added to it, and how its data is classified and retained.

Teams governance has a reputation for being a policy binder nobody reads. It isn’t. It is a handful of settings in Microsoft Entra ID, the Teams admin center and Microsoft Purview that decide whether your tenant is a searchable workspace or a landfill of half-abandoned teams with guests nobody remembers inviting.

This guide covers the decisions that matter, where each one is configured, and what changed in 2025–2026 — including the reason governance stopped being optional for a lot of organisations: Microsoft 365 Copilot surfaces whatever your permissions allow, so every unowned team and overshared site is now an answer waiting to be given to the wrong person.

Fig. 1. The five governance decisions and where each one is configured

What Microsoft Teams governance actually covers

Every team in Microsoft Teams is a Microsoft 365 Group with extra surfaces attached. Creating a team creates a group, a SharePoint site, a group mailbox, a Planner plan and a OneNote notebook. That single fact explains most of Teams governance: the controls you need mostly live at the group and site layer, not inside the Teams app.

Governance covers five areas:

Creation — who is allowed to make a new team, and whether anything stands between the intent and the team appearing.

Naming and classification — what the team is called, and what sensitivity label describes the data inside it.

Lifecycle — how long a team lives, what happens when it goes quiet, and who decides to archive or delete it.

Access — members, owners, guests and external organisations, and how each of those is reviewed over time.

Security and compliance — retention, eDiscovery, DLP, conditional access, and what Copilot is allowed to see.

A governance plan is just a written answer to those five questions plus the settings that enforce the answers. Microsoft’s own Plan for governance in Teams guidance is structured the same way, as a series of decision points rather than a prescribed configuration — because the right answer genuinely differs between a 40-person agency and a regulated bank.

Governance is not the same as lockdown

The most common governance failure is not sprawl. It is an over-corrected tenant where nobody can create a team, so the work moves to personal OneDrive folders, private chats and WhatsApp — places with no retention, no eDiscovery and no audit trail.

Microsoft’s default position is that all users can create Microsoft 365 Groups, and it recommends keeping it that way for most organisations. Restricting creation is a legitimate choice, but it is a choice with a cost: every service that provisions a group is affected — Outlook, SharePoint, Planner, Viva Engage, Power BI, Project for the web — and someone has to absorb the request queue. Decide deliberately rather than by reflex.

Why Teams governance matters in 2026

Sprawl is the visible symptom

Teams sprawl looks like this: forty teams whose names begin with “Project”, three of them for the same project. A team created for a two-week bid that has been dormant for eighteen months and still contains the client’s pricing. Twelve teams with no owner because the owner left. Search that returns four versions of the same document from four different sites.

None of that is a Teams defect. It is what happens when a tool with genuinely frictionless creation meets an organisation that never decided what happens after creation.

Copilot turned an untidy tenant into a security problem

This is the change that moved governance up the priority list. Microsoft 365 Copilot honours existing permissions — it never shows a user something they couldn’t already open. The problem is that “could already open” turns out to be far more than most organisations assumed. Content that was technically accessible but practically buried five clicks deep in an abandoned site is now one natural-language question away.

Microsoft’s own readiness guidance for Copilot makes the connection explicit, and it reads like a governance checklist: ensure every site has a valid owner, clean up unused sites, find overshared content, remove organisation-wide access where it isn’t warranted. The risk signals it tells admins to look for are exactly the artefacts of ungoverned Teams growth — “Everyone except external users” permissions, broken inheritance, unlabelled or public sites, ownerless and inactive sites.

Two controls exist specifically for this. Restricted Content Discovery (part of SharePoint Advanced Management) stops a site’s content appearing in organisation-wide search and Copilot responses without changing anyone’s permissions — useful as a holding measure while owners review access. Restricted Access Control goes further, limiting a site to members of a named security or Microsoft 365 group so that anyone outside it loses access regardless of prior permissions or links.

Neither is a substitute for governance. They are what you reach for when governance was skipped and you need to buy time.

Pic. 1. Restricted Content Discovery setting on a site in the SharePoint admin center

The costs that show up on a balance sheet

Storage is the least of it. The real costs of ungoverned Teams are the audit finding when a regulator asks who had access to a data set and nobody can answer; the eDiscovery bill for searching 400 teams because nobody can rule any of them out; the offboarding gap where a departed employee’s team keeps running with no owner; and the slow tax on everyone’s time when finding the current version of anything takes four attempts.

Team creation and naming policies

Deciding who can create teams

By default every user can create a Microsoft 365 Group, and therefore a team. If you need to narrow that, the control is a directory-level setting in Microsoft Entra ID that points at a security group: members of that group can create, everyone else cannot.

The steps are documented in Manage who can create Microsoft 365 Groups. In outline:

1. Create a security group in Microsoft Entra ID — for example “Team Creators” — and add the users who should be allowed to create.
2. Use the Microsoft Graph PowerShell (Beta) module to set EnableGroupCreation to false and put the security group’s object ID in GroupCreationAllowedGroupId on the Group.Unified directory setting.
3. Wait — changes can take 30 minutes or more to take effect — then verify with an account that shouldn’t be able to create.

Three things regularly catch people out. First, this is a licensing requirement, not just a permission: the admin configuring it and every member of the allowed group need a Microsoft Entra ID P1 or P2 (or Entra Basic EDU) licence. Second, the restriction applies everywhere groups are provisioned, not just Teams — Planner, Viva Engage and SharePoint team sites are all affected. Third, several admin roles remain able to create groups by other routes; Teams Service Administrators, SharePoint Administrators, Exchange Administrators and Groups Administrators can each create groups from their own admin centers regardless.

A middle path worth considering: leave creation open, but require a short training module before adding someone to the allowed group. It converts the control from a gate into an onboarding step.

A naming policy that survives contact with users

A naming policy is the cheapest governance win available, and it is genuinely enforced at creation time rather than being a wiki page people ignore.

Microsoft 365 Groups naming policy has two parts, both configured in the Microsoft Entra admin center under Microsoft Entra ID → Groups → All groups → Naming policy:

Prefix-suffix naming. The structure is Prefix[GroupName]Suffix. Prefixes and suffixes can be fixed strings or Entra user attributes substituted from whoever is creating the group. Supported attributes are [Department], [Company], [Office], [StateOrProvince], [CountryOrRegion] and [Title] — anything else, including extension and custom attributes, is treated as a literal string. The total allowance is 63 characters including the group name, and [GroupName] may appear exactly once.

Custom blocked words. A comma-separated list — Payroll,CEO,HR,Board is a typical starting point. Up to 5,000 phrases. Two behaviours matter: matching is case-insensitive, and it is an exact match on the whole name, not a substring search. Blocking “lass” will not block “Class”. That is deliberate, and it means a blocked-word list is a blunter tool than most people assume.

Pic. 2. Group naming policy configuration in the Microsoft Entra admin center

The policy applies to group names and aliases across every workload that creates groups, and it fires when a group is created and when its name, alias, description or avatar is edited. Teams shows users a live preview of the enforced name as they type, which removes most of the support burden.

Practical notes: configuring the policy needs Global Administrator, Groups Administrator or Directory Writer. Global Administrators and User Administrators are exempt from the policy — convenient for admins, and a reason not to test the policy with your own admin account and conclude it doesn’t work. Naming policy requires the same Entra ID P1 licensing as creation control: possessed by, though not necessarily assigned to, every user who is a member of any Microsoft 365 Group, guests included.

Design the convention before you turn it on. A workable pattern is a short type prefix plus a substituted department, so PRJ_Atlas_Engineering and DEPT_Payroll_Finance sort and filter sensibly. Avoid encoding anything that changes — a year, a client name, a phase number — because renaming a team does not rename its SharePoint URL.

Templates and provisioning

Naming policy controls the label. Templates control what is inside. Teams templates let you predefine channels, installed apps and tabs so a new project team arrives with the structure it needs rather than a single General channel and good intentions. For organisations that need more — approvals, metadata capture, automatic owner assignment, a request form — the usual answer is a provisioning process built on Power Platform or Microsoft Graph, sitting in front of a locked-down creation setting.

Structure matters as much as naming. The most common design error is one team per project, which produces exactly the sprawl you are trying to avoid. Prefer one team per stable group of people — a department, a function, a long-running programme — with a channel per project inside it. Channels are cheap to create and delete; teams are not.

Lifecycle and expiration

Creation policy without a lifecycle policy just slows the rate at which the tenant fills up. The lifecycle side is where most governance plans quietly stop.

Fig. 2. The team lifecycle, from creation through expiration to permanent deletion

Group expiration policy

Microsoft 365 Groups expiration is the native mechanism. You set a lifetime in days — a preset or a custom value, minimum 30 — and groups that reach the end of it without being renewed are deleted.

What makes it usable rather than dangerous is activity-based auto-renewal. Groups with real use renew themselves roughly 35 days before expiry, with no email to anyone. The activities that count are specific: viewing, editing, downloading, moving, sharing or uploading files in SharePoint; joining a group, reading or writing a group message, or liking a message in Outlook on the web; visiting a Teams channel; and viewing a post in a Viva Engage community. A team anyone is actually using will never expire.

If a group is not auto-renewed, owners get email at 30 days, 15 days and 1 day before expiry. The group is deleted one day after the expiration date, and can be restored by an owner or admin within 30 days — a window that is not configurable. If the group contains a SharePoint site or other persistent objects, a restore can take up to 24 hours to complete.

Configuration is at Microsoft Entra admin center → Groups → All groups → Expiration, or through the New-MgGroupLifecyclePolicy family of Microsoft Graph PowerShell cmdlets. Details worth knowing before you enable it:

1. Only one expiration policy can exist per tenant. You can scope it to All groups, to Selected groups, or to None.
2. If you scope to Selected, the cap is 500 groups. Above that you have to apply it to all groups, where the cap does not apply.
3. When you first switch it on, every group already older than the interval is set to 35 days until expiry rather than being deleted immediately.
4. Expiration notices for teams appear in the Teams Owners feed, not only in email.
5. Set the alternate notification address. Ownerless groups have nobody to email, and that is exactly the population most likely to expire.
6. Like creation control and naming policy, this needs Microsoft Entra ID P1 or P2 for members of every affected group.
7. An archived team still expires. Archiving sets a team read-only; it does not exempt it from the policy. Exclude archived teams or renew them deliberately.
8. A group whose mailbox is on legal hold keeps the mailbox after deletion; retention policies similarly preserve content in the retention container even though users can no longer see the team.

Pic. 3. Microsoft 365 Groups expiration settings in the Microsoft Entra admin center

Archiving, and the difference from deleting

Archiving a team makes it read-only while keeping it searchable, which is the right answer for a finished project whose history still matters. In the Teams admin center, select the team and choose Archive; tick Make the SharePoint site read-only for team members if you want the site frozen too. Restoring is the same path with Restore. Note that archiving affects the team itself — connected workloads carry on as they were.

The Inactive teams card in Teams admin center analytics shows teams whose connected workloads have also been inactive over the last 30 or 60 days, with privacy type, channel count, user count and last activity date per team, and lets you archive directly from the report.

Site lifecycle policies for organisations at scale

Where SharePoint Advanced Management is licensed, site lifecycle management adds three policy types that work across Teams-connected sites and are considerably more nuanced than a single tenant-wide expiry date:

1. Site ownership policies enforce a minimum number of owners or site admins and notify when a site falls below it — the direct fix for ownerless teams.
2. Inactive site policies detect sites with no meaningful activity across SharePoint, Teams, Exchange and Viva Engage, and notify owners.
3. Site attestation policies ask owners to periodically confirm the site is still needed, rather than inferring it from activity.

None of them delete anything outright. After three monthly notifications go unanswered you can choose to do nothing, set the site read-only, or set it read-only for a configurable 3, 6, 9 or 12 months and then archive it through Microsoft 365 Archive. One detail that trips people up: clicking the site link in a notification email does not count as activity, and read actions within an hour of that visit are ignored — only real edits reset the clock.

Access and guests

External collaboration is where governance gets tested, because the people you are governing don’t work for you.

Teams offers three different routes for outsiders, and they behave differently enough that treating them as one setting is a mistake.

Fig. 3. Guest access, external access and shared channels compared

Guest access adds the person to your tenant. Anyone with a business or consumer email address can be invited; a guest account is created in Microsoft Entra ID, and from that point they are covered by the same compliance, auditing, conditional access and MFA controls as your own users. Guests are labelled (Guest) in the client and a channel shows an icon when guests are present. A guest must be added to at least one team before guest features work at all.

External access (federation) covers chat, calls and meetings with people in other Microsoft 365 organisations without adding them to anything. It is the right control when the requirement is “let us talk to them”, not “let them into our workspace”.

Shared channels, built on Microsoft Entra B2B direct connect, let people from another Microsoft 365 organisation into a single channel using their own credentials, with no guest account and no tenant switching. Access stops at that channel — they cannot see the rest of the team. Shared channels are on by default in Teams, but external collaboration through them is off by default and requires both organisations to configure a mutual trust relationship in cross-tenant access settings. If your conditional access policies require MFA, you must also configure inbound trust settings to accept MFA claims from the partner tenant, or their users will simply be blocked.

The practical rule: use shared channels when you are working with another Microsoft 365 organisation on a defined workstream, guest access when the person needs the whole team or isn’t on Entra ID, and external access when you only need to reach them.

Pic. 4. Guest access settings in the Microsoft Teams admin center

Whichever you use, the governance question is not the invitation — it is the removal. Nobody leaves a team voluntarily when a project ends. Two Entra ID capabilities exist for this:

1. Access reviews put a recurring prompt in front of group owners to confirm who still needs access, with recommendations attached. Reviews of a team with shared channels can include B2B direct connect users alongside guests and internal members, though only in single-stage reviews. Requires Entra ID P2.
2. Entitlement management bundles a team, its site and its apps into an access package that people request, with a named approver and an expiry date built in — so access ends by default rather than by someone remembering. Also P2.

For the full configuration walkthrough, see our guide to Microsoft Teams guest access.

Permissions and roles

Teams has a deliberately small role model — owners and members, plus guests — and most governance problems here come from owners rather than permissions.

The rule that solves the largest share of them: every team needs at least two owners. One owner is one resignation away from an ownerless team that nobody can add members to, rename, or delete. Make it a standard applied at creation, and audit it periodically — or enforce it with a SharePoint site ownership policy where you have the licensing.

Beyond ownership, the settings worth deciding centrally are which member actions owners may delegate (creating and deleting channels, adding apps, adding tabs and connectors), whether private channels can be created and by whom, and channel moderation for announcement-style channels where posting should be limited. Private channels are useful and slightly awkward: each one gets its own SharePoint site, which is a governance surface of its own.

Admin-side roles follow the standard Microsoft least-privilege guidance — Teams Administrator, Teams Communications Administrator and Teams Communications Support roles exist precisely so that day-to-day Teams work doesn’t need Global Administrator. Our Microsoft Teams permissions guide covers the role matrix in detail, and the Teams admin center guide covers where each setting lives.

App governance changed in 2025 — check which model you’re on

This one catches admins out because the documentation for the old model is still widely linked. App permission policies are deprecated. They have been replaced by app centric management, which controls availability on a per-app basis: for each app or Copilot agent you specify the users and groups who can use it, rather than building policies and assigning users to them.

Tenants that used only the default global policy were migrated automatically; from April 2025 automatic migration was extended to the rest, and once migrated the change cannot be reverted and permission policies become inaccessible. Auto-migration creates one security group per former custom policy and populates it with that policy’s users, so the resulting groups are yours to manage afterwards.

Two limits to plan around: you can add up to 99 users or groups to an app at a time, and bulk updates aren’t available in the admin center UI — use the Update-M365TeamsApp PowerShell cmdlet instead. Changes take up to 24 hours to reach all users.

Check which model your tenant is on before writing an app governance procedure. Open Teams admin center → Teams apps → Permission policies: if you see policies, you’re still on the old model; if you see a migration notice, you’re on app centric management.

Pic. 5. Manage apps page in the Teams admin center showing per-app availability

Security and compliance

Teams inherits the Microsoft 365 security and compliance stack rather than having its own, which is good news — the controls are mature — and a governance trap, because they are configured in four different portals.

Sensitivity labels on containers are the highest-leverage control available, because a label applied to a team applies simultaneously to the Microsoft 365 Group and the connected SharePoint site. A container label can set and lock privacy (public or private), control whether owners may add guests, control external sharing from the labelled site, require conditional access for unmanaged devices, apply an authentication context, prevent a private team from being discovered, and control shared channel invitations. Two further settings — default sharing link type and site sharing settings — are PowerShell-only.

The critical thing to understand: a container label protects the container, not the items in it. A file taken out of a labelled team and shared elsewhere carries no protection unless the file itself is labelled. Container labels and item labels are complementary, not alternatives.

Labels are configured in Microsoft Purview with the Groups & sites scope, and users pick one from a Sensitivity dropdown when creating a team; the label then appears in the corner of every channel.

Pic. 6. Selecting a sensitivity label when creating a new team

Retention policies for Teams cover channel messages, chats and files, and run independently of expiration — a group can expire and be deleted while its content remains preserved in the retention container, recoverable through eDiscovery. Decide retention before you decide expiry, not after.

Data Loss Prevention for Teams inspects chat and channel messages against sensitive information types and can block or warn. Communication compliance covers policy violations in messages. eDiscovery and legal hold work across teams and their connected sites. Conditional access governs who can reach Teams from where and on what device.

For a deeper treatment of the security side specifically, see our guide to Microsoft Teams security and data privacy.

Auditing and reporting

Governance you cannot measure is aspiration. The reporting to build a routine around:

1. Teams usage and advanced collaboration analytics in the Teams admin center — active teams, inactive teams, guests per team.
2. Microsoft 365 audit logs — team and channel creation and deletion, guest additions, role changes, app installs.
3. Data access governance reports in the SharePoint admin center — sharing links, “Everyone except external users” usage, site permission baselines, sensitivity label coverage.
4. Microsoft Entra audit logs — including the list of groups that were auto-renewed by activity.

A monthly pass over inactive teams, ownerless teams and guest counts, plus a quarterly access review cycle, is enough for most organisations. Our Microsoft Teams reporting guide goes further on building the dashboard side.

Governance tooling: what’s native, what’s missing

Microsoft’s native controls cover policy well and operations poorly. It is worth being clear about the gap before evaluating anything third-party.

What the native stack does well: enforcing rules at creation (naming, classification, who can create), expiring and archiving on a schedule, controlling external access, protecting and retaining data, and reporting on all of it.

Where it leaves gaps: approval workflows in front of team creation, ongoing owner accountability outside SharePoint Advanced Management licensing, cross-tenant reporting, and — the one most organisations feel daily — anything that reduces the reason people create redundant teams in the first place.

That last point is worth dwelling on, because it is the part governance policy cannot fix. People create a new team when the existing one doesn’t show them what they need. A department team where the shared schedule is invisible, task ownership is unclear and deadlines arrive without warning generates spin-off teams, spin-off channels and side chats, all of which become tomorrow’s sprawl. Structure inside a team is a governance control, even though it never appears in a governance policy document.

Where Virto apps fit

Virto apps for Microsoft 365 don’t replace Entra ID policies, and nothing outside Microsoft Purview can set retention or apply a sensitivity label. What they do is make an existing team complete enough that people stop building alternatives to it — and they do so while inheriting, rather than bypassing, the permissions you have already configured.

Virto Calendar App overlays SharePoint lists, Exchange and Outlook calendars, and Google Calendar into one view inside Microsoft Teams as a separate app or as a tab inside any channel, so a team’s schedule, absences and project milestones live where the team already works instead of in a separate site someone had to create. Because it reads from the underlying SharePoint and Exchange sources, a user sees exactly what their existing permissions allow — the calendar adds a view, not an access path. It runs in Teams, Outlook, the Microsoft 365 app and SharePoint, and works in the Teams mobile app.

Pic. 7. Virto Calendar App shown as an app inside Microsoft Teams

Virto Kanban Board App turns a SharePoint list into a board with swimlanes and card-level detail. The governance value is ownership: every task has a visible owner and status, which is what makes an access review or an attestation answerable rather than guesswork, and what makes it obvious when a team is genuinely finished.

Virto Notifications & Reminders App sends conditional alerts and reminders into Teams channels or chat from SharePoint list changes and dates — approvals waiting, deadlines approaching, policy reviews due. Governance processes fail quietly when they depend on someone remembering; a reminder that arrives in the channel is more reliable than a calendar entry nobody set.

All Virto apps are available on a 30-day free trial, with no credit card required. Pricing starts at $2 per user per month for the Starter tier (up to 30 users) and $3 per user per month for Pro (31–200 users), with Enterprise pricing on request — see the pricing page for current details, and the full Microsoft Teams app range for everything else.

A practical Teams governance checklist

Work through this in order. Each row is a decision, a place to configure it, and the licence it needs.

Fig. 4. A governance operating rhythm: what to check monthly, quarterly and annually

Frequently asked questions

What is Microsoft Teams governance?

Microsoft Teams governance is the set of policies and controls that keep Teams organised and secure: how teams are created, named and expired, who can join, and what security and compliance rules apply. Because every team is a Microsoft 365 Group with a SharePoint site attached, most of those controls are configured in Microsoft Entra ID, Microsoft Purview and the SharePoint admin center rather than in Teams itself.

What are the best practices for Microsoft Teams governance?

Start with a naming convention and enforce it with a naming policy. Require at least two owners on every team. Structure around one team per stable group of people with a channel per project, rather than a team per project. Apply sensitivity labels to set privacy and guest permissions at the container level. Turn on an expiration policy with activity-based renewal. Review guests quarterly. Keep creation open unless you have a specific reason to close it, and if you close it, put a fast request process behind it.

How do I set up a Teams naming policy?

In the Microsoft Entra admin center, go to Microsoft Entra ID → Groups → All groups → Naming policy. Configure a prefix-suffix pattern using fixed strings or supported user attributes ([Department], [Company], [Office], [StateOrProvince], [CountryOrRegion], [Title]), and upload a blocked words list. It requires Microsoft Entra ID P1 licensing, and Global Administrators and User Administrators are exempt from the policy.

What is a Teams expiration policy and is it safe to turn on?

It sets a lifetime for Microsoft 365 Groups; groups not renewed by the end of it are deleted. It is safe for most tenants because renewal is automatic for any group with real activity — a channel visit, a file action in SharePoint, a group message in Outlook — around 35 days before expiry. Owners of genuinely dormant groups get warnings at 30, 15 and 1 day, deletion happens one day after expiry, and a deleted group can be restored within 30 days. Set an alternate notification email so ownerless groups don’t expire silently, and remember that archived teams still expire.

How many owners should a team have?

At least two. A single-owner team becomes unmanageable the moment that person leaves or changes role, and ownerless teams are one of the strongest risk signals in Microsoft’s own Copilot readiness guidance.

What is the difference between guest access and a shared channel?

Guest access creates an account for the person in your tenant and can give them access to a whole team. A shared channel uses Microsoft Entra B2B direct connect to let someone from another Microsoft 365 organisation into one channel using their own credentials, with no guest account and no tenant switching — and no access to anything else in the team. Shared channels need both organisations to configure cross-tenant trust.

Does Teams governance require extra licences?

Some of it. Creation restriction, naming policy and expiration all require Microsoft Entra ID P1 or P2 for affected users. Access reviews and entitlement management require P2. Site lifecycle policies and Restricted Content Discovery require SharePoint Advanced Management. Retention, sensitivity labels, DLP and eDiscovery come with Microsoft 365 E3 or E5 depending on the feature. Archiving teams, structuring teams and channels sensibly, and reviewing usage reports cost nothing.

How does Teams governance affect Microsoft 365 Copilot?

Copilot respects existing permissions, so it never grants new access — but it makes existing overexposure visible and easy to reach. Ownerless teams, unlabelled sites, broad “Everyone except external users” permissions and abandoned content that was previously buried can all surface in Copilot answers. Reviewing permissions, ownership and inactive teams before a Copilot rollout is the standard recommendation; Restricted Content Discovery and Restricted Access Control are the interim controls while that review happens.

Sources

• Microsoft Learn — Plan for governance in Teams
• Microsoft Learn — Manage who can create Microsoft 365 Groups
• Microsoft Learn — Enforce a naming policy on Microsoft 365 groups in Microsoft Entra ID
• Microsoft Learn — Configure the expiration policy for Microsoft 365 groups
• Microsoft Learn — Use sensitivity labels to protect collaborative workspaces
• Microsoft Learn — Guest access in Microsoft Teams
• Microsoft Learn — B2B direct connect overview
• Microsoft Learn — Use app centric management to manage access to apps
• Microsoft Learn — SharePoint site lifecycle management
• Microsoft Learn — Restrict discovery of SharePoint sites and content
• Microsoft Learn — Get ready for Microsoft 365 Copilot with SharePoint Advanced Management
• Microsoft Learn — Archive or delete a team in Microsoft Teams
• Microsoft Learn — Advanced collaboration analytics for Microsoft Teams