Two problems that get confused
The first problem is the personnel file: contract, appraisals, absence records, disciplinary records, pension correspondence. Retention schedules usually express this as a period after employment ends, which cannot be calculated from the date a document was created or last edited.
The second is the leaver's working content: their OneDrive, their mailbox, and the files they own in SharePoint. That content belongs to the organisation's business functions and should follow the retention rules for those functions, not a rule about the person.
Event-based retention handles the first. Ordinary retention policies and a clear offboarding process handle the second. Mixing them leads either to keeping everything a leaver ever touched for the full personnel period, or to losing business records because the person who saved them has gone.
How event-based retention works
A normal retention label starts its clock when content is created, last modified or labelled. An event-based label starts its clock when a defined event occurs, such as an employee leaving. Until the event is recorded, labelled content is retained and the clock has not started.
There are four pieces. An event type, such as Employee leaving. A retention label set to start retention from that event type. An identifier on the content that ties it to one person: in SharePoint and OneDrive this is the Asset ID property, and in Exchange you use keywords. And the event itself, which you create when the person leaves, specifying the event type, the asset IDs and the date of the event. Purview then starts the retention period for matching content from that date.
At the end of the period, the label decides what happens: automatic deletion, or a disposition review in which named reviewers confirm before anything is removed. For personnel records in a public body, disposition review is usually the right choice, at least until the process has proved itself. Reviewers can also extend retention or relabel items, which matters when a claim or a request for information is still open.
Remember that retention keeps content, it does not restrict who can see it. The HR library still needs tight permissions, and a sensitivity label where your classification scheme calls for one.
Decide the rules before the configuration
Start with your approved retention schedule, not the admin centre. For each category of personnel record, confirm what the schedule says and who owns it. Some categories may have different triggers, such as the end of a pension liability or the conclusion of a claim, and each different trigger is a separate event type.
For each category, record:
- Which records are covered, and which business area owns them.
- The trigger event, and who confirms it has happened.
- The retention period after the event, taken from the approved schedule.
- Whether items should be declared records, which prevents deletion and restricts editing.
- The action at the end of the period, and who carries out disposition review.
- The identifier that links content to a person, almost always the employee number.
Licensing and ownership
Event-based retention and parts of Purview records management carry premium licensing requirements. Licensing changes, so confirm the current position with Microsoft before you commit to a design.
Agree ownership at the same time. HR owns the personnel file and confirms the leaving date. Records management owns the labels, the schedule and disposition. IT owns the configuration and any automation. Line managers own decisions about the leaver's working content. Write this down, because the event step falls between teams and is easily dropped.
Build the structure in SharePoint
Personnel records are easiest to manage in a dedicated HR site with a small, controlled audience, not in a general team site. A common pattern is one library with a folder or document set per employee, and the employee number held in a column.
Apply the event-based retention label as the library default, so everything saved there gets it without HR staff choosing anything. When you set the default, decide whether it should also apply to items already in the library. Then make sure the Asset ID is populated with the employee number on every item. A Power Automate flow that copies the employee number from the folder or document set to each new item is one way to do it. Items without an Asset ID will never match an event, which in practice means they are kept indefinitely.
Restrict who can change labels and edit the Asset ID. If HR staff can overwrite either, the link between a person and their retention period can be broken without anyone noticing.
Personnel records rarely live in one place. Some will sit in the HR system, some in email, some in a manager's own folders. Decide which location is the record of authority, and make it the job of the leaver process to move anything that belongs in the file into the HR library before the event is created. A label can only govern what is in front of it.
Creating the event when someone leaves
The event is the step most likely to be forgotten, because it happens after the person has gone and nobody in HR thinks of it as a records task. Build it into the leaver process with a named owner.
Events can be created in the Purview portal, or through PowerShell or the Microsoft Graph API. With any volume of leavers, automation is safer: when the HR system records a confirmed leaving date, a script or flow creates the event with the employee number as the asset ID and the actual leaving date as the event date.
Make sure the person's content is labelled and carries the asset ID before you create the event. Treat the event as a point-in-time action, and do not assume content labelled afterwards will be picked up. Late documents do arrive, such as reference requests or final pay queries, so agree how HR handles them and check how your configuration treats them.
Check the event's status in Purview afterwards, and investigate any event that does not complete. Most failures come from asset IDs that do not match what is on the content.
The leaver's own content
The leaver's mailbox and OneDrive are a different question. Retention policies applied to those locations keep content for the period your schedule sets for correspondence and working files, whether or not the account still exists.
In Exchange, if a mailbox is covered by a retention policy or hold when the account is deleted, it becomes an inactive mailbox and its content remains available for search and eDiscovery. That is useful, but it means deleting an account does not delete its data. Make sure the policy scope is deliberate.
In OneDrive, when an account is deleted the OneDrive is kept for a configurable period, and access can be given to the manager or another named person. Use that window to move anything with ongoing business value into the right SharePoint site, where it falls under that site's retention rules. Do not move it into the personnel file, and do not apply the event-based label to it.
Files the leaver owns in SharePoint and Teams stay where they are, under the retention of that site, but anything shared only through links they created may need checking. Ask the line manager to confirm, before the leaving date, which working documents and shared folders need a new owner, so nothing important ends up reachable only through a disabled account.
Common mistakes
Most problems we see with this pattern come from a small set of avoidable errors.
- Creating the label but never publishing it or setting it as a library default, so no content carries it.
- Leaving the Asset ID blank, or using names instead of employee numbers, when names are neither unique nor stable.
- Applying the personnel label to a leaver's working content, which keeps everything for the personnel period.
- Declaring items as regulatory records without understanding how hard that is to reverse.
- Choosing automatic deletion before the event process has been tested end to end.
- Naming nobody as disposition reviewer, so reviews sit unactioned.
Test with a process, not a person
Before go-live, create a test employee folder with dummy documents and an asset ID, apply a test event-based label with a short retention period, and create an event. Confirm the label, the event and the disposition review all behave as expected, and that the reviewer receives the notification. Then configure the real labels separately.
We usually run this test with HR and records management together, because it is the clearest way to show each of them which step they own.
Document the result as a short procedure: how a leaver's file is completed, who creates the event and when, how a late document is handled, and who reviews at disposition. Review it once a year alongside the retention schedule, and again whenever the HR system or the leaver process changes.