Microsoft Teams Governance: Stopping Sprawl Before It Starts

M365 FM - Microsoft Teams Governance - Stopping Sprawl Before It Starts

00:00:00 Speaker: Teams were supposed to organize work, one place, one conversation, one home for every project, but open any tenant that's been running for three years and you'll find thousands of teams. Nobody can explain half of them. Nobody knows who owns them, and nobody wants to be the person who deletes the wrong one. So the usual response is to blame the users. They create too much. They don't follow rules, they never clean up. But in reality, that's not what's happening. Sprawl isn't a user problem. It's the model behind how teams get created. Anyone clicks a button, a team appears, and the system never asks again whether that team should still exist. So in this episode, we follow the whole life cycle. From the moment a team is requested to the day it's archived or deleted. Naming, ownership, expiration, guests, channels, templates, labels, all of it without blocking the people who actually need to work. And if you want to see the next life cycle failure coming before it lands on your desk, subscribe now. But before we talk about the model, let's look at the damage sponsor segment. Educational break, a quick break and this one is actually relevant. This episode is supported by stellar Migrator for exchange. Here's the connection. Every migration project eventually hits the same wall, you plan the move, you scope the mailboxes, and then you open the source tenant. And what you find is years of decisions. Nobody documented groups with no owners, mailboxes tied to teams. Nobody remembers guests who still have access to things they should have lost long ago. That's governance debt. And it doesn't stay hidden. It shows up during every migration, every tenant consolidation, every merger. A clean tenant moves faster. It costs less to move, and it's far easier to trust once you arrive. Stellar Migrator for exchange is built for that work mailbox migrations and tenant moves where you need to know what you're carrying across the link is in the description if that's your situation right now. Now back to how sprawl actually takes shape. Section one. What sprawl actually looks like in a real tenant? Let's make this concrete sprawl sounds abstract until you open the list of teams and read it out loud. Test. Test two project new team. New team two. Marketing team. Marketing. Marketing official. These aren't made up examples. In most organizations, a list like this shows up in the first ten minutes of any tenant review. Every one of those names is a decision someone made in about four seconds, with no guidance and no reason to think harder. Start with duplicates. Someone needs a space for a campaign. Searches for an existing team can't find it and creates a new one. Maybe the old one was there all along, hidden behind a bad name. Maybe it was private and they weren't a member either way. Now there are two. The next person who searches finds both and has no idea which one is real. Then come the abandoned teams. A project ends, people move on. Nobody posts anymore. But the team sits there, still in search results, still holding files, still listed in the teams rail for anyone who joined. Nothing tells you it's dead. It just goes quiet and quiet is the problem. A dead team looks exactly like a healthy team that's having a slow month. Same icon, same name. Same permissions. The only difference is activity and nobody is looking at activity. Now go one level down to ownership. Every Microsoft three hundred sixty five group is supposed to have an owner. Someone who approves members, manages settings, and answers questions when something looks wrong. But owners leave, they change roles. They get promoted, they get laid off. When the account is disabled, the team stays. Now it has members. It has content, it has permissions. But nobody is responsible for any of it. That's an orphaned group. In a large tenant. You don't find a handful. You find hundreds, sometimes thousands, each one a small decision that was never made, like who approves the next person who asks to join? Then there are the guests. Guests are the part that makes security teams go quiet. Someone invites an external partner to a team for a two week project. The project ends. The partners account stays because nobody set an expiration. That person still has access months later, sometimes years later, to files they were never meant to keep seeing. Nobody invited them on purpose to stay. It just never got undone. Here's where it gets measurable. There's one number. Almost nobody checks how many teams have had zero activity in the last ninety days. No messages, no file edits, no meetings, nothing. When administrators finally pulled that report, the result is usually uncomfortable in many tenants. A large share of all teams have been silent for a full quarter, not a few outliers, a real fraction of the whole environment. You can't fix what you've never counted. Most people hear all this and think about storage. Too many sites, too many files, too much cost. But that's the smaller part. Storage is cheap compared to what sprawl actually takes from you. It takes visibility. You can't answer simple questions anymore. Who owns this? Who has access? What's in there? Is it still in use? Is it safe to remove? If you can't answer those, you can't govern. You can only hope. So sprawl is a visibility problem. First, storage comes second. And administrator who can see every team, every owner, every guest and every activity date can make decisions. An administrator looking at a flat list of eight thousand names cannot. That's what makes sprawl so quiet. It doesn't break anything. On day one. Nothing crashes. Nothing alerts. The tenant just gets a little harder to understand every week. Until one day someone asks a simple question and nobody can answer it so we can see the symptoms. Now the duplicates, the ghosts, the ownerless groups, the guests who never left. But symptoms are never the cause. The cause sits one level deeper. Section two. The real cause teams is a front door to Microsoft three hundred sixty five groups. Here's what most people miss. When you click Create Team, you're not creating a chat space. You're creating infrastructure. A team is a Microsoft three hundred sixty five group. That's the object. Underneath the group is the real thing. And teams is one of the ways you look at it. That group doesn't come alone. It brings a SharePoint site where every file in the general channel actually lives. It brings a shared mailbox. So the team has its own email address and its own calendar. It brings a plan, a plan, a one note notebook, a stream folder for meeting recordings, and a membership list that controls access to all of it at once. One click six or seven separate resources, each with its own storage, its own permissions, and its own place in the audit log. Now think about what the user sees a name, a green or purple square, a place to type. That's it. Nobody sees the site collection being provisioned. Nobody sees the mailbox appear in exchange. Nobody sees a new entry land in the directory. So the person creating the team thinks they're starting a conversation. The tenant thinks it just got a new site, a new mailbox, a new permission boundary, and a new pile of data that will need to be backed up, searched, retained, and eventually dealt with that gap is the whole problem. The user is making an infrastructure decision with a chat sized mental model. You can't blame them for that. The interface tells them it's small, so let's redraw what sprawl really is. It's not eight thousand teams, it's eight thousand sites, eight thousand mailboxes, eight thousand membership lists that nobody reviews, eight thousand places where a file can sit with permissions that made sense once and have drifted ever since. Every one of those is a surface, something that can be shared too widely, kept too long, or left open to someone who shouldn't be there. This is where a lot of governance efforts go sideways, and administrators sees the mess in teams and tries to fix it. In teams. They write a policy for channels. They send an email about naming, they build a dashboard of team activity. But the team is just the front door. The real controls sit behind it at the group layer. Who can create a group? What the group is called, who owns it when it expires, what label it carries, whether guests can join. Every one of those settings lives in Microsoft Entra ID in the Microsoft three. Sixty five Admin Center or in the Purview Compliance Portal. Not in teams. Teams reads those settings. It doesn't own them. So if you only govern at the team's layer, you're managing the view and ignoring the object. A user can still create a group from outlook, from planner, from SharePoint, from Viva Engage, or from a forms group or straight through the graph API. Each of those paths ends in the same place. A Microsoft three hundred sixty five group with the same site and the same mailbox, and none of your team's rules applied. That's why a policy that only lives in teams feels like it works for a month and then stops working. The users didn't get around it on purpose. They just used a different door into the same room. So governance has to target the group. That's the layer where every path converges. If a rule applies there, it applies no matter how the team was born. That changes how you think about the whole problem. You're not governing a collaboration app. You're governing the creation of directory objects that happen to come with a chat window attached. The questions are different, not how do we organize conversations, but how do we decide what gets provisioned and who answers for it afterward? Once you see it that way, one thing becomes obvious every team has a moment of creation, a single point in time when the group, the site, the mailbox and the name all come into existence together. After that moment, you're managing something that already exists, already has members, and already holds data. Before that moment, you have complete freedom. This is the shift. Creation is the first control point. It's the one place where a rule costs almost nothing to apply and almost everything to apply later. Section three the old model open creation. Clean up later. Now look at what a brand new tenant does out of the box. Everyone can create a group. Every employee, every contractor with a license, every intern on day one. No approval, no training, no questions. Nothing expires. A group created today is set to live forever unless somebody deletes it by hand. And nothing is labeled. No sensitivity, no classification, no signal about what's inside a team holding salary data looks the same as a team planning a birthday party. Those aren't mistakes. Those are the defaults. Microsoft ships the tenant open on purpose because open means adoption. People start using the product on day one, and nobody files a ticket asking for permission to chat. And for a pilot with fifty people, that works fine. But then the tenant grows five hundred people, five thousand. The defaults don't change because nobody revisits them. They were never a decision. They were just what was there when the tenant switched on. So here's the assumption sitting under this whole approach, let people create freely now, and we'll fix it when it gets better. I've heard that sentence in almost every governance conversation. Sometimes in those exact words. We'll deal with it later. We'll do a clean up project. We'll bring in a consultant when it gets out of hand. It sounds reasonable, even responsible, but it assumes something that isn't true. It assumes that later cleanup will be possible. So let's test that. Say you've decided it's time you open the report and find four thousand teams with no activity in the last year. The plan is simple delete the dead ones. Now someone has to decide which ones are dead, and that's where it stops. Because you don't own those teams. You don't know why they were created. You don't know whether a finance team stores year end files in one of them, or whether legal needs a folder for a case from two years ago. The activity report says nothing happened. It doesn't say nothing matters. So you try to ask the owners, but a big share of them have left. And the teams that still have owners get an email from it saying, is this still needed and what do owners do with that email? They ignore it or they say yes, just in case, because deleting feels risky and keeping costs them nothing. That's the trap. Clean up needs a decision, and every decision has the same shape. The person who can say yes isn't there. The person who's there can't say yes, and the person who can say no. The one who wants it all gone doesn't know what's inside. Nobody owns the decision. Nobody knows what's safe. So the clean up project stalls. It turns into a spreadsheet, the spreadsheet turns into a meeting, and the meeting ends with a promise to review next quarter. Meanwhile, the tenant keeps growing because the creation door never closed. And that's the cost nobody puts on a slide. Governance applied at creation is nearly free. A naming rule takes one. Setting a required owner takes one field, an expiration date takes one policy, and it runs on every new group from that day forward without anyone remembering it. Governance applied afterward is expensive in every direction you pay. For the people who do the investigation, you pay for the meetings. You pay in risk because every group you can't explain is a group you can't defend in an audit, and you pay in trust because when you finally email thousands of owners asking them to justify their teams, you've told them the system was never in control. Same rule two moments. One costs a setting, the other costs a project, and the second one rarely finishes. So the old model isn't broken because people are careless. It's broken because it moves every hard decision to the moment when nobody is able to make it. Which raises the real question if open creation and later cleanup don't work, what does a model look like where the decisions get made early and keep getting made without anyone having to remember. Section four the new model governance as lifecycle, not policy. Here's the shift stop governing teams start governing the life of a team. Because a team isn't a thing that exists at one moment. It's a thing that moves. It gets asked for. It gets built. It gets used, it gets checked, and eventually it ends. Every team in your tenant is somewhere on that path right now, whether anyone is watching or not. So let's name the stages. Request, create, use, review, expire, archive, delete seven stages. That's the whole life request is the moment someone says they need a space and says, why create is when the group, the site and the mailbox come into existence with the right name and the right settings already attached. Use is the long middle where people actually work. Review is the check where somebody confirms the team still matters and still has the right people in it. Expire is the point where time runs out unless someone steps in. Archive is the quiet end for a team that's done but worth keeping. And delete is the real end when the content is no longer needed anywhere. Most organizations govern one of those, usually the first one. If they govern anything at all, they write a naming rule, or they add an approval step and they call it governance. But a rule at one stage leaves six stages open. Here's the second idea, and it's the one that makes this practical. Every control you'll ever configure maps to exactly one stage. A naming policy belongs to create a request. Form belongs to request sensitivity. Labels apply at create and shape how the team behaves during use. Access reviews belong to review. The expiration policy belongs to expire. A retention policy sits behind archive and delete. So when someone asks what does our governance do? You don't answer with a list of settings. You walk the path at this stage, this control. At the next stage that one and the gaps become visible right away. If you can point at four stages, but the other three are blank, you know exactly where the sprawl will come from. Now, the part most people skip a policy is a document. It says what should happen. It lives in a SharePoint library. It gets approved by a committee, and then people are expected to remember it. They won't. Not because they're lazy, because they're busy and the policy is not part of their work. A lifecycle is different. It's a system. The control does the remembering the expiration policy sends the notice on its own. The label applies the settings on its own. The access review lands in the owner's inbox on its own schedule. Whether or not anyone in it thought about it that week. That's the test. If a control only works when a person remembers to do something, it's a habit. If it works when nobody remembers, it's governance and habits fade. Systems don't. So that's what you're building, not a set of rules people have to carry in their heads, but a path that runs by itself from request to delete. But there's a trap here, and it's the one that kills most governance projects. If you build that path as a series of locked doors. People will find another way through. We already saw this with creation. Lock the front and users move to a different tool. The work still has to happen. It just happens somewhere you can't see. So the principle is simple guardrails, not gates. A gate stops you and asks for permission. A guardrail lets you move at full speed and keeps you from going off the edge. The user creates a team and the name is built for them. The label picks the best settings for them. The expiration date is already set. They never hit a wall. They just never get the chance to make the choices that cause sprawl. Gates slow people down. Guardrails shape where they land, and that's the standard for every control in the rest of this episode. Does it work without anyone remembering? Does it keep people moving? If the answer to either is no, it's the old model wearing new clothes. But before you configure a single one of these, there's a question that has to come first. What are you actually trying to achieve? Because every control carries a cost and you can't weigh the cost until you know what it's buying. Section five defining what good looks like before you configure anything. Most governance projects start in the admin center. Someone opens a settings page, finds a toggle and flips it, then another. Within a week there are ten controls running, and nobody can say what any of them was supposed to achieve. So start somewhere else. Start with outcomes. There are five that matter findability security, cost, compliance, and user speed. Findability means a person can look for a team and land on the right one first. Try. No guessing between marketing and marketing. Official security means the people who should see the data can and the people who shouldn't can't. That includes the guest from a project that ended last spring. Cost is storage, licenses and the hours your admins burn. Answering questions about teams nobody understands. Compliance means that when an auditor asks where a record lives and how long you keep it, you have an answer. That doesn't start with, I think. And user speed, this one gets forgotten. It's how fast someone gets a working team when they need one. If that takes three days, every control you build has failed, no matter how clean the reports look. Now here's the uncomfortable part. These five pull against each other. Tighter security slows users down. Faster creation hurts Findability. You will not maximize all five. So you have to pick a balance on purpose. And that raises the next question who picks? There are two common answers. One is a governance board, a group with someone from IT, security, legal, HR and the business. The other is a single owner, one person with the authority to decide and the job of answering for it. Both can work. A board brings the business into the room, which matters because it alone will always lean toward control. But boards are slow. They meet monthly. They argue about wording, and a decision that needs ten minutes takes six weeks. A single owner moves fast, but that person carries every trade off alone. And when they get it wrong, nobody else saw it coming. The pattern that holds up is both. One named owner makes the daily calls a small board, sets the direction and reviews the results. Every quarter, the owner decides how the board decides what matters. Whichever you choose, write down the name. A governance model with no named person is a document, not a decision. Now back to the tension because it's the one that breaks projects control on one side, adoption on the other. Every rule you add tightens the first and risks the second. The trap is measuring only one. If you measure only control, you'll see beautiful numbers, every team labeled, every owner assigned. And you won't notice that people stopped creating teams in your tenant and started sharing files in personal accounts instead. So measure both for control. Count things like teams with two owners, teams with a label, and guests pass their review date for adoption. Count how long a request takes, how many teams get created each week, and how many people complain. If control goes up and adoption falls off a cliff, you built a gate. If both move together, you built a guardrail, but you can't see movement without a starting point. So before you change a single setting, capture a baseline. Total number of teams. How many have zero owners and how many have just one? How many show no activity in ninety days? How many guests exist and how many have never been reviewed? How long it takes today to get a new team. Take the snapshot, save it, date it. Because in six months someone will ask whether any of this worked. And without that first number, the only honest answer is we think so. So you know what you want. You know who decides. You have your starting point. Now the first real control and it's the smallest one. It's the name.

