Teams just made file sharing in federated chat less miserable. Good. Sharing a document with someone in another organization used to mean a detour through SharePoint links, guest access, or email — the digital equivalent of passing a note under the door because the mail slot was welded shut. The new experience lets files move through the chat itself. Genuinely useful.
Here’s the part I want you to remember long after you’ve forgotten the feature. To make it work “by default,” Microsoft originally planned to override the tenant control that governs this behavior. Not respect your existing setting. Not prompt you. Overwrite it.
Think about what that means in plain terms. You have a lock on a door. You set it deliberately, maybe after a compliance review, maybe because your DLP posture depends on it. The building manager decides the new delivery system works better with the door open, so the plan is to unlock it for you — on the grounds that most tenants would probably want it open anyway. The lock still exists. Your choice just stops mattering.
The setting in question lives in Teams Admin Center → External Access → File sharing with external users. It controls whether people in your tenant can send and receive files in federated (external) chats. Plenty of organizations have this turned off on purpose. Regulated industries, tenants with strict data-exfiltration controls, anyone who decided federated chat was fine for conversation but not for payloads. That “off” is a decision, not an oversight.
Admins pushed back, and Microsoft listened. The final implementation honors your existing tenant policy. If you had file sharing disabled for external users, it stays disabled. The feature rolls out enabled where the control already permitted it and leaves your deliberate “no” alone. That’s the correct outcome, and it’s worth saying so plainly rather than grinding an axe.
But the reversal is only half the story. The other half is that the override was the plan in the first place. Someone scoped a feature, saw a tenant-level governance control standing in the way, and the proposed path forward was to drive through it. This almost certainly wasn’t malice — it reads like a product team optimizing for adoption and not fully accounting for the fact that some of those “off” switches represent audited, intentional governance. The setting existing at all is Microsoft’s own promise to you: this is yours to decide. The original plan treated that promise as a default suggestion.
So the practical move is boring and important: go confirm your tenant actually reflects your intent. Don’t assume the reversal means your configuration is what you think it is — assume nothing, check everything.
Do this one in the portal. Open Teams Admin Center → External Access and read File sharing with external users. I’m deliberately not handing you a PowerShell one-liner here, and that’s the honest answer rather than a lazy one. The familiar federation cmdlet — Get-CsTenantFederationConfiguration — surfaces who you can federate with (properties like AllowFederatedUsers and AllowTeamsConsumer), not this specific file-sharing toggle. Rather than point you at a property and hope it maps to the control you actually care about, read the setting where Microsoft puts it. If and when a documented cmdlet exposes this exact control, that’s the time to script it — not before.
Confirm the file-sharing control matches what you believe it should be. If it doesn’t, change it the normal way — a reviewed, deliberate edit, not a bulk push — and write down why.
The feature is fine. The reversal was right. The lesson is the one Microsoft handed you for free: a governance setting is only as strong as the vendor’s willingness to honor it, and that willingness is not infinite. Keep reading the roadmap notes. The next override might not get walked back.