AutoRecords Operations
Once configured, AutoRecords runs automatically assigning Retention Categories, calculating Event dates, evaluating Triggers and performing Actions with virtually no end user interaction. Once the Retention Category is assigned to an object, the life-cycle of the M-Files object is determined automatically by AutoRecords.
In addition to assigning Retention Categories authorized users can create and assign Holds to M-Files objects. Holds prevent AutoRecords Events from running during the period the Hold is active. This is useful for audits, lawsuits and other times that it is important to not alter the M-Files objects. The sections below cover operations that are generally performed by Records Managers.
Manually Running AutoRecords Processing
When configuring AutoRecords it is often helpful to manually run processing to see how rules and retention get applied. This is most often done in a separate environment. 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.
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
- #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 Processing Subroutines - Run Now: This runs AutoRecords manually outside of the normally scheduled time.
- (Step 1) Create Trigger Property Objs - Run Now: This option isn't shown on the screen above, but it is used to make properties avialable for use within Triggers. This can be useful after the initial installation of AutoRecords or between AutoRecords runs if there are significant changes to the metadata structure which impact records management.
The Run Now button will initiate AutoRecords immediately as a background process.
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 Retention Categories
There are many methods to automate Retention Category assignment. The most common ways of assigning Retention Categories are listed below.
** 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 Triggers that match a Policy, the Retention Category associated to the Policy will automatically be applied. See Policies above for documentation on how to configure this object.
** M-Files View/Search Defaults **
When ingesting objects into M-Files through drag-and-drop, if a view/search includes a filter by Retention Category, the created object will automatically be assigned that Retention Category when it is dropped into the View/Search.
If the object being added to the system ALSO 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.
** VBScript Validation on Retention Category Property **
This method of automating Retention Category assignment may be configured by an administrator. The script can be configured with a series of cases where based on other metadata properties (i.e. Document Class, Status, Etc). Each Retention Category would be referenced within the script.
** M-Files Artificial Intelligence Services **
M-Files has several AI capabilities that use rules to automatically assign values to properties. Since the Retention Category is just another property the AI services can be used to automatically select the category based on rules configured in the M-Files AI Services. Configuration for these services is document in the M-Files User Guide.
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.
Holds
Sometimes circumstances require that some document(s) be preserved for a certain period of time and are not subject to AutoRecords disposition actions. Holds may be used to prevent any Actions from taking place on specific objects for a specified period. A hold consists of:
- Hold Name
- Free text custom identifier
- Hold Description
- Free text description of why this hold exists
- Hold Start Date
- Date to indicate when the hold will start being active
- Hold End Date
- Date on which the hold will no longer be active
- Hold Owner
- The user that created/mandated the creation of the Hold
AutoRecords searches all objects that are on Hold and automatically prevents any associated Events from occurring. If there is an active Hold, Actions will not be created for the document/object. The same Hold may apply to many objects and an object may have any number of Holds.
** Applying Holds **
Applying a hold involves setting the Hold property as follows:
- Once a Hold is created, the Records Manager must perform a search to find documents that should be placed on hold.
- If the objects do not contain the Hold property, the Records Manager must manually Add the Records Management Hold(s) Property.
- The Records Management Hold(s) Property is a drop down which lists all Hold objects on the system. To place an object on hold, simply select on of the Holds listed.
- The Hold End Date determines when the object is no longer on hold, so there is no need to ever go back and manually remove the Hold.
Since M-Files preserves old versions of documents automatically, Holds do NOT change the permissions on an object to prevent the users from making updates to the document.
Conflicts
Conflicts are special objects created by AutoRecords when it is performing processing but encounters situations that prevent normal processing. For example a disposition action may be attempting to delete a file that is checked out. Since AutoRecords is completely configurable, it is possible for a Records Manager to configure a system where disposition is being driven off of some criteria that doesn't necessarily prevent the object from being checked out and changed while AutoRecords is running. The following types of Conflicts may be created:
- Policy Conflict: Created when a file/object is eligible for two different Policies and AutoRecords cannot determine which it should be applied to. For example if a Document Type property is used and Policies are created for each Document Type, but the Document Type is a mutli-select property, a single document may have multiple document types and qualify for multiple policies equally.
- Action Conflict: Created when AutoRecords is trying to perform an action but is unable after three tries to complete the Action, for example if the file is locked by another process.
- Indirect Hold Conflict:
- Check Out Conflict: Created when AutoRecords is trying to perform action such as setting the retention category, updating records management properties, changing permissions, deleting a file, etc. and the file or object is checked out. A conflict will be created and AutoRecords will automatically retry the action the next time it runs. If the file/object is processed successfully on the next run AutoRecords will remove the conflict.
Policy and Action Conflict objects must be manually deleted by the Records Manager once those conflicts have been addressed.
Understanding Event Groups And Actions
Event 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 Group object points to multiple objects on the M-Files system. A simple example is to consider an organization that receives 100 invoices each day.
For each object under retention, once the Event Date has been reached AutoRecords will create an Action object on the system. 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. The purpose of the Action object is to meeting audit requirements for tracking Actions that have occurred on the system.
Since both Event Groups 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 Event Groups and Actions are maintained on the system based on the duration of the date set in the Event Template.