00:17:29 Speaker: Section six naming conventions that people actually follow. A name is the only part of a team that everyone sees before anyone opens a channel, reads a post, or checks the member list. They read the name and they decide in about two seconds whether this is the team they need. So think about where that name shows up in the team's search box. First, someone types budget and gets a list. If the list reads budget, budget, two budget, team and finance stuff, they pick one and hope, but the name travels further than teams. Remember, a team is a group underneath that name also lands an outlook where it becomes an email address. It lands in the global address list. It shows up in SharePoint as a site title and in planner, and in every sharing dialog where someone types a name and waits for a match. So a bad name isn't one problem in one app. It's the same problem in six places, and it costs you in a specific way. When people can't tell teams apart, they stop searching and start creating. That's how the duplicates from earlier get born. So the fix has to happen where the name is made. That fix lives in Microsoft Entra ID and it's called the Group Naming policy. It's a tenant wide rule that shapes every Microsoft three hundred sixty five group name at creation. Not just teams every door. We talked about outlook, planner, SharePoint, all of them. The simplest version is a prefix and a suffix. A prefix goes in front of whatever the user types say. You want every group to start with G, R, P, and a dash. The user types budget review and the system saves GRP budget review. They didn't have to remember anything. The rule did it. A suffix works the same way at the end. It's often used for a region or a year. Now a fixed prefix helps a little, but the real power is in attributes. Instead of typing a static word, the policy can pull values from the user's own profile department, office, country, or region. Company title. So if Maria in finance based in Germany, creates a team called Budget Review, the policy can build find budget review on its own. She typed three words. The tenant added the structure and that's where this gets useful. Now you can sort by department, filter by region, spot every finance team in one search. The name carries context and nobody had to carry it in their head. You can add a project type the same way as a fixed string in the pattern, like p, r for project teams. Just remember the policy builds names from profile data, so it works best when that data is actually clean. If half your users have no department filled in, you'll get names with holes in them. Next, the blocked words list. This is a list of terms nobody can use in a group name. Think CEO, payroll, HR, or legal. Words that could make a casual team look official or expose something sensitive. It's useful, but be honest about what it does. It matches words. It doesn't understand intent. Someone who can't write payroll can write payroll or salaries and walk right past it. And it doesn't stop a team from existing. It only stops one particular spelling. So treat it as a small fence, not a wall. One more constraint and it's the one people forget. Length names get cut off on a phone. You see maybe twenty five characters before the text trails off in the team's rail. The left hand list long names clip even sooner, and if your prefix and attributes eat half the space, the path the user actually typed gets pushed out of view. So here's a test. Read the finished name on your phone. If the meaningful part is hidden, the pattern is too long. Keep the structure short. Two or three letter codes. one or two blocks of context, then room for a real human name, because a perfect naming rule still leaves one thing untouched. It makes sure a team is easy to read. It does nothing about whether that team should exist at all. Section seven naming policy and practice. Set up limits and edge cases. So where does this policy actually live? In the Microsoft Entra Admin center under groups, then naming policy. That's where you set the prefix, the suffix and the blocked words list one policy for the whole tenant. Not one per department, not one per app. And it applies to every Microsoft three hundred sixty five group created by a regular user. That's the part that matters. A person who creates a team in teams, a group in outlook, a plan in planner, or a site in SharePoint hits the same rule, same door underneath, same policy on the way in. But not everyone is a regular user. Some roles are exempt. Global administrators, user administrators, and a few others can create groups with names that ignore the policy completely. And that's by design. Admin sometimes need a name the rule would block. But think about what that means in practice. Your IT team creates teams for the business all day long. If they're exempt, their teams skip the structure. So the very people who should model the convention are the ones who aren't bound by it. The fix is habit, not setting. Have admins follow the pattern by hand or better provision through the request flow will get too soon, so the name gets built the same way for everyone. Now one detail catches people off guard. The policy shapes the display name. It doesn't always show up the same way in every app. In teams, the user sees the full name with the prefix applied in outlook. The same prefix feeds into the email alias. In SharePoint, it lands in the site title. The pattern holds, but you'll notice small differences in how each app shows it. So test with a real account in all three before you announce anything. Next question. What happens to the teams that already exist? Nothing that surprises a lot of admins. The policy only applies when a group is created or when someone renames it later. Your eight thousand existing teams keep their old names exactly as they are. Test two stays. Test two so you have two options. Leave the old names alone and let the new rule apply going forward. Or rename existing groups in bulk with PowerShell or graph after checking each one with its owner. Most organizations pick the first. And that's fine, because the real goal is to stop the bleeding. Old names fade as old teams expire. Renaming thousands of groups by script with no owner sign off tends to cause its own confusion. And one more catch if an owner edits the name of an existing team, the policy kicks in at that moment, so the rule slowly spreads on its own, one rename at a time. Now the failure I see most. It isn't technical, it's cleverness. Someone designs a pattern with six attributes department, region, cost, center, project code, year, and sensitivity. On paper, it's beautiful. Every team name tells a full story and then a real person tries to read it. Fin d e c four four one zero p r two hundred and five conf budget review on a phone that's gone after the second dash in search. Nobody types it and when it breaks because one profile has an empty field, you get names with double dashes and missing blocks. People don't follow rules they can't read, so they work around them. They pick short, vague names and the policy builds an ugly shell around a useless word. So keep the pattern to two blocks, maybe three. If you can't explain it to a new hire in one sentence. Cut something. The name is only the first control, though, and it's the gentlest one because it never says no. The bigger question is the harder one who gets to create a team in the first place. Section eight creation rules. Who should be allowed to create teams? Most conversations about creation start with a fight. One side says lock it down only it creates teams. Every request goes through a central group and nothing appears without a ticket. The other side says leave it open. People know what they need, let them move. And both sides are describing a real fear. Lock it down and you worry about speed. Leave it open and you worry about the eight thousand teams we already walked through. But notice what's happening. The argument assumes there are only two settings open or closed. Everyone or no one. That's a false choice because creation isn't one permission. It's a decision about who gets to skip the line and under what conditions. Once you see it that way, there's a lot of room between the two ends. So let's start with the mechanics of closing the door. In Microsoft Entra ID, there's a group setting called users can create Microsoft three hundred sixty five groups by default. It's on for everyone. You can turn it off, but turning it off completely would stop everyone, including your own admins and the people you actually trust. So Microsoft gives you a narrower option. You create a security group, an entry ID, name it something obvious like team creators, and tell the tenant that only members of that group can create Microsoft three hundred sixty five groups. Everyone else loses the ability. You set that through PowerShell or graph using the directory settings for groups. It's a short script. You point it at the security group, switch creation off for the general population and it takes effect across teams outlook, planner, and SharePoint at once. Same door, same lock, and that's the right place to apply it. Remember the group is the object underneath restricted there and every path is covered. One detail worth knowing members of that security group can create groups. Admins always can. Everyone else sees the option disappear or fail with a message. So you want a clear message ready because the first thing a blocked user does is ask, why can't I make a team? Now here's the problem with using that lock alone. A person who can't create a team still has work to do. A A project still starts on Monday. A client still needs a shared space by Wednesday. So what do they do? They don't give up. They root around you. Someone starts a group chat and keeps adding people. Someone spins up a shared folder in a personal OneDrive. Someone opens a free Slack workspace, or a Google Drive or a WhatsApp group with the whole project crew. And now the work still happens. It's just happening somewhere you can't see, can't label, can't expire and can't audit. That's the cost of a gate. Sprawl inside your tenant is bad, but work outside your tenant is worse because it has no owner, no review, and no policy at all. You traded a visible mess for an invisible one, so blocking creation on its own tends to move the problem. It doesn't remove it. Which brings us to the middle path. Think about who actually needs to create teams often and who needs one. Rarely a project manager might start six teams a year. A sales assistant might need one. A person in finance might never create anything. So split them. For a group of people who've been trained open creation. Give them a short session on owners naming labels and expiration. Then add them to that team creators security group. They know the rules, they get full speed and they stay inside the guardrails for everyone else. A request flow. They ask the system builds the team for them and they don't touch a single setting. No ticket queue. No waiting on an admins calendar. Same outcome. Either way. A team that arrives with a proper name, two owners, a label, and an expiration date already in place. The trained path trusts people who've earned it. The request path protects everyone who hasn't yet. But there's a catch, and it decides whether this works at all. The request path only survives if it's fast. If the trained group gets a team in 10s and everyone else waits three days, you've rebuilt the gate with a polite name. Users will see the difference immediately, and they'll find that Slack workspace anyway. So the question isn't whether to build a request flow, it's whether you can build one that feels as quick as clicking a button. Section nine building a request flow that doesn't feel like a ticket queue. Here's what a bad request flow looks like. A user opens a form with fourteen fields. Half of them ask for things they don't know cost center, data classification, retention class. They guess, submit and get an email that says your request has been received. Then nothing for two days. That's not a flow. That's a ticket queue with a nicer logo. And users learn fast. After one slow request, they stop asking. So build the opposite small, quick, and mostly invisible. The tools are ones you already own. Microsoft forms for the intake power automate for everything that happens after the user clicks submit. If you want a nicer front end, a Power Apps form or a SharePoint list works too. But forms is enough to start, and it's the easiest one to change when you learn something. Now the question that decides everything, what do you actually ask? Five things no more purpose. One or two sentences on what the team is for. This isn't paperwork, it's the single best clue anyone will have in two years when they wonder why the team exists. Owner the person who answers for the team. Usually the requester, but not always. Second owner a named backup will spend a full section on why. But for now, just know the form should refuse to submit without one. Sensitivity a simple drop down with the label choices, internal, confidential and so on. Written in plain words, with one line under each option saying what it means an expected duration. Is this a three month project or one year initiative, or an ongoing department team? That answer feeds the expiration date later. Everything else the system can figure out. The department comes from the user's profile. The naming pattern comes from the policy. The template comes from the purpose. Don't ask a human for something a directory already knows. Now approvals. This is where most flows slow down. There are two kinds automated and human, and the mistake is using human approval for everything. Automated approval means the flow checks rules and decides on its own. Is the requester. A full time employee is the second owner. A different person? Is the sensitivity label one of the standard ones? If all of that checks out, approve instantly and build the team, nobody waits. Human approval means a person reads the request and says yes or no. That's slower and it should be rare. Use it where the risk is real. A request for the highest sensitivity. Label a team that allows external guests from day one, a request from a contractor or one that asks for an unusual template. So the split looks like this low risk, automatic. High risk. A person and that person should be a specific role with a deadline, say one business day and a fallback if they don't answer an approval that sits for a week is a gate again. Think of it as a short list of triggers. If none of them fire, the request goes straight through. Once approved, the flow builds the team and this is the part users never see. Power automate calls the Microsoft Graph API or uses a team's template to create the group with everything already attached. The name built from the pattern. Both owners added the sensitivity label, applied the templates, channels, and tabs in place. The expiration clock started from the duration. They chose one action. The team arrives. Finished. That's why the template matters here. If the flow only creates an empty team, you've pushed all the setup back onto the user. If it creates a team from a template, they open it and start working. Then the last step and it's small. The flow sends the owner a message with a link. Your team is ready, plus two lines on what they're now responsible for. Now the target is simple minutes, not days. A low risk request should land a working team in under five minutes. Test it yourself. Submit a request, start a timer and see how long it takes. If it's longer than a coffee break. Find the step that's slowing you down and remove it. Because speed is the thing that makes people use the front door. If the right way is also the fast way, you don't have to enforce anything. But look at what the flow just demanded. Two owners named before a single message was ever posted. That's not a form field. That's the most important control in the whole life cycle. And a team is only as healthy as the people who answer for it. Section ten ownership. The single most important control. If I had to pick one control only one, it would be this. Not the label, not the template, not the expiration policy ownership. Because go back to the clean up problem from earlier four thousand quiet teams, and nobody who could say whether any of them mattered what was missing in every case. Not a setting, a person, an ownerless team can't be reviewed because nobody receives the review. It can't be renewed because nobody gets the notice. It can't be cleaned up because nobody can say what's inside. Every other control in the life cycle sends its message to the owner. Take the owner away and those messages go nowhere. So Ownerless teams are the root of most cleanup pain. Everything else is a symptom. That's why the request flow refused to submit without a second owner. And that's the first rule. Every team has at least two owners. Always. Why two? Because one owner is a single point of failure that you can't see until it breaks. People leave. They change roles. They go on parental leave for six months, or they just stop paying attention with one owner. Any of those turns the team into an orphan overnight with two. There's still someone home when the first one is gone. Two isn't a perfect number. Larger teams might want three or four, but two is the flaw. And it's the flaw you can actually enforce because the request form can check it, and the report can find every team that falls below it. Now an owner is just a title until you say what the job is and most owners don't know, they clicked create and the role came along with it. So here's the job. In four parts membership, the owner decides who belongs. When someone asks to join, the owner answers when someone changes roles and no longer needs access, the owner removes them. Nobody else in the tenant knows who should be in this team. It certainly doesn't. guess this is the sharpest part of the roll in most tenants owners can invite external people to their teams, and many have never thought of that as a security decision. But it is. Every guest and owner adds, is a person outside your tenant with a window into your data. The owner should know who's in there and why. Review. Every so often, the owner looks at the team and asks a simple question is this still doing its job? Are the right people here? Is the content still needed and expiration when the notice arrives saying the team is about to expire, the owner decides renew it or let it go. That's it for duties, membership, guests review and expiration. None of them takes more than a few minutes, but they only happen if the owner knows they're theirs, which is where most organizations fail. They assign the role and never explain it. Then they act surprised when owners don't behave like owners. So how do you make the duties show up on their own? This is where Microsoft Entra Access reviews come in, and access review is a schedule check. You point it at a group, choose who reviews and set how often. Then entra sends the reviewer a list of members and asks one question per person. Still needs access or not. For teams, you can scope a review to Microsoft three hundred sixty five groups and make the group owners. The reviewers run it quarterly or twice a year and set a default for. When nobody answers. Remove access, keep access, or flag it for follow up. The owner gets an email with a link, clicks through the list, and finishes in a few minutes, and nobody in it had to remember to send it. That's the pattern we talked about earlier. The control does the remembering. The owner just does the deciding one. Caution. Access reviews need the right entry license, so check what your tenant has before you plan around them. And if you roll them out to thousands of owners at once, expect a wave of confused emails. Say what's coming before it lands will come back to that when we talk about communication. But even a perfect review has a limit. It only works while the owner is still there. The email goes to a mailbox. The mailbox belongs to a person and people don't stay forever. So what happens to a team the day its owner walks out the door? Section eleven orphaned teams and owner succession. Here's what usually happens. An employee leaves, HR closes the record. It disables the account, everyone considers the offboarding done, and nobody checks what that person owned. That account was the owner of three teams. Two of them had no second owner. The moment the account went dark, those two teams became orphans, members files and no one who can approve a request or answer a question. So the first job is detection. You can't fix what you can't list. The list you want is simple. Every team with one owner and every team with zero zero is the emergency. One is the warning because it's one resignation away from zero. You can pull this with PowerShell or the graph API query. The Microsoft three hundred sixty five groups, expand the owners and count them. Anything under two goes on the report in the Microsoft three. Sixty five Admin Center. You'll also find a view of groups without an owner, which is a decent place to start. If scripts aren't your thing, run that report weekly, not once weekly, because this list refills on its own every time somebody quits. Now detection is for admins, but the people who feel an orphaned team first are the members. They're the ones who ask to join and hear nothing back. They're the ones who see a guest show up and can't ask anyone why. So tell them when a team drops to zero owners, an automated notice goes to the members. Plain words this team has no owner right now. Here's who is looking after it and here's what to do if you want to take the role. Power automate can send that. It watches the report, finds the new orphan and writes to the members. And here's a small trick that works well. Ask members to volunteer in a team of forty people. There's almost always someone willing to step up. You've turned a gap into a recruiting message, but you can't rely on volunteers alone. Some teams are small, quiet, or full of people who'd rather not. So you need a rule for what happens when nobody raises a hand. That rule is a chain of fallbacks decided in advance, written down first, the departing owner's manager. They know the work and they usually know who took over the role. Second, the department lead. If the manager is gone too. And third it as the last resort, holding the team only until a real owner is found that order matters. It should be last, not first. If it becomes the default owner for every orphan. You've recreated the old problem with a new name four hundred teams that your admins own and know nothing about fall back to. It means temporary custody with a deadline and a flag on the team, so someone pushes to hand it off. You can build this into the same flow. When a team drops to zero owners, the flow looks up the last owner's manager through entry ID, adds that person as owner and sends them a message explaining why if the manager is missing, it moves to the next step. No meeting, no ticket. But the best fix happens earlier. Don't wait for the account to go dark. Put a check inside Offboarding itself. When HR starts a leaver process, a workflow lists every team that person owns. For each one, it asks one question is there another owner? If yes, fine. If not, the departing person or their manager has to name a successor before the account can be disabled. That's a guardrail, not a gate. It adds a few minutes to an exit that already takes hours, and it stops the orphan from ever being born. Think about the difference. One version finds the problem six months later in a report. The other version never lets it exist, and that's the pattern for the whole life cycle. Catch it at the moment of change. So now every team has people answering for it and a plan for when they leave. But a team with a healthy owner can still outlive its purpose by years. Ownership tells you who decides. It doesn't tell you when.

