A common way to apply retention in SharePoint is to set a policy on a site or library: “keep everything in HR documents for seven years”. It’s quick to set up. But it rarely matches what your retention schedule actually says.

What retention schedules usually say

Most retention rules are tied to an event in the life of a record, not to when a file was saved. For example:

• employee files: a set period after employment ends
• tenancy files: a set period after the tenancy ends
• case files: a set period after the case closes
• contracts: a set period after the contract expires

Check exact periods against your own retention schedule and legal advice.

The problem with library-level retention

A library policy starts counting from the date each document was created or modified. That causes two kinds of mistake:

• Deleted too early. An employee’s contract, saved when they joined ten years ago, could reach the end of a seven-year library policy while they still work for you.
• Kept too long. Documents about someone who left years ago sit in a library indefinitely because nobody applies the right label.

Both are risks under data protection law, and neither is easy to spot.

Retention by record

Microsoft Purview supports event-based retention, where the clock starts when a specific event happens. The challenge is knowing which documents belong to which event.

That’s where context first helps. In FilePlan 365, every document belongs to a record. When the record’s event happens, such as an employee’s leaving date being set, retention starts for every document in that record at once, using the retention label mapped to each document type.

The result

Retention that matches your schedule, applied consistently, with a clear audit trail. And when records reach the end of their period, they go to a disposition review instead of disappearing silently.