A long time coming, but this is the fourth post in my Blog Post series, Microsoft 365 Fiscal Year Retention, and its purpose is to demonstrate one of the ways to implement Fiscal Year retention in Microsoft 365.
The retention requirement may read something like this… “Retain all Financial reports for 7 years past the close of the Fiscal Year they relate to and then put thru a disposition review”.
There are several ways to accomplish this other than manually applying a retention label to a document at the end of each Fiscal Year. Instead, let’s look at ways this can be automated.
Each of the options in this series has differing levels of automation, control, complexity, pros, and cons. I’ll walk thru each of them in separate posts and will update the links here as they’re published:
- OPTION 1: Microsoft 365 Fiscal Year Retention | Default Folder
- OPTION 2: Microsoft 365 Fiscal Year Retention | Event-based Library Default
- OPTION 3: Microsoft 365 Fiscal Year Retention | Microsoft Syntex
- OPTION 4: Microsoft 365 Fiscal Year Retention | Event-based Auto-apply (this post)
Please refer to the Microsoft Purview Data Lifecycle Management & Microsoft Purview Records Management license guidance for the license required for an event-based retention label. It will be one of these:
- Microsoft 365 E5/A5/G5
- Microsoft 365 E5/A5/G5/F5 Compliance and F5 Security & Compliance
- Office 365 E5/A5/G5
- Microsoft 365 E5/A5/F5/G5 Information Protection and Governance
Steps for Fiscal Year Retention | Event-based Auto-apply
This option is comprised of a 1-time setup along with recurring steps each fiscal-yearend:
One-time setup for Fiscal year retention using an auto-applied event-based label:
- An event-based retention label
- A tenant-level Fiscal Year term set
- A managed metadata Fiscal Year custom column added to the SharePoint library
- An auto-apply retention label policy
Once at the end of each Fiscal year:
- Trigger the retention event to start
- Update the auto-apply label policy to reference the new Fiscal Year
You may be thinking… why not use the built-in Compliance Asset Id to hold the fiscal year? Although it is certainly possible to use the Compliance Asset Id for storing the fiscal year, I prefer to use a custom column as it provides more rigor and control over the values entered into the column. For this reason, I’m using a custom managed metadata column for Fiscal Year instead.
The “heavy lift” for this configuration is the initial one-time setup. On subsequent fiscal years, you only need to trigger the “end of fiscal year” event and update the retention label auto-apply policy to point to the new fiscal year. (something you can do either manually or via a PowerShell script)
Let’s dig in…
Step 1 | Create Term Set for Fiscal Year
By using a tenant-wide managed term set to define your Fiscal Years, it provides the flexibility to use the term set in columns across all SharePoint sites in your tenant in a consistent way. This is particularly important if you have Fiscal Year content spread across numerous SharePoint sites, all requiring retention.
For anyone in the Records Management space, it’s important to understand how SharePoint managed terms, specifically tenant-level terms, can be leveraged to classify your data and automate your retention schedule across SharePoint sites in a more scalable way than other metadata options (like choice or lookup).
We start by creating a tenant-wide term set for Fiscal Year in the Modern Term store.
Tip for Term Set Administration: Assign an owner to keep your term sets up to date and to update the default value as required. For the Fiscal Year term set, you may want to update the default value at the start of each fiscal year on all libraries consuming it.
Step 2 | Create an Event Type for Fiscal Year End
Create an event type (mine is called “Fiscal Year End”) to identify the event for the end of the Fiscal Year (FY). The name should describe the event that will eventually be associated with one or more event-based retention labels. Remember, you may have more than 1 retention label whose retention is associated with the FY end – they will all be related to the Fiscal Year End event type below.
At the end of each FY, we’ll trigger a retention event referencing this event type with the exact details of the FY we’re starting retention on.
Note: you can associate many FY retention labels to the Fiscal Year End event type, each potentially for different business content having different retention periods.
Step 3 | Create Event-based Retention Label
Create a retention label with your specific retention requirements for the Fiscal Year content you want to retain. In this post, my test retention label is called ‘Finance Report TEST’ and it is configured to retain for 3 days with a disposition review. I associate it to the Fiscal Year End event type from the previous step and auto-apply it to the SharePoint site(s) where my Fiscal Year content will be stored.
You can now have a multi-stage disposition review. In this FY retention example, the first stage could be a Finance team and the second stage could be the Records Management team as the image below shows. Check out this blog for more details: How to configure multi-stage disposition review
Step 4 | SharePoint Document Library and Site Column setup
For the retention engine to find the documents at the end of the Fiscal Year, the Fiscal Year must be associated to each document in any library where you want the retention to occur. Create a managed metadata site column, FiscalYear in my example, pointing to the tenant-wide term set created in step 1 and add it to the document library. To ensure it is updated on each document, do either 1 of these 2 things:
- Set the list column default for FiscalYear to be the current fiscal year. This will automatically set it to the current year for any document added to the library. This does not prevent an end-user from changing the value if required (if they entered a document for last Fiscal Year). If you choose this way, assign an administrator to set the default at the start of each Fiscal Year.
- Optionally, and what I’ve done in this post, create Fiscal Year folders in the library and set the column default value for the FiscalYear column for each Fiscal Year folder. You can precreate these folders in advance for many Fiscal Years ahead. This will automatically set the Fiscal Year column to the default value for the folder the document is placed into. This is done in the library settings under Column Default Value Settings
This allows you to set the default term for the folder. In this image, I’m setting the default value for the FiscalYear column in the FY 2019-20 folder to be the 2019-20 term:
Once you have all folders’ default value set with the correct term, you will see a green gear icon on each folder icon:
Whichever way you choose to default the Fiscal Year, as long as the document’s Fiscal Year column has been filled with a value on each document, the retention engine has something to work with!
Step 5 | Search Schema Preparation
Because event-based retention is search-based, we need to do some pre-work in the SharePoint Search schema before triggering the first Fiscal Year event. This setup only needs to be done once and it can then be used in all future events and anywhere you want to use the Fiscal Year value across the entire tenant.
URL to Search schema: https://domain>-admin.sharepoint.com/_layouts/15/searchadmin/ta_listmanagedproperties.aspx?level=tenant
To start, we need a crawled property generated for the FiscalYear column. To do this, we add some sample content into the Fiscal Year folders in the library and wait for the content to be crawled by the search process.
Once the crawled property is generated, ows_taxId_FiscalYear in my case, I map it to one of the pre-configured RefinableString managed properties in the search schema, RefinableString15 in my example:
You MUST use a pre-configured Refinable managed property and it appears to also be from RefinableString00 thru 99 only. A custom managed property will not work as the condition on an event trigger. Trust me, I’ve tested this!
Step 6 | Validate the Search Query
It’s always a good idea to test out your search query to verify the results before creating your event. In this case, I want to simulate the Fiscal Year End event for FY 2020-21 where I will be providing a query to determine all content to start retention on.
I’ll use the managed property in my query… RefinableString15:’2020-21′ and confirm there are 6 document results to be included in the retention event.
Step 7 | Auto-apply the retention label
Last, but certainly not least, auto-apply the default retention label based on the Fiscal Year condition and the managed property name previously defined:
Note: each Fiscal Year, you will need to edit the auto-apply label policy to update the value of the Fiscal year. It is not necessary to create a new label policy, you can just adjust the condition.
Step 8 | Create Retention Event
At Fiscal Year-end, after all documents worked on throughout the year have been tagged with the Fiscal Year they relate to, we must trigger the event. We specifically want to start retention on anything with the Finance Report TEST retention label applied and the Fiscal Year 2020-21. This can be done several ways:
- Manually thru the UI, which may be a feasible option since this is only an annual event. This is what I’ve done for this post.
- Automatically using:
- PowerShell: New-ComplianceRetentionEvent (ExchangePowerShell)
- REST API: Automate events by using a REST API (will be deprecated soon)
- [Preview] Microsoft Graph API for records management (recommended)
After you provide a unique event name, such as Financial documents for FY 2020-21, you must identify the settings for the event:
If you select Use Event Type, it will process all content tagged with all retention labels associated to that event type. A use-case for this is if you have content with different retention periods, but all starting their retention at the end of the Fiscal Year.
Immediately after I create the event for FY 2020-21 by supplying the event-based retention label, the search query to use, and the date to start retention, the counts are 0:
Several days later (when the back-end process has ran against the content), the counts are updated:
A new column, Label Event Date, is automatically added to the library once the back-end event process runs and has identified the content relating to the event. The date/time shown will match what was entered for the event trigger.
Important: if content is added AFTER the event date for the retention label and same Fiscal Year, 2020-21 in our case, the items will NOT be processed. You must trigger another event with the same conditions to start retention on those items as well. Make sure you use the same event date (the end of the Fiscal Year) for the new event since you want retention to start on the same date.
Step 8 | Perform Disposition Review
Because I also had a disposition review configured for this retention label, I received an email when the disposition review period was reached:
… and when I click Go there now… I see the 6 records waiting my review:
That’s it! The first year is the heavy lift on the setup; however, on subsequent years, this is all you will need to do:
- ensure you’ve set up the new Fiscal Year term in the tenant-level term set
- ensure the default value for the current FY is set on libraries across your tenant where FY content will be stored. Although not required, it will make it easier on end-users working with the content if the value is defaulted for them
- trigger the event at the end of the FY (automate if you can)
- Scalable. As long as a Fiscal Year metadata column is populated on content and it has the event-based retention label assigned to it, the event trigger will start the retention on the item when you trigger the event.
- [Optional] Can set the default value on libraries to alleviate the end-user from having to do it
- Requires SharePoint search schema knowledge
- Requires back-end configuration in tenant-level term store
- You cannot add new content with the FY and the retention label AFTER the event has been triggered. It will not get picked up if you do – you must trigger another event (with the same event date)
- Someone has to remember to manually trigger the event OR you have to automate the process
Thanks for reading.