00:37:01 Speaker: Expiration policies, giving teams a lifespan. Every team in your tenant is set to live forever. That's the default. No end date, no check in, no moment where anyone has to say yes. Keep this. A team made in twenty nineteen for a one week workshop is still sitting there with members, with files, and with a mailbox. The Microsoft three hundred sixty five Group expiration policy changes that it's a tenant wide setting in Microsoft Entry ID, and it does one simple thing it gives every group a lifespan, and when the lifespan runs out, the group gets deleted. Unless somebody steps in, you find it in the entry admin center under groups, then expiration. You choose a lifetime. In days. You choose who gets the notices. If a group has no owner and you choose whether the policy covers all Microsoft three hundred sixty five groups, only selected ones or none, remember what a team is underneath. This policy hits the group so the team, the site and the mailbox all go together. Now how does it actually work? The clock starts when the group is created. As the end date gets close, entry emails the owners and the notice isn't a one time thing. It goes out at thirty days before expiration, then again at fifteen days, then once more at one day. Each email has a single button renew group one click and the clock resets to a full lifetime. No form, no approval. No ticket. The owner proves the team is still wanted by clicking a link. That's the whole design, and it's smarter than it looks. It flips the burden. Before someone had to prove a team was dead before it could go. Now someone has to prove it's alive before it can stay. And that solves the problem from the clean up story. Remember, nobody wanted to say delete this because deleting felt risky and keeping costs nothing. Expiration moves the decision to the one person who knows the answer at a moment they can't ignore. So what period do you pick? Most tenants land on one hundred eighty or three hundred sixty five days, and the choice is about rhythm, not math. At three hundred sixty five days, an owner hears from the system once a year. That's light and it fits a tenant where most teams are long running departments. But a team that died in month two still sits there for ten more months at one hundred and eighty days. Owners hear from you twice a year. Dead teams clear out faster, and the notices stay frequent enough that people remember what they mean. The cost is a little more noise. If you're not sure, start at three sixty five. You can shorten it later and shortening is easy to explain. Lengthening after you've trained people to expect notices is harder. One setting to watch the policy has a field for who gets the email when a group has no owner. Put a real mailbox there, one that somebody reads. Otherwise, the notices for your orphaned teams go to a place where nobody sees them. Now the fear that stops most admins. What if someone ignores the email and the team disappears? It doesn't disappear. Not right away. When a group expires, it's soft deleted. It moves into a recycle bin in entra and it stays there for thirty days. During that window, an admin or the owner can restore it. The group comes back with its members, its site, its mailbox, and its files as if nothing happened. After thirty days, it's gone for good. So the real safety net is a month long. Between the first notice and the final deletion, an owner gets about sixty days of warning plus a thirty day grace period after. That's a lot of chances to say, wait, that's mine. And here's what that does to people. It changes behavior before expiration. An owner has no reason to think about a team. After the first week after expiration, the owner gets a message with a date on it. They have to look at the team and ask, do we still use this? Is anyone in here? Should I really keep paying for it? Some say yes and click renew. Some realize the project ended eight months ago and let it go. Either way, someone made a decision. That's what you couldn't get from a clean up project. The owners start to care because the system keeps asking. But there's a flaw in this and it shows up fast. A team in daily use gets the same email as a team nobody has touched in a year. Both owners get the same button and both owners have to click it. So the question becomes can the system tell the difference without asking? Using activity to drive exploration decisions. Yes, the system can tell the difference. It's a setting inside the exploration policy and most admins never notice it. When a group gets close to its end date, Microsoft checks whether anyone has been using it. If the group shows real activity, the policy renews it automatically. No email, no button. The owner never hears about it because there was nothing to decide. And that's the right outcome. A team that's busy every day shouldn't ask its owner to prove it's alive. The traffic already proves it. So what counts as activity for places? Mainly teams where people post in channels or join meetings. SharePoint where someone opens, edits, or uploads files in the team's site. Outlook where the group mailbox gets conversations and Viva engage the product that used to be called Yammer, where the group has a community. Think about what this does to the notices before every owner got the same email. Busy or not. Now only the quiet teams get one. The owners who do hear from the system are the ones who should be asked. That's a much better signal. The email stops being background noise and starts meaning something. But here's where it gets uneven. Those four workloads aren't treated the same. Microsoft's renewal logic looks at specific actions in each one, and it doesn't cover every kind of work. A team that lives mostly in chat, for example, may look quieter to the policy than it does to the people inside it, and a team where people only read files and never edit or upload can look like it's doing nothing at all. So you get false negatives. A team that is working fine gets flagged anyway, and the owner receives a notice for something that was never dying. You also get the reverse. A group with a little stray activity, a single mailbox message, or one old file touched by a sync tool can renew itself again and again. It looks alive in the data while nobody actually cares about it. So activity is a hint, not a verdict. Which is why the cleanest approach combines two things reports and owners. Start with the reports in the Microsoft three. Sixty five Admin Center and Teams Admin Center. You can see last activity dates by team and by site. Pull those through PowerShell or graph into a list. Sort by the quietest. Then for the edge cases, ask the owner teams that look inactive but have an active owner. Teams that are quiet but hold something sensitive. Teams that sit right at the threshold. For those, a short message with a clear question works better than a silent deletion. Still needed. Yes or no. The report finds the candidates. The owner confirms neither one decides alone. Now some teams break the pattern on purpose. Take a seasonal team, a tax preparation group that's dead for nine months, then wakes up every spring or a budget planning team that only matters in the fourth quarter. By activity alone, those look abandoned and an expiration cycle will catch them in the middle of their quiet stretch. Project teams have the opposite problem. They start loud, run hot for a few months, then stop the day the project ends. Nobody tells the system. The team just goes silent and then sits there until the next expiration notice. So give these two kinds a different path for seasonal teams, set a longer lifetime or have the owner renew on purpose before the quiet stretch begins. For project teams, use the duration from the request form. If someone said three months at the start, that date becomes the checkpoint. Same life cycle, different clock. But all of this assumes the answer is binary. Keep the team or lose it and plenty of teams don't fit either box. The work is finished, the people have moved on, but somebody someday will want to look at what was decided. So what do you do with a team that's done but not disposable archive versus delete? Choosing the right end state. Most owners think there are two options keep it or kill it. There's a third one, and it's built into teams. It's called archiving. Here's what it does. When an owner archives a team, the team goes read. Only people can still open it. They can scroll through the channels, read old posts, and look at the files. But nobody can post, reply, edit, or add anything new. The conversation stops and the owner keeps a little more control than everyone else. Owners can still manage membership and bring the team back to life later with one click on the Unarchive button. Now the part people get wrong. Archiving doesn't hide the team from search and it doesn't make it disappear. It moves it to a separate list in the teams client out of the way, but still there. Also worth knowing the SharePoint site doesn't lock down in the same way you might expect. The site stays, the content stays, everything remains exactly where it was, and it still counts toward your storage. So archiving is a quiet end, not a cheap one. You've stopped the activity. You haven't removed the footprint. That makes it the right answer for one kind of team. The work is done. The people have moved on, but somebody might need to look back. A finished client engagement, a project with decisions people will want to check next year. A team that holds a record delete is different, and it's more forgiving than most owners think, but only for a short while. When a team is deleted, the group goes into that recycle bin we talked about, and it stays recoverable for thirty days. In that window, an admin can restore it. The members, the site and the files all come back after thirty days. It's gone. Not hidden. Gone. So delete fits a team that has nothing worth keeping. A test team a duplicate, a short project where everything useful already lives somewhere else. But here's the problem. An owner clicking delete is making a decision about data they may not fully understand, and a missed email, an old file with a contract in it, or a chat that turns out to matter during an investigation. None of that shows up on the button. So who protects the organization from a bad call? Not the owner. Not archive either. The real safety net sits underneath both of them. Retention policies. These live in Microsoft purview, and they work on the content itself, not on the team. You can say that teams channel messages are kept for seven years, or that files in these sites are held for three. And if a retention policy applies, deleting the team doesn't remove the content. The data is preserved in the background even though the team has gone from view. Then there's legal hold when a legal or compliance team places a hold on a person or a site, nothing in scope can be permanently deleted until the hold is lifted. It doesn't matter what an owner clicks, it doesn't matter when the expiration policy fires. That's the point. Archive and delete are the owner's choices, retention and hold are the organizations choices, and the second set has to sit behind the first because owners will sometimes be wrong. So how do you make the owners choice? Simple. Give them a short decision tree. Three questions in order. First, will anyone ever need to read this again? If no and nothing in it matters, delete. Second. If yes, does it need to keep changing? If people still need to post and work in it, don't end it at all. Renew it. Third if it's finished, but worth keeping, archive it. That's the whole tree. Delete, renew or archive. And if the owner isn't sure, the default is archive because it can be undone and the content stays protected, put that on one page, link it from the expiration notice so it arrives. At the moment the owner needs it because the teams inside story is now covered owners naming expiration and the end state. But a team has an outside edge too, and the people standing on that edge don't work for you. Guest access designing for collaboration. Without exposure. A guest is someone you didn't hire on a device you don't manage with an email address you don't control, and that person can sit inside your team. So think about what a guest actually sees. They can read channel conversations, they can open files in the team site, they can see the member list. And in many tenants they can see who else is in the chat. Every guest is a window into your data held open by someone outside your walls that makes guests the highest risk surface in a team's tenant. Not because guests are careless. Most are perfectly fine. The risk comes from the model. Their account lives in another organization when they leave that company or get phished or reuse a password, you don't hear about it. Your tenant keeps trusting an identity that you can't see and the exposure grows quietly. One guest here. Three there a vendor for a project that ended. An agency that was replaced. Nobody invited them on purpose to stay forever. They just never left. So before the controls, the plumbing, how does a guest actually get in through Microsoft Entra B2B collaboration? When someone invites an outside person, entra creates a guest object in your directory. It's a small record that points back to the person's own account, whether that's a work email at another company, a Microsoft account, or a one time passcode sent to their inbox, the guest signs in with their own credentials. You don't create a password, you don't manage their account, But you do own the guest object, which means you can assign it access, put it in groups, apply conditional access, and remove it. That last part matters. You can't govern the person. You can govern the object. Now the settings and this is where admins get lost. Because guest access isn't one switch, it's three layers and each one can overrule the one above it. The first layer is the tenant. This is the master setting in the admin center. Under external collaboration settings, you decide whether guests can be invited at all and what they can see in your directory in the Microsoft three. Sixty five Admin Center. You also choose whether guest access in teams is turned on. If the tenant says no, nothing below it matters. The second layer is the team. Inside teams, an owner can allow or block guests for that one team. Same tenant, different choice. A team for internal finance can say no guests while the one next door shares freely. The third layer is the label. A sensitivity label applied to the team can control guest access to confidential teams can block external members entirely no matter what the owner prefers. We'll come back to labels in a later section, but notice where it sits. The label overrides the owner's choice because the organization decided that before the owner arrived. So the order is simple. Tenant sets the outer limit label. Sets the rule for a class of teams. The team owner works inside what's left? One catch. These layers only protect you if they agree with each other. A tenant that allows everything with labels that block nothing, and owners who invite whoever they like. Has three layers and no control. Now the question that sits at the center of all of it. Who is allowed to invite? By default? Almost everyone. Members can invite guests. Owners can invite guests. Even guests can invite other guests. In some configurations. It's the most open setting Microsoft ships because it makes collaboration easy on day one. But think about what everyone means eight thousand people, each able to add an outsider to any team they belong to, with no record of why that's not a policy. That's a hope. In entra, you can narrow it, limit invitations to admins and users in the guest, invite a role, or limit them to members of specific groups, or allow owners only. So the person who answers for the team also answers for who joins it. Most organizations land on that last one. Owners invite members don't and guests never invite anyone. It keeps the decision with the person who knows the context. But setting who can invite is the easy part. A single click adds a guest in under a minute. The hard part starts the day after guest life cycle reviews expiration and cleanup. A guest account has no end date. You invite someone for a three week project. The project ends, the person never signs in again, and the account stays in your directory for years with its access exactly as wide as the day it was created. So the life cycle for guests needs its own clock. Start with access reviews. We used them for owners and members. They work for guests too, and this is where they earn their license cost. You scope a review to guest users across your Microsoft three hundred sixty five groups, set it to repeat every quarter or every six months and choose who answers. Usually that's the team owner. Sometimes it's the guests sponsor the internal person who invited them. Each reviewer gets a list name company last sign in one question per person still needs access. And here's the setting that makes it work. The default. When nobody answers, set it to remove access, not keep. If the reviewer ignores the email, the guest loses access automatically. That one choice turns a polite request into a real control because silence now has a consequence. Entry can also help the reviewer decide. It shows when the guest last signed in, so an owner can see that a vendor contact hasn't touched the team in eleven months. That's usually enough to click remove without a second thought. Reviews take care of access inside one team, but the guest object itself is a separate problem. Remove a guest from every team and the account still sits in your directory. It can still be added to the next team by someone in a hurry. So you want the object to go to enter has a feature for this. In the access review settings, when a guest is denied access in a review, you can choose to block them from signing in and then delete the account after a set number of days. Thirty is common. The guest gets blocked first, so if you made a mistake, you can reverse it. Then the account is removed for good. What does deletion actually remove the guest object, their group memberships, and their access to anything shared through those groups. What it doesn't remove is the content they created, messages and files they posted stay in the team tied to a name that now shows as deleted. That's worth knowing before someone asks where a vendor's documents went. Now a different layer controlling which organizations can send you guests at all. In the external collaboration settings, you can set a domain allow list or a block list. They work in opposite directions and you pick one. A block list says anyone can be invited except these domains competitors, known bad actors. It's easy to start, but it's a list you'll maintain forever because the internet keeps adding new domains and allow list says only these domains can be invited. Your partners, your key suppliers, your agencies, everyone else gets refused at the invitation step. It takes more work up front, but it shrinks the exposure to a set of organizations you can name for a regulated business. The allow list is usually the better fit for an open project heavy one. A block list may be all you can sustain. Either way, a list of any kind beats no list. The last control sits at sign in conditional access, you can write a policy that targets guest and external users specifically. Then you decide what they must do before they get in. The most common rule is multi-factor authentication. A guest from another company has to prove it's really them. Every time you ask, no matter how their home tenant is set up. You can also require that guests accept your terms of use. It's a short document shown at first sign in that says what they may and may not do with your data. It sounds like paperwork, but it creates a record. And for some industries that record matters at device and location conditions, if you need them, a guest signing in from an unmanaged laptop might get web only access with no downloads. So now guests have reviews, expiry domain rules, and sign in checks for controls. One life cycle. But guests are only one way to let outsiders in. Microsoft has built another, and it doesn't use guest accounts at all. External collaboration models, guests, shared channels, and federation. Most admins think external collaboration means one thing a guest account. It doesn't. Microsoft gives you three different models, and each one makes a different promise about who you trust and what they can see. Start with the one we just covered the guest account. A guest gets an object in your directory. They sign into your tenant, and they're added to a team like any other member. That means they see everything in that team, every standard channel, every file in the site, the member list, the guest lives inside your boundary as a visitor with a badge that fits long running work with a small set of outside people, a consultant embedded in a project for six months. An agency that works in your team. Every day you get full collaboration, and you also get a full directory object to review, expire, and clean up. The second model is the shared channel with B2B Direct Connect here. Nobody becomes a guest. The outside person stays in their own tenant, signs in with their own account, and the shared channel shows up in their team's client next to their own teams. They don't get access to the parent team. They see one channel and only that channel. The files live in a separate SharePoint site tied to the channel, so the exposure is narrow. One channel, not a whole team. And there's no guest object in your directory to forget about because the trust sits between two organizations rather than one person that fits a standing relationship with a partner you know well, a joint venture, a key supplier, a sister company. Both sides agree to trust each other, and then people on both sides can be added to channels without an invitation for each one. The third model is external access, sometimes called federation. This one is the lightest. It lets people in your tenant chat and call people in another organization using each other's real accounts. No guest. No shared space. Just one to one chats, small group chats and meetings. What does it expose? Whatever somebody types or pastes into that chat. There's no team, no channel, and no site in play. That makes it good for quick contact and a poor home for anything that needs a record, a label, or an expiration date. Chats like this sit outside the structure we've been building. So here's the comparison in one pass. Guest accounts give wide access to a team and they create a directory object. Shared channels give narrow access to one channel and they create a trust between tenants. External access gives conversation only and it creates nothing to govern at all. That last part isn't a benefit, it's a gap. Now, where do you control all of this in Microsoft Entra? Under external identities in the cross tenant access settings, that's the control panel. It has two parts default settings which apply to every outside organization and organisational settings, where you overwrite the defaults for one named tenant. Inside each, you set inbound and outbound rules. Inbound controls what outside people can do in your tenant. Outbound controls what your people can do in theirs. And for B2B Direct Connect, both sides have to switch it on if your partner allows it and you don't, nothing happens. So the practical pattern is simple keep the defaults tight. Then open specific doors for specific partners, one at a time by name, and you can go further. Trust settings let you accept the other tenants multi-factor check and device compliance so their users don't get prompted twice. Which brings us to the real point. Nothing here is a feature choice. Each model decides how much of your data leaves, who watches the door, and what's left to clean up later. Choosing shared channels over guests is a decision about exposure. Allowing Federation is a decision about records. Those are governance questions, and they belong to the people who answer for risk, not to whoever clicked the invite button first. So set the model first, then the team gets built around it and inside that team. The next decision is smaller, but it shapes how everything else behaves, how the channels are laid out.

