How to manage your document lifecycle rules

In short, rules have conditions (tags and age) and if a condition is met, an action will be triggered (delete or move).

The documents’ rule conditions are checked using SharePoint’s search engine. Documents and their properties therefore have to be visible in SharePoint’s search results.

Rules also have a state (draft, published, or inactive). To make a rule executable it needs to be published. To maintain traceability of why certain documents were moved or deleted by a certain rule, a rule that at one point of time has been published cannot be deleted, nor can its conditions be altered, it can just be inactivated.

Rules are listed on this page:

From this page you can:

  1. Add a rule, by clicking on the “Add rule” function.
  2. Edit a rule, by selecting an existing rule and then clicking on the “Edit” function.
  3. Remove a rule, by selecting a rule and then clicking on the “Remove” function.

When you create a rule, the rule’s property form will be shown on the right pane:

Detailed descriptions

  1. Rule condition:
    1. In this mandatory field you select one or several tags that documents must be tagged with, for the rule to trigger.
    2. A tag is a term that is defined in SharePoint’s term store. It can reside in any of the available term sets.
    3. To find a term, just type in the term’s name (default label or other labels) and while you type you will see a list of all the terms that start with the word you are writing. You can select a term in the dropdown either by using your keyboard’s up and down buttons and then select an item by hitting the Enter key, or you select a term using your mouse.
    4. In the drop down, tags are displayed with their default label and under the tag, with smaller characters, you see the term’s path (which term group, term set and parent terms the term belongs to:
    5. The tags that have been selected for a rule condition are stored in MetaShare Orbit with the term’s unique identifier (a GUID), so if a term’s label is renamed, the rule will show the new label and still trigger on the specific condition.
    6. If a term, that is used in any of the defined rules, later is deleted, the term’s GUID will be shown and beneath it the following will be written: [The term is not any longer available in the term store]:
  2. After (Days):
    1. A rule will trigger on documents that are older than the number of days that you specify.
    2. The age of the document is counted from the documents’ last modified date.
    3. The value should be within the range of 1 (1 day) and 3650 (10 years).
  3. Action:
    1. The available options are Delete or Move.​
    2. If you select “Move”:
      1. Then a new mandatory field, Destination library, will be shown in the form. This field shows all Destination libraries that are defined in MetaShare Orbit’s settings. The normal use case is to only have one destination library but if needed you can define more.
      2. Documents that match the rule’s condition will automatically be moved to the selected destination library.
      3. The moved documents’ version history will be intact but the actual number of versions that will be moved might be restricted by the versioning settings in the destination library. In this case, only the latest 100 major versions will be moved:
        Versioning settings
      4. Moved documents will maintain all the tags they had in the source location (a prerequisite is that the tags are assigned through a content type that is created and published in SharePoint’s content type hub). The first time that a document is moved, of a certain published content type, MetaShare Orbit first needs to attach the content type to the destination library. As documents are queued to be moved before the content type is in place, you could end up with a few errors (documents failed to be moved). As soon as the content type is attached, documents of that content type will be able to be moved, so the documents that failed during the first move operation will eventually be moved during the next run.
      5. In the destination library, the documents will be stored in a folder structure that corresponds to their source location.
        • If a document’s source path is “https://contoso.sharepoint.com/sites/general-documents/shared documents/client documents/Octan”, where:
          • “general-documents” is the source site,
          • “shared documents” is the document library in the source site and
          • “client documents/Octan” is the folder structure in the document library.
        • Then the document’s destination path will be “https://contoso.sharepoint.com/sites/document-archive/shared documents/sites-general-documents/shared documents/client documents/Octan”, where:
          • “document-archive” is the destination site,
          • “shared documents” is the document library in the destination site,
          • “sites-general-documents” is a folder that relates to the source site,
          • “shared documents” is a folder that relates to the document library in the source site and
          • “client documents/Octan” is the folder structure that relates to the document’s folder structure.
        • As the documents are stored in folders, corresponding to their original source locations, then, if needed, you can set permissions on the folders in the destination library, so that they match the permissions that the documents had in their source locations (probably only giving them read permissions), thereby maintaining control over access-rights.
    3. If you select “Delete”:
      • Documents that match the rule’s condition will automatically be deleted (moved to the site’s recycle bin, where they will be available for up to 93 days).
      • If it feels scary to automatically delete documents, you could instead define a “Move” rule that moves the applicable documents to a specific destination library for documents for documents to delete and periodically review these documents before they are permanently deleted.
    4. Once you have saved a rule, you will not be able to change the action (Move or Delete).
  4. Priority:
    1. Two or more published rules could have conditions that match one or more documents.
    2. To prevent rule-conflicts, you can set a priority, between 1 and 9999.
    3. The rules will execute in priority order (from highest to lowest), so the rules that are prioritized will execute before low priority rules.
  5. State:
    1. The options are Draft, Published, or Inactive.
    2. For a rule to execute, it first needs to be published.
    3. To maintain traceability of why certain documents were moved or deleted by a certain rule, a published rule cannot be deleted, nor can its conditions be altered, it can just be inactivated.​

MetaShare Orbit logs when a rule is created or modified and by whom. “Modified by” is shown as a column in the rules list but if you edit a rule, you will be able to see all this information, in the bottom of the form, under the “Submit” button:

A recommendation when setting up the rules is that you first create all rules as drafts and when they are created, you or someone else can publish them.

Note

  1. If your term store is configured to manage multiple languages, then, in the rule conditions field, you will only be able to search for terms in one language. The items that are shown in the dropdown will however be displayed in the language that you have as the default language in the term store.
  2. If you, in the rule conditions field, search for a term and do not find any matches, you will still see items in the dropdown that match the initial characters that you wrote in the field.
  3. If you have configured a document library with draft item security then only published document versions will be visible in SharePoint’s search results. The properties of the latest draft of a document might match a rule’s conditions but SharePoint search will only be aware of the latest published version, whose properties might not match the rule’s conditions.