Microsoft 365 is not one thing. It is a set of workloads with different APIs, different data models and — critically for backup — different levels of vendor support. "We back up Microsoft 365" is a category, not a specification.
The gap between those two shows up exactly once: during a recovery, when someone asks for something that was never in scope.
Where your clients actually keep things
Mail and files are the easy part, and every vendor covers them. The workloads that hurt to lose are the ones that accumulated quietly.
Teams is where a large share of decisions now happen, and it is structurally awkward to back up because messages live against a channel or a chat rather than against a user. That distinction is exactly where our restore path splits: top-level channel messages restore back into Teams directly, with their original author and time but without their replies, reactions, inline images or attachments, and only the messages missing from the channel come back, in a new restored channel in the same team; private one-to-one and group chats are backed up too, but are not yet browsable or exportable in the portals, and VaultFuzion does not restore them back into Teams. Shared mailboxes are owned by nobody, which is why they fall outside per-user scopes. SharePoint sites grow sideways for years and end up holding the operational memory of a department.
| Workload | Status | Why it matters |
|---|---|---|
| Exchange Online | ✓ yes | The part every vendor covers |
| OneDrive | ✓ yes | Per-user files, usually straightforward |
| SharePoint sites | ✓ yes | Where six years of structure lives |
| Teams channel messages | ✓ yes | Channels, attachments, membership, settings, tabs |
| Teams private + group chats | captured | Backed up; not yet browsable or exportable in the portals, and not restored back into Teams |
| Shared mailboxes | ✓ yes | Owned by nobody, so a per-user scope misses them |
| Planner boards | captured | Backed up and eDiscovery-exportable; VaultFuzion does not restore Planner, so restore is export only |
| SharePoint sub-sites | ✓ yes | Libraries, lists and pages, up to three levels deep |
| Microsoft 365 Groups conversations | captured | Backed up and exportable; not restored back into the group |
| Chats hosted in another organisation's tenant | ✗ no | External meeting threads cannot be read by a tenant-scoped connector; the backup logs them as out of scope rather than skipping them silently |
Why we publish the second list
A gap you know about is a decision. You can put a compensating control against it, exclude it from a client commitment, or accept it. A gap you discover during an incident is none of those things — it is a conversation with a client about why the thing they assumed was protected was not.
This has a commercial cost and we would rather pay it here. Publishing a not-covered list loses some deals to vendors whose list is silent. It also means no client of yours learns the boundary of our scope from us at the worst possible moment.
Not "what do you cover" — you will get a list. Ask for what they do not cover, in writing, and notice how long it takes to arrive.
Scope and retention are different questions
Scope determines whether an object was ever captured. Retention determines whether the capture still exists when you go looking. A platform can be perfect on one and useless on the other, and buyers routinely evaluate only the first.
The pair of questions worth asking together: is this workload in scope, and for how long is the copy kept? Both answers should come from documentation rather than a call.