00:56:31 Speaker: The channel design structure that prevents chaos. A team without channel rules turns into a hallway with forty doors. Nobody knows which one to open, so they post in general, or they make a new channel for every topic that crosses their mind. A year later, you have a team with sixty channels and half of them hold three messages. Channels are where sprawl hides inside a team. It's the same problem one level down. So start with what you can choose from. Teams gives you three kinds standard channels. These are the default. Everyone in the team can see them and every file lands in a folder inside the teams main SharePoint site. One team, one site, many folders, private channels. Only invited members can see these even if they belong to the team. They're meant for a smaller group that needs a closed conversation, like a leadership circle or a sensitive workstream. Shared channels these can include people from outside the team and even outside your tenant through B2B Direct Connect, which we covered a moment ago. The channel stands on its own, and the people in it don't need to join the parent team. Now, here's the part that surprises admins. A private channel isn't just a closed room, it creates its own SharePoint site. Same for a shared channel, a separate site with its own permissions, its own storage, and its own list of members. So every private channel adds an object that sits outside the team's main site. Different access, different owners in practice, and often nobody watching it. Ten private channels in a team means ten more sites to inventory, review and label. That's governance load. It doesn't show up on the day somebody clicks new channel, it shows up two years later. When you try to answer a simple question who can see what? And the answer lives in a dozen places. And there's a second catch. A private channel can have its own owners and members, so a person can lose track of access that sits underneath the team. The team owner may not even see everyone in there. So treat private channels as an exception. Use one when the audience is truly smaller and the content truly needs a wall, don't use one because it feels tidier. Now how many channels is too many? Microsoft allows up to two hundred standard channels per team and thirty private channels. Those are technical limits, not guidance. Nobody should aim for them. A workable rule is far smaller keep standard channels to somewhere between five and ten. Keep private channels to a few and ask for a reason. Each time. Past that, people stop checking the channel list. They stop knowing where things go, conversations scatter and the search bar becomes the only navigation anyone trusts. There's a cost to files to every channel gets its own folder. More channels means more places a document might live, and more chances that the right version sits in the wrong one. So when do you add a channel and when do you build another team? Think about who needs to be in the room. A channel is a topic inside a group of people who already belong together. A new team is a new group of people with a different purpose. If the same members work on the same goal and you just need a place for a topic like budget planning or launch tasks, add a channel if the members differ or the lifespan differs or the sensitivity differs. Build another team. A project that has its own end date deserves its own exploration clock. A work stream that includes outside partners probably deserves its own guest rules. Stuffing those into a channel hides the difference instead of governing it. A quick test would you want this to expire separately? Would you label it differently? If yes to either it's a team. Next, naming channels don't get an entry naming policy, so a short pattern has to come from you. Keep names plain. And about the work budget, launch plan, client questions, skip dates, initials and versions, and don't repeat the team name inside the channel name because it's already on screen. Then give general a job. By default. It's the catch all and it fills with everything. Instead, make it the place for announcements, team wide notices, and pinned links. One line in the channel description says so work conversations go to the topic channels. None of this is hard on paper. The trouble is getting one hundred owners to follow it every time from memory. So stop relying on memory. Build the structure in once and let every new team start with it. Team templates making the right way, the easy way. A template is a team that already exists in your head saved so it can be built again. That's the whole idea. Instead of asking one hundred owners to remember your channel rules, you build the structure. Once every new team starts from it, the owner doesn't follow the standard, they just open the team and the standard is already there. Teams gives you two kinds. The first are built in templates. Microsoft ships a set of them covering things like onboarding employees, managing a project, managing an event, or running a store. They're a decent start. They show you what a template can hold, and you can create a team from one in a few clicks. But they're generic. They don't know your naming habits, your departments, or the apps your people actually use. A built in project template doesn't know that your projects always need a budget channel and a risk log, so most organizations use them as examples, then build their own. The second kind are custom templates. You make them in the teams admin center, and you can start from scratch from a built in template or from a team you already have. That last option is the quickest. Take a team that's well run, copy its shape and turn it into something others can reuse. So what does a template actually carry? Four things. Channels with their names and descriptions already written. Tabs. So a planner board or a pinned document library is waiting in the right channel. Apps installed and ready and settings like who can create channels where the members can add apps and how messages and mentions behave. Think about what that removes. No more empty general channel and a blank screen. No more asking the owner to set permissions they don't understand. The team opens the way you decided it should before anyone clicked anything. One limit to know a template doesn't set the label or the guest rules, and it doesn't create the expiration clock. Those come from other controls. This is also why the request flow from earlier matters. The flow picks the template applies. The label adds both owners and starts the clock all in one action. The template is one piece of that build, not all of it. Now which templates do you make? Start from the work people actually do. Three use cases cover most tenants a project template channels for planning tasks and status, a planner tab, a short description in each channel so new members know where things go. This one fits any work with a start and an end, which means it pairs well with the duration question on the request form a department template, channels for announcements, daily work, and one or two standing topics. Fewer tabs because departments live longer and change slower. This is the team that gets renewed for years. A client engagement template, channels for delivery, internal discussion and client facing updates built with outside people in mind. So the settings expect guests or a shared channel from the start. The owner doesn't have to remember to be careful. The structure already is. Notice what these three do. They map to the way people describe their own work. Nobody asks for a collaboration workspace with a standard governance profile. They say I'm starting a project. The template matches the sentence. Now the temptation. Once templates work, everyone wants one. Every team lead asks for a version tuned to their group. Finance wants one, legal wants one. The marketing manager wants one with six extra channels within a year. You have forty templates and you've rebuilt the sprawl problem inside your catalog. So hold the line. Keep the catalog small. Five to eight templates is plenty for most organizations. If a request doesn't fit one of them, the answer isn't a new template. It's a closer look at whether the request is really different or just a preference. Small catalogs also stay accurate. You can review eight templates in an afternoon forty nobody reviews. Which raises the last question who owns them? Every template needs a named owner, a person, or a small group who answers for it, not it by default, someone who understands the work it supports. A project office owns the project template. HR owns onboarding and changes need a path. When someone wants a new channel in the standard project template, they ask the owner. The owner decides and the change is tested on a trial team. First, edit a live template carelessly and every future team inherits the mistake. Version it, date it, and keep a note of what changed. Now templates settle the shape of a team channels, tabs, apps, structure. What they don't settle is how well that team is protected. A perfectly built team can still hold the wrong data in the wrong hands. Templates set structure labels set protection sensitivity labels governing the container, not just the file. Most people hear sensitivity label and think of a document, a stamp on a spreadsheet, a footer on a contract, maybe a bit of encryption on a file that shouldn't leave the building. That's real and it works. But it's only half of what labels can do. There are two kinds file labels, which protect the content inside a document or an email, and container labels which protect the place where the content lives. In our case, the team, the Microsoft three hundred sixty five group behind it and the SharePoint site underneath. The difference matters. And here's why. A file label travels with the file. A container label sets the rules for the room. It doesn't care what's in any one document. It cares who gets to walk in, who they can bring, and what device they're holding when they do. So when you label a team as confidential, you're not marking a file. You're deciding what kind of team this is allowed to be. What does a container label control for things? Mainly privacy. Is the team public where anyone in the tenant can find it and join or private where an owner has to approve each person, the label can force one or the other. So an owner can't flip a confidential team to public by accident. Guest access can people outside the tenant be added at all? A label can say yes, or it can say no for good. And remember the three layers from the guest section. The label sits above the owner's choice. If the label says no guests, the owner can't override it with a checkbox. Unmanaged device access. Someone opens the team from a laptop you've never seen. A label can hand that person full access. A limited web only view with no downloads or block them. This one works together with conditional access and will connect those two shortly. External sharing Can files in the team's site be shared with people outside? Anyone with a link, only existing guests or nobody. The label sets the ceiling for the site for settings one decision. At the moment the team is born. Now, a label doesn't do any of this until you switch the feature on, and this part trips up a lot of admins. By default, labels don't apply to groups and sites. You have to enable them in Microsoft Entra as a setting on the tenant, and then publish the labels from Microsoft Purview in the label's own configuration, you choose the scope. That means turning on the option for groups and sites, which is a separate choice from files and emails. Missed that step, and the label never shows up in the team creation screen. There's a sync step in the middle, too. Once you've set it up, the labels need time to appear, so don't test five minutes after publishing and conclude it's broken. And one more detail labels on groups and sites can't be applied to the team through the same tools as file labels. You're working with the container side of purview, so check the scope before you build anything. Now, how many labels do you make? Fewer than you want to. A small set works best, and a four level model covers most organizations public. Internal. confidential, highly confidential public is open to the tenant and guests are fine. Think of a company wide interest group. Internal is private by default, with guests allowed only through the owner. Confidential blocks guests and limits unmanaged devices and highly confidential locks it all down with no external sharing, no guests and managed devices. Only four names that anyone can say out loud and understand. Notice that each one maps to a clear change in rules, not a vague feeling about how sensitive something is. That last point matters more than it seems. If two labels do almost the same thing, users can't tell them apart and they'll pick whichever one is quickest to click. And that's the real risk here, not the settings, the people choosing them. You can build a perfect label set in purview, publish it, and still end up with every team marked internal because nobody understood. The other three labels only work when users understand them. Labeling in practice, defaults, mandatory choices, and adoption. The best time to ask for a label is the moment the team is created, not after, not in a clean up project next spring at creation, when the owner is already making choices about a name and a purpose. And one more question costs them five seconds. That's the design. When someone creates a team, a drop down appears with your labels and each one has a short description. The owner picks one and the privacy guest and sharing rules attached to the team before the first message gets posted. If you built the request flow from earlier, the label is simply one more field on that form. Same moment, same decision and you can make it mandatory. In the label policy, you require a label for groups and sites. Nobody finishes creating a team without choosing one. Now the dropdown has a default and the default does more than you'd expect. Most people don't read the list. They accept what's already selected. So whatever you preselect becomes what most of your tenant gets without anyone thinking about it. That cuts both ways. Default to internal and. Most teams land in a sensible middle. Private guests through the owner. Normal sharing default to public and you've quietly opened every team that nobody paid attention to. And with no default at all, owners tend to pick the first item or the lowest friction one. So choose the default like it's a policy because it is one pick the label you be comfortable seeing on seventy percent of your teams and set that, but that only covers teams made from now on. What about the ones already there in a mature tenant? That's thousands of teams with no label at all, each running on whatever the owner chose years ago. You can't label them all by hand, so work in order. Start with a report of unlabeled teams sorted by what they hold and who's in them. Teams with guests come first. Teams with a lot of members come next, then apply a baseline label in bulk using PowerShell or graph to the teams you can safely say are ordinary. For the rest, ask the owners a short message with a clear question and a deadline. And remember, a label applied to a team with guests might change what those guests can do, so check before you push it. The bulk step should never break somebody. Monday. One more thing about scale label policies. Decide which labels each person sees. You can scope a policy to a group so legal sees an extra label and everyone else sees the standard four. That's useful. It's also where people overdo it. Every group gets its own version, and then you have a label set for finance, another for engineering, another for the regional office within a year. Nobody can say what confidential means because it means something different in each place. Keep it to one standard set. Add a scoped label only when a group has a rule the standard set can't express. And when you do, name it for what it changes, not for who gets it. Because here's what a label really is. It's one control on one layer, but a label that blocks guests does nothing for a chat message. A label that limits devices needs something to enforce it, and a label that says confidential doesn't decide how long anything is kept. The label names the class, other controls act on it. Connecting controls, retention, DLP, and conditional access. Start with what a label can't do. It can't keep a message for seven years. It can't stop someone from pasting a credit card number into a channel, and it can't check whether the laptop in front of the user is one. You manage. Three other controls handle that retention, data loss prevention, and conditional access. Each one acts on a different thing, and each one waits for the label to tell it what kind of team it's looking at. Retention first. This lives in Microsoft purview and in teams. It splits in two one policy covers channel messages, another covers chats meaning one to one and group conversations. Their separate locations. So you set them separately and a lot of tenants set one and forget the other. What does a policy do? You pick a period and you pick the action. Keep for seven years, then delete, keep forever or delete after two years with no keep at all. Behind the scenes, the messages are copied into a hidden folder in a mailbox, and they stay there for the period you chose. Even if a user deletes the original. This is the safety net from the archive and delete section. Now with a name. If an owner deletes a team on a bad day, the retention policy still holds what it was told to hold. The owner chose to remove the team. The organization chose what to keep. Those are two different decisions made by two different people, and only one of them is allowed to be careless now. Data loss prevention DLP policies for teams. Watch the content as it's written. You define what you care about credit card numbers, national ID numbers, health terms, or a custom pattern of your own. Then you define what happens when someone shares it. The system can warn the sender with a policy tip. It can block the message from being seen in chats and channels. A blocked message shows the sender a notice and the people on the other end see nothing useful. It also applies to files shared in teams since those sit in SharePoint and OneDrive. Here's where the label comes in. A DLP rule can be scoped by sensitivity label. Say a team is labeled highly confidential and someone shares a file with a guest. The rule can block it outright. For an internal team, the same action might only trigger a warning. One policy different strength because the container already told you how careful to be. Same idea with the third control. And this one is the one that closes the door on bad devices. Conditional access works at sign in. It asks who is this? What are they using and where are they? And it can answer with yes, yes, with limits or no. Remember the unmanaged device setting from the label? The label sets the intent. Conditional access enforces it. A confidential team can say that unmanaged devices get web only access with no downloads, no printing, and no sync. Conditional access reads that instruction through an authentication context tied to the label, and applies the right session rules when the user opens the site, so a person on a managed laptop opens the team and works normally. The same person on a borrowed tablet, opens it and can read but can't take anything with them. Same person, same team. Different device state. Different outcome. Now put these three back on the life cycle map from earlier request. Create. Use review. Expire. Archive. Delete at create. The label lands. That's where the container gets its class. During use, DLP watches the content and conditional access. Watches the sign in at review access reviews. Check who's inside at expire and archive. The teams life ends in the way the owner chose and through the whole run in the background, retention decides what survives at the end. So every control has a stage. Nothing floats free. And that's what makes the set a system rather than a pile of settings. But a system you can't see is just a set of promises. Policies exist, labels are applied, notices go out. Is any of it actually working? Monitoring and reporting? Seeing the tenant honestly start with what Microsoft already gives you for free. The teams admin center has a report. Section two of the matter here. Teams usage, which shows active users, active channels and messages by team and teams. User activity which shows who's posting, calling and joining meetings. Open the usage report and sort by the quietest. That list is your first draft of a clean up queue, but keep one limit in mind. These reports show activity. They don't show ownership, labels or guests. A team can look healthy in the usage report and have no owner at all. So go one layer down. The Microsoft three hundred sixty five admin center has its own reports, and the useful ones sit under group and site activity. Here you see last activity by group, by mailbox, and by SharePoint site. Remember that a team is a group with a site behind it. A team can be silent in chat while people work in the files every day. Only the site report shows that. Read the two together quiet in teams and quiet in SharePoint. That's a candidate. Quiet in one and busy in the other. That's a conversation with the owner. Now the built in reports have a ceiling. Their pages you read, they don't give you a table. You can filter by own account or join to a label or run every week. For that, you need an inventory and you build it with PowerShell or Microsoft Graph. The idea is simple for every team. Pull one row name, owner account and owner names. Member count. Guest count. Sensitivity label. Createddate. Last activity date. That's eight columns. And together they describe the whole tenant. With the Microsoft Teams module, you can list every team and its owners with graph. You can read group properties and activity reports in bulk and run it on a schedule. Either way, the output lands in a file or a table, and now you can ask real questions of it. How many teams have fewer than two owners? How many have guests but no label? How many haven't been touched in ninety days? Each one is a single filter. A question that took a week of clicking now takes a minute. Set it to run weekly. An inventory you pull once is a snapshot. One you pull every week is a trend, and trends are what you want on a dashboard. Power BI is the natural home. Load the inventory into a data set, refresh it on a schedule, and build a few pages. Keep it plain one page for the overall picture. Total teams. New teams this month. Teams with no activity. One page for ownership. Teams with zero or one owner listed by department. One page for guests how many, where and how long since they signed in one page for expirations. What's coming up in the next thirty days? Don't build thirty visuals. Build the ones a person can read in two minutes before a meeting because the point isn't the dashboard. The point is that every report answers a question someone will actually ask. So decide the questions first. Is the number of teams growing faster than the number of owners? Are new teams being labeled at creation? Which teams hold guests and have no review? What expired last month and who restored it? How long does a request take from Submit to Ready? If a chart doesn't answer one of those, cut it. That last question matters more than it looks. Time to provision measures the other side of the model. If it's slow, people root around you and the sprawl comes back through a side door. One more habit keep the baseline numbers from the start of the rollout. Without them, you can't say whether anything got better. But here's what happens next. In most tenants, the dashboard goes live. People look at it for a month. The orphaned team count sits at four hundred, then four, one ten, then four and thirty. Nobody changes anything. A report is a mirror. It shows you the tenant and it does nothing about it. Reports help only if someone acts on them.

