After working with many customers mapping their retention schedule into a workable Purview File Plan, I’ve observed a set of similar challenges.
Did you know? AI hasn’t changed or eliminated the underlying challenges – it has simply made them more urgent. Retention and deletion controls matter more than ever.
I call these challenges “Hot Spots” and I’ve previously listed them in a blogpost titled Retention Schedule “Hot Spots” for Microsoft Purview.
This post is a detailed explanation of Hot Spot 2… the number of record series whose retention starts after an event (I’ll explain what I mean by “event” in a moment). This hot spot has made the second position in the list due to its complexity and dependencies.
TL;DR:
Simply put, the fewer event-based retention labels you include in your file plan implementation the simpler and more manageable your “operational load” will be.
I will die on this hill.
Retention events are common in retention schedules. This makes sense since in the business world, events happen all the time; many of them triggering the start of a retention period. Common examples of events that trigger retention:
- Fiscal year-end
- Contract completion
- Project completion
- Product retirement
- End of lease
- End of agreement
- Exit of employee
In its simplest form, a Purview retention label can be configured to start retention based on one of the following 3 options: created date, last modified date, or labeled date. None of these options align to the custom event date examples listed above. For this reason, with an E5/G5/F5/A5 or Purview add-on, Microsoft provides an additional, 4th option called “custom event date”.
How does Purview handle retention for these types of events?
🛑Stop! Before jumping into the “custom event date” option, be aware of the additional, follow-on complexity it will add to your file plan implementation.
I strongly believe this is not solely a Microsoft Purview challenge. Event-based retention tends to be complex regardless of the records management platform being used. That complexity is often amplified when organisations lack well-governed content structures and have not clearly defined the technical triggers required to initiate retention events.
I’ve previously blogged about the setup for an event-based retention label including the initial configuration, the application of the label on the related event content, and the ultimate event trigger when the specific event occurs (i.e., a contract completes). This is a multi-step process requiring a lot of governance and discipline to implement at scale – far more than other types of retention triggers.
I won’t repeat the steps, but instead will link to those blogs:
Through those blog posts, I’ve reduced the steps down to the minimal number required to successfully implement event-based retention… and it’s still complex! This supports my current opinion that they should only be used with careful planning and mature governance.
Is there an easier alternative to an event-based label?
Yes, although not perfect, not a complete replacement, and it is risky. Alternatively, you can use a retention label that starts the retention clock on the labeled date and then YOU control when the label is applied to the items to simulate the “event”.
Downsides to this approach:
- the content may not be labeled until the event occurs (this means it could be deleted before that time unless you have some other control in place to prevent that)
- someone/a script/AI? has to know to label the content when the event occurs (can be manageable if all the content relating to the event is in the same container (library, folder or document set) so you can simply label the container. A Fiscal Year folder is a great example of this that I have seen several customers use.
- still relies on some kind of standard structure to easily identify everything relating to the event (folder, document set, metadata)
Upsides to this approach:
- simpler configuration than an event-based label
- can use an auto-apply label policy or a script (or AI in the future?) to apply the retention label if you have a well-defined structure and metadata to correctly identify the content
Closing thoughts
Although it’s likely not realistic to remove all event-based retention labels from your Purview file plan, doing what you can to reduce the number while still adhering to the spirit and intent of your retention schedule is always a pragmatic approach and my recommendation. It may very well make you more compliant in the long-run.
What are your thoughts?
Thanks for reading.
-JCK