Skip to main content

Best Practices

Initial AutoRecords Implementation​

No two organizations are the same, but in general the bulk of the "effort" in an AutoRecords implementation involves rationalizing the way the organization currently defines retention policies against what is needed to configure AutoRecords. It is common to come across rules within the organization that identify documents in a way that is different than the metadata currently configured within your M-Files vault. For example, we may have stored Invoices on M-Files without an Invoice Date, but retention for Invoices is driven based on the Invoice date. In that case we need to add the Invoice Date to the metadata of the Invoice in M-Files to drive retention.

The following sections walk you through the process of implementing records management using AutoRecords.

Set Up A Test Environment​

Ideally before there is any work done, a separate M-Files vault should be configured for testing and configuring AutoRecords. This environment provides a place for a Records Manager to validate configurations, make changes and perform tests without impacting production data. Once AutoRecords is configured in the test vault, a Content Replication & Archiving job should be set up to push the AutoRecords configurations from the test environment into production. Equally as important is a Content Replication & Archiving job to synchronize objects, metadata, value lists, etc. from Production to the Test Environment.

Create A File Plan​

Define A File Plan Some organizations already have a list of Retention Policies or a "File Plan" in place. A File Plan generally states the types of documents within an organization and the retention that should be applied to those documents in easy to understand terms that people in the organization are familiar with. Don't worry about AutoRecords at all at this point. Developing this File Plan is often done on a spreadsheet with a column for the type of document along with other columns for retention periods and things like department. Establishing a File Plan is the first and most important step.

Define Retention Criteria As you review the File Plan you will notice criteria for retention or perhaps a lack of criteria. Your File Plan will likely have a column indicating how long you should keep something (ie. 10 Years). The important question to ask is "10 years after what event?" When do we start counting to get to 10 years? Is it 10 years after the file is created? Is it 10 years after a Project is Complete or a Client becomes Inactive? For each entry in the File Plan we have to know what the criteria is to determine when we should start the clock ticking. This information must be added to the File Plan.

Define Retention Categories/Patterns The File Plan will also reveal patterns of retention or "categories" of retention. For example, you may notice that you keep many things 10 years after the obsolete date or 5 years after Project Completion. In general a "category" of retention is a combination of a period of time and some criteria (i.e. 10 years after obsolete). Make a list of these patterns or categories. While your file plan may have hundreds of entries, you'll find that you have far fewer "categories" of retention.

Reconcile The File Plan To M-Files​

The next step is to update M-Files so it contains information that is consistent with the File Plan or change the File Plan to reflect what is in M-Files.

Document Classes & Types For each type of content identified in the File Plan you must have some way of identifying content of that type within M-Files. Add a column to the File Plan to indicate the Document Class associated with the content. Add a second column to indicate any additional criteria necessary to indentify the content. For example, in some vaults, Invoices may be under a Document Class of Invoice, but in your vault they may be under a Document Class of Financial Document and there's an additional metadata property called Document Type that is set to Invoice. In your File Plan add any additional criteria necessary to accurately filter out Invoices from the rest of the Financial Documents. AutoRecords can use any combination of Document Class and available metadata to correctly identify content.

Retention Criteria In some cases it is likely that the retention criteria defined in you plan doesn't exist in M-Files. Add a column to your File Plan and for each retention criteria defined make specify the M-Files property or properties that represent that criteria (i.e. Invoice Date, Obsolete Date, Project Status).

Update M-Files & Configure AutoRecords​

The next step is to update M-Files to contain any new document classes and metadata necessary to support the File Plan that has been defined. This must be done with careful thought and testing. Consider the impact the changes may have on security, workflows and metadata cards and how those changes may also impact business processes external to M-Files.

Configure AutoRecords​