01:15:56 Speaker: And governance roles and operating rhythm. The dashboard has a problem. Nobody was told it's theirs. So the first job is to name the people for roles cover most organizations, and none of them needs a new job title. The executive sponsor one senior person who cares that this works? They don't touch a setting. Their job is to say yes. When governance costs somebody a favorite shortcut and to say it in public. So the rule doesn't look like an itty whim. The governance lead. This is the person who runs the rhythm. They own the dashboard, call the meetings and chase the answers. Part time is fine at first, but a name has to sit on it. A task owned by the team is owned by nobody team owners. We've already given them a lot to do and they hold the most context. They know whether a team is alive. Admins are the last role. They run the tools, apply the policies, restore what was deleted by mistake, and pull the inventory. Every week. Admins carry out the decisions. They shouldn't make them alone. Now, roles without a calendar. Turn into a list of names on a slide. So set a rhythm two beats, one short and one longer. Monthly. The governance lead and an admin spend about an hour on the operational numbers, how many teams were created and how many were created with a label and two owners. Which teams lost an owner this month? What's due to expire in the next thirty days and who hasn't answered? Guests. Added guests who never signed in and provisioning time. Because if that number climbs, people will start working around you. Quarterly is wider. The sponsor joins along with a few people from the business. This meeting looks at trends, not tickets. Is the orphaned count falling? Did expirations push owners to act or did they just click renew? Is a template unused? Is a label ignored? And one more question that matters. Which requests got turned down and was that the right call? Keep the agenda fixed. Same four things every time. New teams. Orphaned teams. Guests. Expirations. A fixed agenda makes the meeting short and a short meeting survives. A creative one gets cancelled by June and every item needs an action with a name and a date beside it. A review that ends with we should look at that hasn't reviewed anything. Now the part that decides whether the whole system holds up exceptions. They will come. A team that needs sixty channels. A department that wants guests from a domain you blocked. A project that really does run for five years. Some of these requests are fair, so don't pretend they won't happen. Build a path. The requester explains the need in writing. In a few lines, a named person decides usually the governance lead and anything risky goes up to the sponsor. If it's approved, it gets an end date because most exceptions are temporary and nobody remembers that. Then it goes on a record. A simple list works. Which team? What rule was bent, who approved it, why? And when it comes back for review, the quarterly meeting reads that list out loud. That sounds like bureaucracy. It's the opposite. An exception with a record is a decision. An exception without one is a hole in the policy that somebody will find again next year. And here's what the list tells you over time. If the same exception shows up five times, the rule is wrong. Fix the rule and the exceptions go away. But look at what's still missing. Roles exist. A calendar exists, a path for the odd case exists, and none of it matters if a hundred owners don't know any of this is happening. Governance doesn't run on settings. It runs on people choosing to follow it, and people only follow what they understand. Communication and training. Governance without friction. Most governance messages fail in the first sentence. Per the new Microsoft three hundred sixty five Group lifecycle policy owners are required to. And that's where the reader stops. Not because they're lazy, because nothing in that sentence tells them why they should care. So start there with the why. In plain words, an owner doesn't need to hear about group objects or retention scopes. They need one idea. If you own a team, you answer for who's in it. And here's what we're asking you to do. And what happens if you don't try it in two sentences? Every team now has two owners, so someone is always responsible when the first one leaves once a year, we'll ask if your team is still needed and it takes one click. That's the whole policy. Say what changes? Say what it costs them and say what it protects. If the cost is one click a year, tell them it's one click. People accept small costs. They can see. They resist big ones. They have to imagine. Now training. This is where organizations overbuild they write a forty page owner handbook. Nobody opens it. The one person who does is the person who didn't need it. Skip the manual, build a ten minute session instead, or a short recorded video with one job. What an owner is responsible for for things. Keep membership current. Watch who joins from outside. Answer the review when it arrives. Renew or retire the team when it expires. Four things fit in someone's head twelve. Don't show it. Live to open a real test team and click through each task where the member list is. How to remove a guest, what the renewal email looks like, and which button to press. People remember a screen they've seen once better than a paragraph they've read twice. Then put the short version where owners will find it later. A single page pinned inside the team creation flow or linked in every note as you send. Not buried in a policy library. Which brings us to the message people see most the expiration notice. Microsoft sends it on its own schedule and the default text is generic. It reads like system noise, so people treat it as system noise. They delete it, then the team expires and you spend a Monday restoring it. You can't rewrite Microsoft's email, but you can add your own around it. A short note from the governance lead sent to owners ahead of the first notice, saying what's coming and what to do and keep it tight. Name the team, say the date. Give the one action your team. Project Atlas expires on March fourteenth. If it's still active, open the email titled Renew your Group and select renew. If it's finished, do nothing and we'll archive it. A subject line that names the team gets opened. A subject line that says action required gets filed. Test it to look at how many owners renewed after the first notice versus the last. If most wait for the final day, the early messages aren't working, and that's a sign to change the wording, not the schedule. Now one more layer messages travel better from a neighbor than from it, so build a champions network in each department. One or two people who already care about order. They aren't admins. They don't get extra rights. They get early notice of changes, a direct line to the governance lead, and a few minutes a quarter to hear what's coming. What do they do? They answer the small questions in their own hallway. Do I need a new team or a new channel? Who do I ask to add a guest? They also tell you honestly when a rule is annoying their people and that feedback is worth more than any dashboard. Pick people who volunteer. A champion who was assigned will do the minimum. One who asked will do more. So now you have a reason. People understand a short lesson, notices that get read and a few voices in the departments. That's the communication. But all of it lands on a tenant that already has thousands of teams in it, and turning governance on across all of them on the same day is how you break somebody Monday rolling out governance in an existing tenant. You can't turn this on all at once. A tenant with five thousand teams has five thousand owners, and every one of them built their work around the old rules. Flip every control on the same morning, and you'll spend the afternoon explaining why a project site went read only. So the rollout has an order, and it starts with looking before touching anything. That's discovery. Pull the inventory we built in the reporting section and read it as a map of what you're about to change. How many teams exist, how many have zero owners, and how many have one? Which ones have been silent for ninety days, which ones hold guests, and how many of those guests have never signed in for numbers matter. Most ownerless teams. Single owner teams. inactive teams and teams with guests. Write them down with today's date. They're your baseline, and in six months, they're the only proof you have that anything improved. Discovery also tells you where the risk sits. A tenant with one hundred owner list teams is a different job than one with four thousand. You'll size the cleanup from these numbers, not from a guess. Now phase one. And it's the easy one on purpose switch on the naming policy and the exploration policy, but only for teams created from now on. Nothing that exists today changes. Every new team gets the right prefix. A blocked word list and a clock that starts on day one. Why begin here? Because it stops the bleeding without touching anyone's current work. The pile stops growing before you try to shrink it, and owners meet the rules gradually through new teams instead of through a surprise on a team they've used for three years. Run it for a month or two. Watch what breaks does the naming rule reject names people actually want? Do the first expiration notices land in the right inbox? Fix those now while the group affected is small. Phase two is where you reach back into the existing tenant first labels use the report of unlabeled teams. Apply a baseline label in bulk to the ordinary ones and ask owners about the rest, starting with teams that hold guests. Check each batch before you push it, because a label can change what guests are allowed to do. Then the owner list teams. This is the clean up people dread, so treat it in steps. Teams with no owner but real recent activity. Get a new owner drawn from the active members or from a manager. Teams with no owner and no activity. Go into a holding list. Send a notice to the remaining members, give a deadline and if nobody claims the team, archive it. You haven't deleted anything. You've made the decision reversible. And what about expiration for the old teams? Apply it in waves one hundred teams at a time, not five thousand. Otherwise, every owner gets the same email in the same week and the help desk drowns. Phase three is the one that changes people's habits, restrict who can create teams and open the request flow. Wait until the first two phases are stable by now. Naming and labels are working. New teams carry two owners and the cleanup has shrunk the pile. Only then do you close the open door. Restrict creation to a security group and point everyone else to the form and test the flow before the switch. Submit ten requests yourself from different roles. If a team takes more than a few minutes to appear, fix that first. Restricting creation with a slow flow is how you create shadow tools overnight through all three phases. One rule holds nothing lands without a warning. Every phase gets a message before it starts, what's changing on which date, and what the owner needs to do. Send it two weeks ahead again a few days before and once more on the day. Use the plain language from the last section and name the team where you can then tell people who to ask, because the champions in each department will get the first questions. That's the plan. And on paper it looks calm. But rollouts rarely fail in the plan. They fail in the same few places, again and again, and most of them are visible from the start. Common failure patterns and how to avoid them. The first failure is the approval flow that grew a conscience. It starts reasonable a form, an approver, a team. Then someone adds a legal check, then a security review, then a second approver because the first one was on leave once. Three months later, a simple request takes four days and touches five people. And what do users do? They stop asking. They open a shared mailbox or a folder on a personal drive, or a free tool you've never heard of. The data is still being created. You just can't see it anymore. The fix is a hard number. Decide how long a request may take and measure it every month. For most teams, approval should be automatic. Human review belongs only where the label or the guest rules say the risk is real. Everything else should just build. The second failure is the pile of choices twelve labels, thirty templates, a naming rule with seven parts. Each one made sense on the day somebody added it. Together. They ask an owner to decide things. Nobody explained to them. When there are too many options, people stop reading and pick the first one so you're careful. Twelve labels collapse into one and it's the wrong one. Keep the label set at four, the template catalog under eight, and the naming rule to something a person can say from memory. If you can't explain a control in one breath, nobody else can either. Third, the policy that lives in a document. There's a governance page on the intranet. It says owners must review membership twice a year. It says guests must be removed after a project ends. It's a good page. Nobody's checking whether any of it happens. A rule without a mechanism is a wish. Every statement in that document needs a matching control, an access review that runs on a schedule. An expiration clock that starts at creation. A report that shows who ignored the notice. If a rule can't be enforced by the system, either build the enforcement or take the rule off the page. Because an unenforced rule teaches people that the rest are optional to forth governance that only it owns. Admins can configure every setting in this episode. What they can't know is whether a team is still needed. They don't know that the quiet finance team is quiet because it only wakes up at year end. They don't know the difference between a dead project and a paused one. So when it writes the rules alone, two things happen. The rules are technically correct and practically wrong, and the business treats them as someone else's problem. So when a rule hurts, they push back. Instead of helping put business voices in the room from the start, the sponsor, the department champions, a few owners. They won't make the rules easier. They'll make them right. And the fifth failure is the one that sits under all the others. Treating governance as a project. A project has a start date and end date and a closing slide. The team celebrates, moves on and the tenant keeps changing. New hires become owners who never saw the training. Microsoft adds features that create new places for data. A label that fit last year doesn't fit a new partner model. Within eighteen months, the numbers drift back off and teams climb. Guests pile up and someone proposes a cleanup project, which is the same project run again. Governance is an operating function like patching or backups. It has an owner, a calendar and a budget line that doesn't expire. The monthly review isn't optional overhead. It's the thing that keeps every other control alive. Look at what these five have in common. None of them is a technical failure. The settings work, the policies exist. The failure sits in how people were asked to live with them, and in whether anyone kept watching after the launch. So what does the system look like when none of these show up? One where the controls are few. Each stage has an owner and every piece connects to the next. Time to put the whole thing in one frame, a practical reference architecture. Here's the whole thing in the order a team actually lives, it. It starts with a request. Someone needs a place to work, so they open a form, power automate and forms, catch it, collect a purpose, two owners, a label and an expected duration. Automated approval handles the ordinary cases. A person steps in only when the label says the risk is real. Next, the name. The entry ID naming policy adds the prefix and checks the blocked word list. The owner never types the standard. The system applies it, then creation graph or the teams provisioning call builds the team from the approved request one action and inside that action the label lands from purview with privacy guest and sharing rules attached before the first message. The template shapes the channels, tabs and apps. Now ownership two owners set at creation enforced by the flow. After that, the team enters use conditional Access Watchers sign ins, DLP watchers content and retention quietly holds what it was told to hold, then review, enter access reviews, ask owners to confirm members and guests on the schedule. The inventory and the power BI dashboard show the governance lead. What's drifting then expiration the Microsoft three hundred sixty five Group expiration policy starts its clock on day one and sends the renewal notices. Active teams renew, finished ones don't, and the end state is archive or delete with retention as the net underneath either choice ten stages. Every control sits on one of them. Nothing floats. Now how much of this do you need on day one? Less than you think. Minimum viable governance is five things. Naming policy. Expiration policy. A required second owner, a small label set with a default, and a weekly inventory. That alone stops most of the growth, and you can run it with a part time governance lead. Mature governance adds the rest. The full request flow with restricted creation, custom templates with owners, guest access reviews and domain rules. Conditional access tied to labels. DLP scoped by label. A dashboard with a monthly and quarterly rhythm. You earn that stage over a year, not a quarter. So what do you do in the first thirty days? Week one pull the inventory and write down the four baseline numbers. Owner list teams. Single owner teams. Inactive teams. Teams with guests. Week two choose the label set and the default and switch on the naming and expiration policies for new teams only. Week three. Name the governance lead. Book the monthly review and pick your first champions. Week four build the request form and test it yourself ten times. Nothing in that month blocks a single user, and by the end the pile has stopped growing. That's the architecture. But a diagram doesn't change a tenant. A different assumption does. Conclusion. From clean up to control, sprawl was never an accident. It's what happens when a tenant lets anyone create anything with no owner, no clock, and no class. The tenant did exactly what it was built to do. That's the model. And it can change. Not by chasing individual teams. You'll never win that way because there's always another one. Instead, you govern the lifecycle. Request, create, use, review, expire, archive, fix those stages and every team that passes through them comes out governed. If this changed how you see your tenant, leave a review of the podcast. It helps more admins find lifecycle governance before they're drowning in a cleanup. And connect with me on LinkedIn. Tell me what you want covered next. One last thing. Every ungoverned team created today is a cleanup task scheduled for next year.