Expiry Compliance Policies allow regular checks to be run on any workspaces managed by ProvisionPoint. The rules can be configured to report or notify owners or admins about activity or inactivity or perform action to extend or reduce the expiry date for items that have a lifecycle policy applied.
- Example 1, if a project Team or Site has not been modified in the last 60 days, run lifecycle policy today to archive then delete
- Example 2, if a project Team or Site is still active (messages being sent, site being accessed and documents being modified), extend the expiry date by a number of days.
- Example 3, use the report and notify rules to monitor all workspaces in ProvisionPoint for activity and manually make changes if there is no lifecycle policy
Whatever your reason, the Expiry Compliance Policies allow ProvisionPoint app managers/admins to configure what activity is for your organisation, when it will be updated and whether the expiry date should be shortened, extended or changed to a set date using transformation tags.
Before you begin to look at the configuration, we urge you to spend some time understanding what options are available in the app and what you want to achieve.
Once you know what you want to achieve, you can start creating rules and policies that will get the desired results.
Important Questions to consider:
When will an Expiry Policy run?
When a compliance policy is created, one of the first options is when will it run. A schedule can be defined at either the policy level or can be overridden when adding to a Service Definition. As the expiry policies also link to the lifecycle, it will also be checked before reminder emails are sent and on the expiry date to ensure that the date is not going to change. A reminder will not be sent if the policy would extend it.
Choose if the policy will check every workspaces on the same day each week or define the checks to be set monthly, buy checking every 30 days.
How many can be configured?
Only one expiry policy can be added to a Service Definition. If there are different needs for different service definitions, multiple Expiry policies can be created.
Use rulesets where needed to group the rules, as well as prioritising the order of the rules, ensuring the most important is run first.
What activity can be checked?
There are several rules for Expiry policies, and the following are currently available, decide what means activity to you. A combination of these rules may be required:
|
Rule name
|
Details
|
|
Site Last Modified
|
Checks the last modified date on the site.
Covers add, edit and delete actions on items and documents in lists and libraries.
|
|
Site Accessed
|
Checks if the site has been accessed using the activity logs.
Covers viewing site pages and documents in libraries.
|
|
Site Accessed Daily Counts
|
Checks the activity logs to get the total number of actions performed on the site along with the total number of users on a daily basis.
Covers viewing site pages and documents in libraries.
|
|
Site Accessed Past Seven Days Count
|
Checks the activity logs to get the total number of actions performed on the site along with the total number of users over the past seven days.
Covers viewing site pages and documents in libraries.
|
|
Team Channel Activity
|
|
|
Delegated
|
Sets the expiry date based on the preceding Expiry rules. This allows you to enforce a change when all preceding rules are true.
|
When should the check be run?
A schedule is set on each compliance policy, this may run weekly or monthly (you decided this earlier). If you have just created a Team or Site for a project it is going to be active.
So running a weekly check on the new project could mean it starts to extend immediately. It may be preferable to say only check projects in the last month of the project
For each rule, add a conditional check to determine when the policy should be checked. The policy will only run if it meets the conditional check.
In the image above shows a condition is set, when the expiry date is less than 30 days from now the policy will run, we use Now.AddDays(30).
This meets our requirement for the last 30 days of a project
The number of days configured can be adjusted to meet your organisation needs.
This may also be a requirements for any rules that follow.
For example, you have two rules setup checking for different activity, the first rule will look at when a Site was accessed and it extends the expiry date by 7 days.
The following rule looking at when a site was modified (with no conditional check) will also extend by 7 days. Either use a conditional check that looks for Expiry Date > Now.AddDays(7) on the 2nd rule to only run if the expiry date is greater that 7 days. Alternatively use delegated rules if both rules must be true to extend.
Which rule should run first?
Our previous subject leads us directly to which rule should be run first.
This is an important consideration, are you more interested in the files being accessed or modified?
If it is a Team are you more interested in the channel activity. Decide as a company what the preference is and set the rules accordingly.