Overview of Content Lifecycle Policy Processing

When a Content Lifecycle policy is created or edited, there are several aspects to consider concerning the backend processing of that policy.

Initial Policy Processing

During initial policy processing, the system looks through all files in the associated content sources for files that match the criteria specified in the policy. The policy will not affect any files until the initial processing is completed.

The length of the initial scan will depend on the size of the dataset, which includes both files in active storage and files in the Trash.

While the initial policy scan is in progress, there will be a hover-over status that will provide you with information, including:

• Time the policy scan was initiated
• Total number of objects scanned
  • This number may far exceed the number of files in your system. This is because the policy scan is done at a version level, not just a file level, and also that objects that were scanned once and then moved to the trash may be scanned again when the policy scans the trash.
• The last time number of objects scanned was updated
• Which content sources are included in the policy
• Which types of criteria were included in the policy.

Policy Changes

There are two basic kinds of changes you can make to a policy - you can change the criteria the policy is looking for (classification and/or included folders the policy will match), or you can change the actions the policy is taking (e.g., change retention period).

• If the criteria are changed, the policy will do a full rescan to identify which files match the updated criteria.
• If the actions are changed, then it will modify the specified actions on files that have already been identified as matching the policy, and no rescan is necessary.

Whenever a policy is changed,  all policy types will affect matched files during the recalculation process as they are identified. If a rescan is not necessary, new actions will begin as files are updated with the new actions.

Policy Limits

While there are no limits to the number of active policies that can be created, you can only create five draft policies. This limit exists to prevent a large number of draft policies from negatively impacting the performance of active policies.

Retention Guard

During the initial policy scan, or if a policy rescan takes more than 8 hours to complete its initial processing, the system will prevent any files from being purged from the trash until the processing is completed. This safeguard was put in place to ensure that no files can be purged while a policy is still identifying which files need to be retained, preventing accidental or malicious purging of files that a policy will retain once completed and fully active. Retention Guard will be enabled regardless of whether a policy is draft or active.

Exported Policy File Date Information

When you export the details of a Content Lifecycle policy, there is information about each file, including the created date, last accessed date, and expected trigger date.

• Created Date - The date that the current version of the file was created (matches Modified Date in Collaborate)
• Last Accessed Date - The date the last time the file was Viewed, Downloaded, or Locked
  • Only files locked by the Desktop App will update last access; locking via the web interface will not.
• Expected Trigger Date - The date of the oldest version of the file that will be affected by the policy

Since in Collaborate, you can only access the current version of a file, and you need to make an older version of the file current if you want to use it, the Last Accessed date in Secure & Govern will always be for the current version of the file. Because of that, in combination with Content Lifecycle policies processing individual versions, the expected trigger date may seem older than it should be based on the last accessed date because it shows the date of the oldest version that will be affected.

In order to provide visibility into Content Sources that are available in the Content Lifecycle view, the Egnyte backend systems need to scan all of that content initially and perform periodic update scans to identify changes. Because of this, there can be occasions when the dates seem out of sync in the export data (for example, the last accessed date has been updated, but the expected trigger has not). In these situations, it is only the export data out of sync, the actual trigger date is correct, and the file will be processed as it should be. In most cases, waiting some period of time and rerunning the export will provide accurately synced results.