Skip to main content

AutoRecords Objects

Object Overview There are several important objects used by AutoRecords to meet the complex demands of an Enterprise Records Management System. These objects can be thought of in two main groups: the Configuration Objects and the Records Management Objects.

Configuration Objects

Configuration Objects are created by records managers and used to tell the system how we plan to do records management. The following diagram shows how configurations are used to store settings that are used when AutoRecords does its processing.

overview

  • Policy - A Policy is used to assign a Retention Category to a group of content automatically based on the class and/or metadata associated to the content.
  • Retention Category - Retention Categories get assigned to objects in M-Files by Policies and determine how the object life-cycle is managed. contains labels and descriptions for the category as well as linking the category to Event Templates which will perform actions such as disposing of the records. Additionally the Retention Category can have metadata properties added to it if needed to link it to the "File Plan" so Retention Categories can be arranged using M-Files Views and restricted based on Permissions.
  • Event Template(s) - One or more Event Template is assigned to each Retention Category to determine what will happen to any M-Files object which references the Retention Category. AutoRecords uses information in the Event Template to create and schedule records management Events on the system which ultimately perform some action against the M-Files object.
  • Trigger(s) - Define the property-based conditions on which an Event fires. There are several types of triggers that allow AutoRecords to work based on metadata conditions, date conditions and file versions.
  • Periods - Define the length of time after a Trigger condition is met, to wait before performing an Action.
  • Action Templates - Action Templates are used to associate an M-Files workflow to an AutoRecords Action. When a scheduled Event is executed, AutoRecords uses information in the Action Template to create a distinct instance of the Action and attach it to the "record" object. The workflow associated to the Action then performs some work such as Delete or Notify.

Records Managment Objects

Records Management Objects are used to carry out records management as it has been established by the Configuration Objects. These objects are used to do the work of records management within the vault.

  • Actions - Actions are objects created on the M-Files system when an Event's scheduled date has been met. The Action is created based on an Action Template assigned to the Event. If an Event Template specifies Direct Actions, then an Action will not be created.

  • Action Workflows - Pre-built workflows that perform "Actions" for AutoRecords. Pre-built workflows come with Auto-Records and handle most records management needs. New workflows may be created for nearly any imaginable use case.

  • Holds - Prevent a scheduled Event from being executed. A Hold is assigned to any record where disposition must temporarily be suspended. By default Holds do not change permissions or prevent changes to an object.

  • Indirect Retention Category - AutoRecords has the unique ability to leverage M-Files relationships and establish parent/child retention. An Indirect Retention Category indicates that an object is inheriting retention from some parent object. For example documents related to an Employee inherit their retention from the Employee object. These are created automatically by AutoRecords and should not be changed manually.

  • Events - Events are objects created on the M-Files system to schedule an action for a document or documents at some point in the future. Events are created even if the scheduled date for disposition cannot yet be calculated because Trigger conditions have not yet been met.

  • Conflicts - Conflicts are objects that are created by AutoRecords as it is trying to perform processes but for some reason cannot. This most often because an object is checked out when AutoRecords is initially trying to assign retention or trying to perform some dispostion action.