As we move through this blog series focused on creating a usable, automated and simple file plan we will build the "house" in steps until there is a finished and beautiful looking building. With that in mind, today's post will cover determining the trigger type. Determining the trigger type sets up our file plan to be actionable and automated.
Retention periods start with triggers. Having flexible triggers is perhaps the most important aspect of good rules based record keeping. It is crucial to have triggers that can fire from recurring calendar events, business system events, or rules based on any combination of available meta data.
Now that we've classified information into its appropriate bucket so that it can be properly managed and disposed of, we need to figure out what type of triggers will most effectively accomplish this task.
Event vs. Date Triggers
Just as we did with our record types, we must determine which type of trigger will allow us to manage the data from creation to destruction. This is critically important to the information governance program as the triggers are the link between the file plan and the lifecycle of your records. We need to match the trigger type to it's appropriate record type.
Let's focus on event triggers first. Case records (click here for a quick reminder on what constitutes a case record) have to have an event type trigger. For example, employee records are case records and therefore it is only logical that they should be tied to an event trigger such as "Employee Hired" or "Employee Terminated". If you go with a date trigger, each document (or other piece of content) would need to be triggered individually.
A screenshot from SharePoint showing an example for a case identifier.
There are multiple benefits of event triggers including:
- Event triggers can be recurring (e.g. yearly, monthly, quarterly)
- They can be business system driven (HR, CRM, or ERP systems)
- Based on "real world" events and not an arbitrary date
- Based on a future date, giving the ability for indefinite retention periods
Once you know an event trigger is needed, you need to also know the case identifier to use to start an occurrence for each case record. Going back to the employee records example, the case identifier would likely be the employee ID. Hopefully you have software that can handle this type of scenario, as most of your records will likely turn out to be cases and not date based, which is what we'll talk about next.
A date trigger uses time based retention. Date triggers are useful for an admin-based record category, which is managed individually based on its age or some other date that is already known or will be known and set in the future. This is known as a True Document Date and the record is disposed of according to the lifecycle defined for the record category.
A screenshot from SharePoint showing invoices with a true document date.
While date triggers certainly have their place with certain record types (admin-based), on their own they are woefully insufficient in handling many of your record lifecycles properly.
There are a few problems with date triggers:
- They cannot handle multiple files per record
- Often requires changing meta data on many records
This isn't to say that you should never use date triggers, as for simple admin-based records they can be quite effective. However, finding the right balance of automated triggers to ensure your end users' workflow is not interrupted is critical to the overall success of your information governance program.
What is a Rule Trigger?
A rule trigger, which is unique to Gimmal, is a trigger that is based on any available meta data from the record. A simple example would be a "Status Complete" trigger. When the status of a document is changed to "Complete" in the meta data, that would fire the associated rule trigger.
A screenshot from RecordLion Information Lifecycle showing the trigger details for a "Status Complete" rule trigger.
Rule triggers have several benefits as well:
- can be based on any available meta data
- improves automation of the lifecycle
- increased flexibility versus traditional date triggers
Rule triggers can be used with admin-based records, which represent information that consists of the same topic or type of document. Usually this represents an ongoing business activity that does not have an end date. It is also possible to use rule triggers for case records in subsequent phases after an event occurrence, in order to split the individual documents in a case to have different retention periods.
The review process is the next step and should not be underestimated. Complete buy-in from the entire organization is the only way for a file plan to be effective. Let all of your stakeholders review the trigger types and offer notes and changes. Give a firm deadline for when these reviews need to be conducted to ensure the project stays on track.
Once the first round of review is complete, the records manager should set up a detailed review with the inside counsel or compliance team. This confirms that everything is completely compliant and ready for the final review at the executive level. Who exactly is in this meeting will of course vary from company to company, but C-level approval will be crucial going forward, especially since this project (and the file plan overall) will involve the allocation of resources.
Next week we will discuss the next step in the overall file plan process: determining the disposition type. As we move through this process and add layers, we must still keep in mind the general principles we rely on: automation, simplicity and completeness. This mindset will certify your information governance program is truly effective and providing value to the business.