This content has been marked as final. Show 6 replies
That's actually relatively easy to fix.1 person found this helpful
To recap, you want to remove content based on the later of one of two conditions:
- The content is "stale" by virtue of creation date occurring 5 years ago.
- The case with which the content is associated is "closed" on a given date.
First, create two date fields in Configuration Manager. One field will hold the stale date (which I'll elaborate on in a bit) called "xStaleDate". The other field you probably already have, "xContractClosedDate".
Second, go into Records-->Configure-->Retention-->Triggers. On the Custom Direct tab, create a new trigger called "ContentEitherStaleOrClosed". Provide a description for the trigger. In the "Record Date Field(s)" box, enter "xStaleDate, xContractClosedDate". Save and exit.
Third, in the category that calls for this condition, change the disposition rule to use this new trigger, removing the other triggers. You should now not have a need for the records folders to segregate the content in the category.
Let me explain now what this new trigger does and how it works. This trigger will not fire until the date value in both fields (xStaleDate and xContractClosedDate) has passed. If one date field or the other is blank, this trigger never fires, and the content stays in place as desired. Both fields could have values, but unless both dates have actually passed, there is no action taken. It's this property we will exploit to address your issue.
The issue now is that a user must complete both date fields in order to send the content item into disposition. Ideally, the only field a user should ever have to complete is the contract close date. What you can do (and should do) is create a global rule that fills in the stale date. (You can't simply use the create date or release date for this trigger. Remember that 5 years must be added to the create date or release date to compute the "stale" end date.) You can create a global rule that completely hides the field from the user, and for new checkins sets the default value of xStaleDate to "<$dateCurrent(1825)$>" which computes to 5 years from "now". If you have needs for varying lengths of "stale" time, say 7 years instead of 5, you now have a mechanism to easily change that calculation.
Since the stale date is now already populated on checkin, the user can go in later, and only fill in the contract closed date. Both dates are now available for proper calculation, and this task is complete until both dates pass.
There was a patch that needed to be applied. Multiple criteria can be added, but they were not being executed. After the patch, when setting up a category with multiple dispositions, each of the dispositions executed correctly.
Ah we're still having issues. Here's what we want: the longer of five years after check-in OR when a "closed" date is set. Every way we've tried, as soon as the closed date is set the content item gets removed even though the second disposition date is still out in the future. Any ideas?
Still not working unfortunately. See post.
I'd have to see the entire disposition instruction set definition for the category. It sounds like you have multiple trigger events defined like
- After: Closed
- Wait: now
- After: Checkin
- Wait :5 years
- After: ContentEitherStaleOrClosed
- Wait: some period
and therefore, the closed trigger is satisfied, since the closed date is filled in. That would be the correct behavior, because the closed trigger just cares about the one date for satisfaction.
That's not the setup that I laid out in the earlier post. As stated earlier, you'll only have the one single trigger "ContentEitherStaleOrClosed" for the category, which is defined using two date fields, and you have to get rid of the other triggering conditions.
If both dates are not populated, the trigger condition is NOT met, can't fire, and the item cannot enter disposition. If you have items in records folders under the category, make sure you correctly apply the rules to the folders as well. Since you were using folders to break up this processing step before, you should probably take the items out of the folders, and put them directly into the category.
I know this setup works, I tested it before I posted the answer, and have used this approach numerous times previously. If you've defined the trigger as I've described, and it's still broken, this sounds like a bug.
We were able to get your implementation to work and it's certainly an interesting and useful approach. Ultimately we chose to simply set the Approve Delete date as a result of the first trigger and then have a second trigger which uses that date. That configuration avoids the need to go in and maintain the scripts as changes to the plan occur over the years.
Thanks again for all of the help William.