Three Team types
Microsoft Teams is one product, but the way it's used varies enormously. A clear three-type model — informal collaboration, professional groups, project & work initiative — keeps the platform usable and lets retention behave differently for each.
| Team type | Purpose | Examples |
|---|---|---|
| Informal collaboration | Day-to-day collaboration within a defined team or function. Chat, files, light project work. | Department teams, working groups, ongoing operational teams. |
| Professional groups & engagement | Communities of practice, special-interest groups, social/cultural teams. Longer-running, less time-bound. | 'IT Architecture Community', 'Women in Tech', 'New Hires Welcome'. |
| Project & work initiative | Time-bound work with defined start and end. Files, conversations, planner tasks. | 'Project Apollo', 'Q3 Strategic Planning', 'CRM Migration Workstream'. |
Three Team types is the recommended starting point. Some organizations consolidate to two (Project + Everything Else), and that works if your project content has clearly different lifecycle from your ongoing work. Adding a fourth type (External-facing, Customer-facing, Vendor) can also make sense in specific contexts. Start with three; add or consolidate based on actual usage.
Channel strategy
Microsoft Teams supports three channel types. Choosing the right channel type for the right purpose prevents most channel-sprawl problems.
| Channel type | Storage location | Best for |
|---|---|---|
| Standard channel | Files in the Team's main SharePoint document library. | Default for almost all use cases. Visible to all Team members. |
| Private channel | Separate SharePoint site collection (one per private channel). | A subset of Team members needs to discuss something the rest of the Team shouldn't see. Use sparingly — each private channel is a new site. |
| Shared channel | Separate SharePoint site collection. Members can include people outside the parent Team or organization. | Cross-Team collaboration; cross-organization collaboration via Teams Connect. Replaces guest invitations for ongoing relationships. |
Each private and shared channel creates its own SharePoint site collection. A Team with 10 private channels has 11 site collections, each with their own permissions, retention, and governance. Use private/shared channels only when the access model genuinely requires separation — not as a substitute for organizing content with folders.
Lifecycle defaults per Team type
Different Team types deserve different retention and lifecycle treatment. Apply per-type defaults at provisioning, not retroactively.
| Team type | Active retention | End-of-life |
|---|---|---|
| Informal collaboration | Channel files: dispose 6 months after last modified. Chats follow tenant chat policy. | Team archived when inactive 12 months. Disposed 24 months after archive unless renewed. |
| Professional groups & engagement | Channel files: dispose 2 years after last modified. Chats follow tenant chat policy. | Team archived when inactive 18 months. Disposed 24 months after archive unless renewed. |
| Project & work initiative | Channel files: no active retention while project is active. Chats follow tenant chat policy. | Team archived on project end (defined end date or owner trigger). 2-year readonly hold; team disposed entirely (chats, files, planner) at end of hold. |
Retention for channel files applies as a SharePoint policy on the Team's backing SharePoint site, not as a Teams-specific setting. A Teams archive policy applies to the Team itself (group object) and disposes the entire Team — chats, planner, channel folders.
Backing SharePoint site retention
Every Team has a backing SharePoint site collection. Channel files live in document libraries in that site. Retention applied to the site applies to the channel files.
-
Generic policy. Apply the per-Team-type default at provisioning. The policy is a SharePoint retention policy targeting the site URL or, better, sites tagged with the corresponding property bag.
-
Specific labels. Project deliverables that need to be kept beyond the Team's lifecycle should be labeled explicitly so they survive Team disposition (or moved to a records hub before disposition).
-
Copy to records. When a Team is being archived, the Team owner is given a window to identify content that should be preserved as records and routed to the appropriate records hub.
Kybera Impact applies Team-type-appropriate retention via property-bag-driven adaptive scopes. When a Team is provisioned via the Workspaces module, its site gets the right property bag; the Compliance module's adaptive scope picks it up automatically; the right policy applies. The Lifecycle module manages archive triggers, the readonly hold window, owner notifications, and disposition execution.
Stock Microsoft Purview and Teams admin tools support the same model — but coverage drift is the persistent issue. Teams created outside templates miss the property bags that adaptive scopes depend on, and end up with no retention. Plan for a regular audit of Teams-without-retention as part of the operating model.
Project Team archive and disposition
Project Teams are the most disciplined lifecycle case. They have a defined start and end. When the project ends, the Team should be archived rather than left to drift.
The Team is managed at the container level — the M365 Group, the site, the channels, the files all archive and dispose as a single unit. There are no file-by-file decisions at end of life.
-
Records capture before archive. Anything in the Team that needs enterprise retention — signed contracts, approved policies, regulatory submissions, audit-relevant artefacts — must be moved or declared into the appropriate Record Centre before the Team is archived. Once the Team is in the read-only state, content can still be read but not moved cleanly.
-
Archive trigger. Project end date (set at Team creation) or explicit owner trigger. Owner is notified before automated archive.
-
Archive state. Team becomes read-only. Chats, channels, files all visible but immutable. Owner can unarchive if work resumes.
-
Readonly hold. A defined hold window — long enough for late-arriving needs (audit, legal, project lessons-learned) but bounded. The exact window is configurable per organization.
-
Disposition. At end of hold, the entire Team is disposed: chats, planner, channel folders, the M365 Group itself. Owner is notified before disposition.
Without a defined archive trigger, project Teams accumulate indefinitely. Year three of any deployment without lifecycle has hundreds of dormant project Teams nobody owns. The archive trigger is the single most important lifecycle control on the platform.
Provisioning patterns
-
Restricted creation. Teams creation should be restricted at the tenant level (only specific users or groups can create Teams directly).
-
Request flow. Teams creation requests flow through the standard workspace request process — Broker approval, template-based provisioning, property-bag tagging.
-
Naming policy. Tenant-wide naming policy applies (prefix or suffix indicating Team type, owner, or business area).
-
Owner requirements. Every Team has at least two owners. A single-owner Team is a single point of failure.
-
Sensitivity label at creation. Container-level sensitivity label applied based on Team type and content.
Discussion Questions
• Do we want three Team types or simplify to two?
• Which Team types are appropriate for external collaboration via shared channels?
• What's our policy on private channels — encouraged, discouraged, or restricted?
• What active-retention defaults make sense per Team type for our regulatory environment?
• How long should the readonly hold be for archived project Teams — 1 year, 2 years, longer?
• Who owns the archive trigger for project Teams — the Team owner, the Broker, automated based on end date?
• How do we handle Teams that don't fit the three types — external customer Teams, vendor Teams?
• What's our cadence for auditing Teams without retention coverage?