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 need to be indexed and crawled by SharePoint for MetaShare Orbit to manage them.

Rules also have a state (Draft, Published, or Inactive). To make a rule executable it first 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 and by default only Published rules are shown (unless you select to change the page’s filters on the top of the 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 draft rule and then clicking on the “Remove” function.

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 later publish them.

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

Details about the form

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

Beneath you find more details about each and one of the fields in the form:

1. Input mode – you can choose between these two options:
   1. “Simple” mode – you can create a rule that triggers on the documents’ age (calculated from the documents’ last modified time) and a combination of tags that the documents are tagged with (terms from SharePoint’s term store).
   2. “Advanced” mode – you can write an advanced query condition that triggers on any attributes that the documents have. For instructions on how to create Advanced rules, go to this page: How to write advanced query conditions.
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. Term based conditions:
   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 term store’s 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 (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]:
      
4. The “Test rule” button:
   1. If you click on the button, a new window will launch displaying the number of documents that match the rule, in which sites they reside in as well as a table with a list of all the documents that match the rule:
      
   2. The files that are listed in the report window are all documents that the MetaShare Orbit app has permission to see (which are all files in your Microsoft 365 tenant).
   3. From the report window you will also be able to export the result-list to a csv-file, by clicking the “Export to csv” button on the top of the window. Apart for the columns that are shown in the report window, the exported file will also have these columns: Created & Modified. From this file you can analyze the results more thoroughly before deciding to publish the rule.
5. Action – you can choose between these two options:
   1. “Move”:
      1. If you select “Move”, you will need to select a value in the “Destination library” field. 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:
         
      4. Moved documents will maintain all the tags they had in the source location. The first time that a document is moved, of a certain content type or with specific local metadata values, MetaShare Orbit first needs to attach the content type to the destination library and/or locally create any missing metadata columns. 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 or local columns have been created, the documents 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 initial source location.
         • If a document’s source path was: “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.
   2. “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 to be deleted and periodically review these documents before they are permanently deleted.
   3. Once you have saved a rule, you will not be able to change the action (Move or Delete).
6. 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 have high priority will execute before the ones with low priority.
7. Description:
   1. Use this field to write any comments about the rule, to make it easier to understand why the rule is created.
8. State:
   1. The options are Draft, Published, or Inactive.
   2. The default value for a new rule is “Draft”.
   3. For a rule to execute, its state needs to be changed to ” first needs to be p”Published”.
   4. 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, its status can just be changed to “inactive”.​

Note

1. If your term store is configured to manage multiple languages, then, in the “Term based conditions” field, you will only be able to search for terms in the term store’s default language.
2. If you, in the “Term based 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 applied draft item security on a specific document library, only the published documents will be crawled by SharePoint. So MetaShare Orbit will in this case not manage draft documents that never have been published to a major version. The properties of a published document’s latest draft version might also not match a rule’s conditions as SharePoint search is only aware of the latest published version, whose properties might be different from the latest draft.