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. Archival and retention policies will affect any matched files during the initial processing as they are identified. Deletion policies will only affect files once the initial policy 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 the following information:

• Time the policy scan was initiated
• Total number of objects scanned
  • This number may far exceed the number of files in the 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

Archival policy actions

For archival policies, files are acted on in 3 stages:

1. Copying files to the archive destination

Files (and versions) are copied to the archive destination starting 7 days from the target date identified by the policy. For example, a file created on 1/8/24 that is supposed to be archived a year after creation would be copied to the archive destination starting on 1/1/25. This is to ensure that the archival process has time to finish before the target date.

2. Creating stub files

If a file and all versions have been completely copied to the archive destination so that no versions will remain in the original location, a stub file will be created in that original location at the time of the target date. For example, in the example above, the stub file would be written on 1/8/25.

3. Deleting the file from the original location

Once the file is copied and any necessary stub files are created, the file (and versions) will be moved to the Trash. Files and versions will not be moved to the trash until the other 2 processes are completed.

 

Policy Changes

There are two types of changes that can be made to a policy: 

• Modifying the criteria it evaluates(such as classification or included folders).
• Adjusting the actions it takes(such as altering the 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, only 10 draft policies can be created. 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

Exporting the details of a Content Lifecycle policy provides 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

In Collaborate, only the current version of a file is accessible. To use an older version, it must be made current. As a result, the Last Accessed date in Secure & Govern always reflects 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.