Skip to main content

AutoRecords Processes & Performance

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.

Important Performance Information

AutoRecords performs metadata updates to objects and files in the vault. It is very important that any custom Event Handlers on the vault take this into consideration, since processing performed during updates can dramatically extend the run time of AutoRecords.

AutoRecords Processing & Performance​

info

Steps with a (q) in the title submit multiple tasks to the M-Files task queues

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

Performance: The initial AutoRecords run will take anywhere from 1-5 minutes. Subsequent runs will be only a few seconds.

  • Step 2: Processing Policies (q)

This step examines all Policiess to see if any new objects or changed objects now qualify for the Policy. It will assign the Policy to object and update it in M-Files.

Performance: Since this step updates objects in M-Files the expected performance is in the range of 2-3 updates per second. The largest performance impact will be when new Policies have been added and large numbers of objects need to be updated with the new Policy. This step leverages M-Files task queues and will create multiple tasks based on the Task Queue Optimization settings in AutoRecords.

  • Step 3: Processing Items That No Longer Meet Policy Criteria And Updated Items That May No Longer Meet Trigger Criteria

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 from the Policy. 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.

Performance: This step will update objects in M-Files that have changed and performance will likely be between 2-3 objects per second. There are rarely enough updates of this type to have a significant impact to performance overall.

  • Step 4: Processing Updated Policies And Removing Policy From Ineligible Objects (q)

This step handles situations where Policies are updated or new Policies are added. If a new Policy is added it's possible that existing objects need to be removed from an existing Policy and reassigned to the new Policy. Likewise, a document or object may be changed which causes it to be assigned to a different Policy.

Performance: This step will update objects in M-Files that have changed and performance will likely be between 2-3 objects per second. Policy changes can have wide ranging implications since significant amounts of content may apply to a single Policy. This step leverages M-Files task queues and will create multiple tasks based on the Task Queue Optimization settings in AutoRecords.

  • Step 5: Processing Updated Indirect Triggers To Update Indirect Retention

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.

Performance: This step will update objects in M-Files that have changed and performance will likely be between 2-3 objects per second. Importantly, this step updates Event Groups rather than the objects under retention (files and objects) on the vault. This means that a single changed Event Group may represent many files. As a result it's likely that performance of this step is rarely significant to overall performance.

  • Step 6: Processing Updates To Content That May Result In New Indirect Retention Category Assignment (q)

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.

Performance: Changes that result in a new Indirect Retention Category Assignment are rarely done in significant volume. This step will update objects in M-Files that have changed and performance will likely be between 2-3 objects per second. This step leverages M-Files task queues and will create multiple tasks based on the Task Queue Optimization settings in AutoRecords.

  • Step 7: 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 Event objects that reference the 7 year period and recalculate all dates to use the 10 year period.

Performance: Changes that result in a new Indirect Retention Category Assignment are rarely done in significant volume. This step will update objects in M-Files that have changed and performance will likely be between 2-3 objects per second.

  • Step 8: 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.

Performance: Depending on the Action that is being executed there may be updates or deletes to objects in the vault at a rate of between 2-3 objects per second. In general, it is rare to have Hold Conflicts in a volume that will impact overall performance.

  • Step 9: Processing Events That Have Not Yet Triggered (q)

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.

Performance: This step will update objects in M-Files that have changed and performance will likely be between 2-3 objects per second. Aside from an initial run of AutoRecords where many documents suddenly qualify or significant dates such as year end or fiscal year end, it is unlikely that the volume of changes will significantly impact AutoRecords performance. This step leverages M-Files task queues and will create multiple tasks based on the Task Queue Optimization settings in AutoRecords.

  • Step 10: Processing Events To Create Actions (q)

This step evaluates all existing Events and Event Groups. Where the Event Date has been met, the Action associated with that Event Group gets executed. For Direct Actions, the Action is executed directly against the file. For Workflow Actions an Action object is created to carry out the Action for the object(s) associated to the Event or Event Group.

Performance: This step performs the disposition Actions associated with files and objects on the system and as a result is issuing updates and deletes to many files. Performance will likely be between 2-3 objects per second. If deleting or updating large numbers of objects, this can be a time consuming step.

  • Step 11: 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.

Performance: This step will update objects in M-Files that have changed and performance will likely be between 2-3 objects per second. Since this step is deleting old versions of a document, there are rarely enough updates to dramatically impact performance.

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

Performance: This step deletes Action objects from the system and performance will likely be between 2-3 objects per second. It is only impactful when using Workflow Actions. There will generally be one Action object for each file or object processed. Since this is deleting objects, performance will depend entirely on how many objects need to be deleted. Performance can be increased by using Direct Actions which avoid this step.

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

Performance: This step deletes Event & Event Group objects from the system and performance will likely be between 2-3 objects per second so overall time will depend entirely on how many objects need to be deleted. Since a single Event Group can be related to many files and/or objects, there will rarely be enough Event Groups implemented for this step to impact overall performance.

  • Step 14: Processing Orphaned Conflicts To Clean Up

This step removes any Conflict objects that AutoRecords created which are no longer needed or no longer reference an object on the system.

Performance: This step deletes Conflict objects from the system and performance will likely be between 2-3 objects per second. Overall time will depend entirely on how many objects need to be deleted. Since there are rarely large numbers of Conflicts, there will rarely be a significant impact overall performance.

  • Step 15: Processing Orphaned Indirect Retention Categories To Clean Up

This step removes Indirect Retention Categories that are no longer needed because the objects they were associated to have been manually removed.

Performance: This step deletes Indirect Retention Categories from the system and performance will likely be between 2-3 objects per second. Overall time will depend entirely on how many objects need to be deleted. Since there are rarely large numbers of orphaned Indirect Retention Categories, there will rarely be a significant impact overall performance.

  • Step 16: Processing Orphaned Event Groups To Clean Up

This step removes Event Groups that are no longer needed because the objects they were associated to have been manually removed.

Performance: This step deletes Event Groups from the system and performance will likely be between 2-3 objects per second. Overall time will depend entirely on how many objects need to be deleted. Since there are rarely large numbers of orphaned Event Groups, there will rarely be a significant impact overall performance.