A 310-line retention schedule written for paper had been carried into Microsoft 365 as static policies nobody maintained. We rebuilt it on retention labels, adaptive scopes and event-based retention, and cleared a disposition backlog of 48,000 items.
The provider's retention schedule ran to 310 lines and had been written when records were paper and lived in a basement. It separated record series at a level of detail that made sense to a records manager and none at all to a clinician saving a document to a Teams channel. When the organisation moved to Microsoft 365 the schedule was transcribed rather than redesigned.
The transcription used retention policies, and only retention policies. That choice quietly removed every capability the programme needed. Policies apply to whole containers, are invisible to users, cannot be chosen per item, cannot declare a record and cannot trigger a disposition review. Content reached the end of its period and was kept indefinitely, because nobody would configure automatic deletion on clinical material.
Scoping had failed in a more mundane way. The policies were static, and a static scope stops at 100 SharePoint sites and 100 OneDrive accounts. Only 13 policies can be scoped to all sites, so neither the itemised route nor the blanket route scales. The team wrote new policies to get around the ceiling until it ran out of those too, and sites created afterwards were never covered. Across 1,240 sites in the final inventory, a meaningful share had never been covered by anything.
The regulatory picture made guessing expensive. Medical record retention is set by state statute and the periods differ across the 3 states the provider operates in. Records for minors run until the age of majority plus a further period — a clock starting at an event rather than at file creation. None of that is expressible as a fixed number of years from the day a file was uploaded.
The first decision in any Microsoft 365 retention programme is labels or policies, and it is usually made by accident. We made it deliberately, then built the scope model so the schedule would not go stale a month after go-live.
Worked through the 310-line schedule with the records manager and legal, collapsing series that shared a retention period and a disposition outcome. The test: if two lines produce the same action at the same time, they are one rule. Retention policies were then kept for broad, invisible, keep-everything baselines where no user decision and no disposition review is wanted. Labels were used wherever an item-level decision, a record declaration or a disposition review is required — most of the clinical and legal content.
Built the label set as a file plan rather than as individual labels, so each carries its descriptors: the citation, the statute behind it, the responsible department, the record category, the provision. Records and regulatory records were distinguished carefully — a regulatory record cannot have its label removed or its period shortened by anyone, including a global administrator, which is right for a narrow set of content and a trap everywhere else.
Every static location list was replaced with an adaptive scope defined as a query — site scopes on site properties and provisioning metadata, user scopes on directory attributes such as department, job title and country. The query re-runs daily, so a site created next quarter with the right metadata is in scope without anyone touching the policy, and adaptive-scope policies are not bound by the per-policy location counts that capped the static configuration. Several scopes attach to one policy, which collapsed a set of near-identical policies into one. The trade-off was stated up front: adaptive scopes cannot be used with Preservation Lock, so the few policies genuinely needing an irreversible lock stayed static.
Retention that starts at an event needs the event. We defined event types for patient discharge, employee termination and contract expiry, gave the relevant labels an asset identifier, and built integrations raising the event through the Graph API when the source system records it. Event-based start is a label-only capability, which settled the earlier labels-or-policies argument on its own. The clock for a minor's record now starts where the statute says, not where a PDF was uploaded. Where no system could supply the event reliably we said so and used a conservative fixed period.
Configured multi-stage disposition review so content reaching end of life goes to a departmental reviewer first and records management second, with the options to dispose, extend or relabel, and proof of disposition retained for seven years either way. Then worked the backlog: 48,000 items that had passed their period under the old regime went through review in departmental batches, releasing 38 including Preservation Hold library growth nobody had examined. Holds from closed matters were reconciled against the eDiscovery case list first, because retention cannot delete anything a hold is preserving.
Rule model: Retention labels for anything needing item-level decisions, record declaration or disposition review; policies only for invisible baseline coverage
File plan: Labels imported with citation, regulation, department, category and provision descriptors, regulatory records restricted to the set that genuinely warrants an irreversible lock
Scoping: Adaptive scopes built on site metadata, directory attributes and group membership, re-evaluated daily and free of the 100-site static ceiling
Event-based retention: Event types for discharge, termination and contract expiry, asset identifiers on the relevant labels, and events raised from source systems through the Graph API
Disposition: Multi-stage review, seven-year proof of disposition, and labelling automated through trainable classifiers and classification conditions
Client identity withheld under confidentiality. Figures are representative of engagements of this scope.
If your organization is facing a similar challenge, here's what we learned:
Retention labels and retention policies are not two ways of doing the same thing. Policies are container-level, invisible and silent. Labels are item-level, visible, can declare a record, start retention on an event and trigger a disposition review. Policies for a baseline, labels for anything a human should decide about.
Static scopes go stale the week you publish them. A static scope stops at 100 SharePoint sites and 100 OneDrive accounts, and only 13 policies can cover all sites. Adaptive scopes are daily queries against site metadata and directory attributes, so new content arrives in scope — at the cost of Preservation Lock, which they do not support.
Event-based retention is the only honest answer for clocks that start later. A minor's medical record, an employee file, a contract — none start ageing when the file is created. If you cannot get the event from a source system, say so and use a conservative fixed period rather than a number that looks precise and is not.
Disposition review is where a retention programme becomes real. The moment a reviewer decides whether a specific record goes, the schedule is tested against reality — and the proof of disposition is what you show an auditor.
Reconcile holds before you dispose of anything. Retention cannot delete content a legal hold is preserving, and an open matter nobody closed keeps years of content alive silently. Start the disposition programme with a hold inventory.
Microsoft Platform · Insurance
Microsoft Platform · Banking
Microsoft Platform · Manufacturing
Most Microsoft 365 retention programmes keep content and never dispose of it, because the wrong control was chosen at the start. We rebuild schedules on labels, adaptive scopes and a disposition review that runs.
Tell us what you need. We will send curated profiles within 4 days.