Operations Overview
Once configured, AutoRecords is designed to run automatically based on a schedule. It will assign Policies and Retention Categories, calculate Event dates, evaluate Triggers and perform Actions with virtually no end user interaction. Once the Policy and Retention Category is assigned to an object, the life-cycle of the M-Files object is determined automatically by AutoRecords. In addition to the automated processes, authorized users can create and assign Holds to M-Files objects, resolve conflicts and run AutoRecords on demand.
Scheduling AutoRecords To Run
AutoRecords is designed to run on a scheduled basis. The Processing Interval determines when it will run and is set up in the M-Files Admin under Configuration | Other Applications | TEAM.AutoRecords | Configuration | Processing Interval Config.
Scheduled processing uses an M-Files feature for scheduling tasks. The configuration must have Enabled set to Yes and then one or more "Triggers" specified. A Schedule Trigger can be Daily, Weekly, or Monthly and based on the selection, different values are required. Most values are self explanatory, requiring days of the week, times or days of the month. Unrepresentable Date Handling appears for monthly processing in cases where you select Monthly processing and specify a day such as "31." On months with less than 31 days, M-Files determines whether to use the closest date or skip the process.
Manually Running AutoRecords Processing
When creating configurations in M-Files using AutoRecords objects, it is often helpful to manually run AutoRecords to see validate that Policies and retention get applied and operate as expected. This is most often done in a separate M-Files vault. Once configurations are working as desired, they can be created on a production environment either through copy and paste or an export and import.
To manually run AutoRecords Processing, click on the Run AutoRecords action from the M-Files Action menu.
In order to see this option, you must be a member of the Records Managers.
Additional AutoRecords Processes
If you have access to the Administration screen you may also manually run AutoRecords from there and perform additional tasks. Navigate to the Configurations | Other Applications | TEAM AutoRecords | Configuration option to reveal the Configuration panel shown below.
- #1 Update Cache: This is generally only used in specific upgrade situations.
- #2 Processing Status: Shows the last time AutoRecords ran and the next time it's scheduled to run.
- #3 Clear Last Run Time: Clears the last run time from history.
This will cause every object in the vault to be reprocessed which could take a very long time and must be done with caution.
- #4 Run Vault Structure Import: This is used during the intial installation of the vault app. After it has been run once it does not need to be run again until the next version of AutoRecords is installed.
- #5 Processing Subroutines [Run Now]: This runs AutoRecords manually outside of the normally scheduled time.
- #6 (Step 1) Create Trigger Property Objs [Run Now]: This option is used to make M-Files properties avialable for use within Triggers and Policy Filter configurations. This should be run after AutoRecords has been installed. It is also very useful when new properties are added to M-Files and those properties need to be included in the AutoRecords configurations. Since it only runs Step 1, it usually completes in less than five minutes the first time and afterward it will take only a few seconds with each subsequent run.
Monitoring AutoRecords Processes
If you have access to the Administration screen you may monitor AutoRecords as it runs. Navigate to the Configurations | Other Applications | TEAM AutoRecords | Dashboard option to reveal the Dashboard panel shown below. The steps listed correspond to the steps in the Understanding AutoRecords Processes page.
Assigning Policies & Retention Categories
You should not assign Policies, Retention Categories or Events to documents manually, via M-Files automated suggestions or using any scripts or tools such as Property Calculator. Let AutoRecords do the work for you.
AutoRecords Policies
An AutoRecords Policy is a very important part of AutoRecords. This is where documents/objects get assigned their retention. A Policy is a special object on the system which points to one or more AutoRecords Triggers and/or M-Files Classes. Policies are applied to objects on the system that do not already have an Policy applied. The AutoRecords Policy assignment process is performed during the scheduled AutoRecords processing and evaluates whether any objects added since the last time the process ran meet the conditions of any Policy. When an object has a Class and properties that match a Policy and Policy Filter, the Retention Category associated to the Policy will automatically be applied. See Policies above for documentation on how to configure this object.
Understanding Events And Actions
Events represent a future plan to perform some work on the system. Actions represent work being done on the system. All objects which AutoRecords manages will point to some kind of an Event object on the system. An Event object is scheduled for a date in the future and may point to one or more ojects on the M-Files system. When the Events's scheduled date arrives AutoRecords will perform the Actions associated with the Event against the files that are linked to the Event.
A simple example is to consider an organization that receives 100 invoices each day and deletes those invoices 7 years later. AutoRecords will schedule an Event for seven years from the day and all 100 invoices received on that day will be linked to the Event. Once the Event Date has been reached AutoRecords will execute a separate Action to delete each of the 100 files. If the Event Template uses Direct Actions, the Action of Delete will be performed directly against the file and it will be deleted. If the Event Template uses Workflow Actions AutoRecords will create an Action object on the system. The Action object is sent through a workflow where a single state executes the code to delete the file. This temporarily increases the number of objects on the system while processing, but depending on configuration these Action objects can be removed as part of AutoRecords process, saved for auditing or extended to perform additional processing as part of the Action workflow.
Since both Events and Actions are M-Files objects they can be easily accessed using M-Files views and can easily be exported using any common M-Files Export mechanisms. Likewise, both Events and Actions are maintained on the system based on the duration of the date set in the Event Template.
Managing Large Vaults
When M-Files updates a file it performs many checks and updates many relationships. These updates take time to complete. As the vault size gets larger the initial AutoRecords run may update large numbers of files as it assigns initial retention policies. Since it's updating many files, the process may take a long time to complete. While exact performance numbers are hard to pin down, if your vault has 70,000 to 100,000 documents it may take a full day for all of the M-Files updates to complete. If you have a million documents it may take 10 times that long.
In general, AutoRecords performance is directly related to how the M-Files environment has been architected and the overall performance of M-Files.
After the initial run, AutoRecords is only looking for new and changed documents so performance of subsequent runs is generally not as significant of a factor.
There are several tips that can help address the issues around initial updates to files on the system. A guidance document for running AutoRecords on large vaults has been created and can be found at the AutoRecords Download Site.
If the object being added to the system qualifies for a Policy, the Retention Category that gets assigned using M-Files drag and drop will be overwritten by the Policy the next time AutoRecords processing runs.