Skip to main content

AutoRecords Processes & Objects

AutoRecords performs multiple steps to manage retention of objects in the M-Files vault. It relies on both user defined and system created objects to perform its work. The progress is tracked in the AutoRecords Dashboard available in the M-Files Admin tool (see AutoRecords Operations for details). Additionally, AutoRecords can be configured to write entries into log files which are stored in M-Files and can be monitored. The processing steps shown below are performed for each run of AutoRecords and referenced in both the dashboard and log entries.

AutoRecords Processing Steps

**Step 1 - Updating Properties List: ** This step looks for new properties that have been defined in the admin utility and adds those properties as selectable options for triggers. IMPORTANT: AutoRecords must be run once before any Triggers can be configured so that all of the properties can get registered the first time. After that only new properties will be registered.

**Step 2 - Processing Policies: ** This step examines all Policiess to see if any new objects or changed objects now qualify for the rule, including items from Step 2 and Step 3 from above.

**Step 3 - Processing items that no longer meet Policy Requirements & items that no longer meet trigger criteria to untrigger an event: ** This step examines changes to objects which would make the object no longer qualify for a Policy. For example if a Policy is configured for a Document Class and a SubType of Employee Document, if the SubType of an object is changed from Employee document to some other value, that object will no longer meet the Policy criteria and it will be removed. Additionally, this step checks for objects on the system where a specific trigger condition has changed which impacts AutoRecords. For example, if an Event is scheduled based on when the status of a document changes to Obsolete, someone may set the status to Obsolete today which will cause an event to schedule a date for disposition. However a week from today that status may be changed back to Active in which case the Event must be unscheduled.

**Step 4 - Processing Updated Indirect Triggers to update how Indirect Retention Categories are applied: ** This step examines all Indirect Triggers to see if any have changed. If changes have been made to an Indirect Trigger, AutoRecords will recalculate retention for all objects which use that trigger.

**Step 5 - Processing updates to content that may result in new Indirect Retention Category assignment: ** Indirect Retention Categories are based on relationships between objects. This step examines any new relationships between objects to find objects which may now fall under the umbrella of Indirect Retention based on a relationship to some other object. For example, if a Project object has retention of 20 years after completion for all documents, an existing document may be updated to link to the Project. Once that change takes place, the document would be included in the Indirect Retention for the project.

**Step 6 - Processing updated Periods and Event Templates: ** This step updates references to Event Templates and Periods on the system. If a Records Manager decides to change a Period from 7 years to 10 years, this step will update all objects that reference the 7 year period and recalculate all dates to use the 10 year period.

**Step 7 - Processing Indirect Hold Conflicts: ** This step searches for all Hold conflicts and checks to see if the Hold has expired. If the Hold has expired, then it creates an Action to run disposition against the object.

**Step 8 - Processing Events that have not yet triggered: ** This step evaluates Events that have Trigger conditions that have yet to be met (i.e. a date hasn't been met, status hasn't been set, etc). Any Events that now meet the Trigger condition are updated to have an appropriate Event Date on which they will execute.

**Step 9 - Processing Events to create Actions: ** This step evaluates all existing Events and Event Groups. Where the Event Date has been met, an associate Action object is created to carry out the workflow based effort and perform the disposition for the object(s) associated to the Event or Event Group.

**Step 10 - Processing File Version Destroy Actions: ** This step handles the disposition of specific versions of objects on the system. It is the only AutoRecords action that operates against specific versions of a file. During this step old versions of the file beyond a set number are removed.

**Step 11 - Processing Workflow Ready Actions: ** All AutoRecords Actions are objects on the M-Files system. When the Actions are created, they go through a workflow associated with the Action. This step does the actual work associated with the Action such as sending notification, deleting files, etc.

**Step 12 - Processing Actions to Delete: ** This step removes completed Action objects from the system based on the parameters in the Event Template used to create them.

**Step 13 - Processing Events to Delete: ** This step removes completed Event objects from the system based on the parameters in the Event Template used to create them.

**Step 14 - Processing Orphaned Conflicts to Clean Up: ** This step removes Indirect Retention Categories which are no longer needed because metadata on an object has changed and the object no longer references an object on the sytem which has retention on it. It also removes any Conflict objects that AutoRecords created which are no longer needed or no longer reference an object on the system.

AutoRecords Objects

There are several important objects used by AutoRecords to meet the complex demands of an ERMS. These objects can be thought of in two main groups: the Configuration Objects and the Records Management Objects. Configuration Objects are created by records managers and used to tell the system how we plan to do records management. Records Management Objects are used to carry out records management as it has been established by the Configuration Objects. overview

Configuration Objects

  • 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

  • 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.