With M-Files updated to include the necessary document classes and metadata, using the information from your File Plan you can now begin configuring AutoRecords objects. Please reference the detailed documentation for each AutoRecords object. At a high level you will be configuring the following:

  • Policy (The retention policy)

    • Retention Category (The disposition to perform)
    • Document Classes (The document and/or object classes to include in the policy)
    • Trigger (Criteria to limit within the document/object class which items to include in the policy)

  • Retention Category (The dispsition to perform)

    • Event Template (The disposition actions)
      • Trigger (Criteria to determine when the Period begins)
      • Period (The time period to wait before performing disposition)
      • Action (The disposition action to perform, usually the pre-defined Actions that come with AutoRecords will suffice and it isn't necessary to create additional actions)
info

Triggers and Document classes work independently. You do not need both but you must supply at least one.

Configuration Names​

The names you assign to objects in AutoRecords can make managing your configurations significantly easier in the long term. The following tips may be useful.

Be Consistent: Above everything else, be consistent with your naming conventions AND how you configure your system. Since AutoRecords is very flexible, it can be configured in a number of ways. It also doesn't require daily intervention, so once configurations are in place it is very common to rarely ever touch them again. Being consistent in your approach to configuring the system and with your naming conventions will eliminate the need to "remember" why something was set up one way vs. another.

Below are some guidelines for setting up names (NOTE: Trigger and Period names are set automatically).

Policies- The names should reflect the type of content as well as the disposition of the content. For example: "Delete Safety Documents 1 Year After Obsolete"

Retention Categories- The name should reflect the Events that are going to occur. Importantly, since the same Retention Category may be used in many policies, it's best NOT to include the type of content unless the retention category is ONLY to be used for that one type of content. For example, "Delete 1 Year After Obsolete" may be used by many Policies. It is VERY likely that the name of your Retention Category will be the same as the name of your Event Template. The exceptions are those cases where a Retention Category schedules multiple events, for example, "Restrict to RM Permissions after 1 year and Delete After 2 Years."

Event Templates- The name should be a combination of the time period, trigger criteria and action. For example "Delete 1 Year After Obsolete." This will often match the Retention Category name.

Assign Policies Only Once For Each Object​

Often a document will have a complex lifecycle. With AutoRecords flexibility it can be tempting to assign different retention policies at different points in the lifecycle of a document. Avoid doing this. Instead, think of the document as having a single retention policy and schedule multiple events.

For example, let's assume there is a Product document class that starts life as a Proposal but may turn into an Approved Product document. There may be many Product Proposals, but only a few get turned into the Approved Products. Let's also assume our organization keeps Product Proposals for five years and Approved Products for seven.

In this case it may be tempting to set up two separate Policies and have AutoRecords change the Policy based on whether the Product gets Approved. While that works, there's a better option. Set up a single Policy for all Product documents and use a Retention Category that can has two Event Templates. The first Event Template would be "Delete Product Proposals After 5 Years" and the second would be "Delete Approved Product Proposals After 7 Years."

This approach seeks to keep the Policies simple and put the complexity of document level criteria and exceptions in the Retention Category. When it comes to reporting, viewing upcoming events and schedules, this will be slightly easier in the long term. Another consideration is that many implementations choose to only show end users the Policy and hide other AutoRecords properties such as Retention Category. Consistent application of the Policy and not having documents change policies provides a more cohesive end user experience.

Responding To Workflow States​

Documents and objects in M-Files often go through workflow and it is common to want to have a workflow state trigger AutoRecords retention. For example, a Budget may go through a process of Draft, Review, Approved, Active and end its life in a state of Archived. We may want AutoRecords to keep Budgets a number of years after they enter the Archived State.

While the first thought may be to create a Property Trigger over the workflow State property and respond to the change of the State, it's best to avoid this approach. Instead, set up a value list for Record Status that can be used across the system for any object in any workflow. In the example above we might add a value of Archived Budget to our Record Status value list. We might also have values for other documents and objects in the Record Status list such as Obsolete Invoice and Inactive Employee.

When the Budget document is in workflow and it hits the Archived State, set the metadata property Record Status to Archived Budget. In AutoRecords we would set up a Property Trigger for the Record Status Equal To Archived Budget. AutoRecords can then respond to that trigger criteria and effectively drive retention based on when the Budget hit the Archived state. Using metadata card rules, it's advisable to create a rule where the Record Status is set to Read Only and it can optionally be Hidden from users.

The reason this approach is preferred instead of setting up a Trigger over the State property is due to how M-Files deals with workflow restrictions. At a high level, workflow state is just another M-Files select list property. For AutoRecords to respond to a select list property we would create a Property Trigger, specify the property and then since it's a select list, we must add that property to the metadata card and select the value we want to use for the Property. For the workflow State property, it's already on the metadata card. To select the State value we want to use, we must first specify the workflow that has the state. In this case it would be the Budget workflow. This is where we get into trouble. We need to have the Trigger object in a Budget workflow.

When configuring a workflow in M-Files you can limit the workflow so it can only be used with a single object type OR you can have it unrestricted so the workflow is available to all object types. There's no way to configure a workflow so it's enabled for two object types such as Budget and also Triggers while excluding all other objects. The end result is that in order to set up a Trigger over the workflow State property, the workflow has to be available to all object types. In most implementations, workflows are purposely restricted to a specific object type so this approach creates problems.

Using Properties Filtered On Class For Triggers​

M-Files allows you to set up Properties which select from values and apply filters. For example, you may have a Document Type list that is filtered based on Class. When the document class if Financial Document, the Document Type property might contain Budget, Invoice and Audit. When the Document Class is HR the Document Type might contain, Tax Document, Review and Resume.

Since Document Type is a select list, an AutoRecords Property Trigger will need to reference that Property to get its exact value. The Document Type Property must be added to the metadata card and the value for the trigger must be selected. Since Document Type is filtered based on Class, the drop down will have no values because it's filtering based on the Property Trigger class. While it's tempting to simply add Document Type Values to the Property Trigger class, that will not work. The values are associated with an ID behind the scenes, so it's not the name that M-Files uses, but the ID of the name (1=Budget, 2=Invoice, 3=Audit, etc) M-Files is storing the number, not the name.

For AutoRecords to have a Trigger based on Document Type=Budget, what we really need is not the word "Budget" but ID# 1 which has a label of Budget. The work around for this is to go into the Admin utility and temporarily turn off filtering for the Document Type property. Then go back into the Trigger and select the value you want from the list and save the Trigger. The Trigger is now pointing at the correct ID. Finally go back into the Admin Tool and turn filtering back on for the Document Type property.

To avoid doing this in production environments, it is strongly recommended that changes are made in a Test environment that has been sycnrhonized from Production and then push those values over to Production. This way filtering is never turned off in the Production environment.

Expiring Holds vs. Deleting​

A Hold in AutoRecords, will prevent a document from being processed. Often Holds are used to flag selected documents that are part of litigation or audits and make sure the document is not removed from the system until after the litigation or audit is complete. There are two ways an object can be updated so it is no longer on Hold.

The first way to expire the Hold but leave it on the document for reference. This may be helpful as a historical reference in cases where AutoRecords is supposed to assign objects for review but due to a Hold the processing was delayed. The Records Manager can easily see that the object was on Hold and when the Hold was no longer in effect.

The next way to remove a hold is to use M-Files features. The Hold property can simply be cleared out for an object and the object can be saved. While the Records Managers loses visibility to historical Holds, the advantage to this method of removing Holds is that M-Files permissions can be configured to restrict access to the object when the Hold property is populated.

Records Manager Permissions & Views​

AutoRecords has been designed so the person who is configuring AutoRecords does not need to be an M-Files Administrator. There are some installation steps where Administrator permissions are required, however, all Records Management configurations are done in M-Files. It is recommended that the Records Manager is someone within the business who is responsible for enforcing retention policies. The Records Manager should be added to the M-Files User Group: Records Managers. The main AutoRecords view should be changed so the Records Manager can access it along with others in the organization that will be making configuration changes.

caution

All AutoRecords Views and objects use standard M-Files Permissions and have NOT been restricted by default.

Direct Actions vs. Standard Actions​

Direct Actions are the preferred option for AutoRecords Actions unless you have a specific reason to use Standard Actions. Direct Actions execute faster and require fewer system resources which makes them preferrable. Instances where you will need to use Standard Actions include

  • All Assignment Actions (i.e. Assign To Policy Owner).
  • Any Action where you need to implement a customized workflow.
  • If you want to archive and export Action data to some other database.
info

You cannot extend or customize Direct Actions since they are tied directly to M-Files system functionality.

Physical Records​

Physical Records are implemented as "non document objects" in M-Files. M-Files objects are used to represent boxes, folders, etc. Retention works the same way with destruction ultimately being an "assignment" to someone to perform the destruction. When implementing Physical Records it is best to keep numbering and labels separate from electronic records. For example, if retention categories are numbered in the hundreds for electronic records start at 1000 for physical records. Likewise if your Retention Categories are named "Delete Invoices After 10 Years" for electronic invoices, but you also have paper invoices, you will need a separate retention category for the physical records to "Destroy Invoices After 10 Years." Using "Destroy" for physical items and "Delete" for electronic items helps clarify the purpose of the Retention Category. You could also prefex the name with "Physical Record - Destroy Invoices After 10 Years." Regardless of what you choose, having a way to differentiate physical vs. electronic retention categories will be useful.

Beyond naming, Physical Records often have a check-in and check-out library function. You can use the M-Files Check-In and Check-Out against the object to provide this functionality.

Finally, each Physical Records implementation seems to be unique. TeamIM has a library of customizations available to help tailor the Physical Records experience to best meet your needs. When implementing Physical Records, we strongly recommend a brief meeting to discuss "the art of the possible" based on your needs and what is avaiable.