Using The Information Management Policy (Specifically The Retention Policy) In SharePoint 2010

The Information Management Policies feature of SharePoint 2010 has some interesting potential in a few ways I hadn’t imagined. I was familiar with setting retention actions to delete, recycle, or move items after a certain time period had passed, but I somehow wasn’t aware that I could also trigger a workflow. I also wasn’t aware of the recurrence option that would repeat the retention action until the next stage was triggered. In other words… would this feature allow me to run nightly/daily/weekly workflows on a list or library option?

To set up a test, I created a custom list with a couple of columns that I could update via a workflow. It contained the title of the list item, a Date Condition column that I would use to trigger the retention policy, and a date the workflow agent was triggered (it would be updated in the workflow):

The workflow was very basic… Whenever it was triggered, it would update the Agent Triggered Date column with the current date/time, and send out an email to the person who created the item:

I then created the Information Management Policy for this list item:

The trigger for this retention policy would be when the current date was greater than the Date Condition column plus 0 days:

Side note: It is highly recommended that you associate Information Management Policies with specific content types, not just a generic Item content type. For test purposes, this list only has the one Item content that it’s using, so I didn’t create a different content type for it.

There are two timer jobs that interact with the Information Management Policies. The first one, titled Information Management Policy, is set by default to run weekly on Friday at 11 pm. It goes through libraries that have policies and figures out if the event portion of the policy is a true condition. If so, it will then set the stage for the second timer job to run against the action portion:

The second timer job is Expiration Policy, and that’s what allows the action portion to run. It’s set by default to run weekly on Saturday at 11 pm:

The two workflows need to run in that order. If you were to just run the Expiration Policy timer job, nothing would ever trigger because the event wouldn’t be set. If you run just the Information Management Policy timer job, then the action will never run (even though the event was true).

First Test Run

My first test run involved triggering an Information Management Policy that did not use recurrence. I used the Run Now feature of the Information Management Policy timer job to run that, then waited approximately 15 minutes and used Run Now on the Expiration Policy timer job. Within approximately 10 minutes, I received my email, showing that the policy had triggered.

I then ran the two timer jobs again, wanting to see if this would re-trigger the email. It does not, as without recurrence the Information Management Policy will only be applied to the document once.

Next Experiment – With Recurrence

My next experiment involved adding recurrence to the Information Management Policy. The question to be answered was whether or not the workflow would continue to run every time the Expiration Policy timer job ran.

Using the Run Now features of the Information Management Policy and Expiration Policy timer jobs, I ran a series of cycles against four items that I had in my custom list. In all cases, the emails got sent out in each cycle, meaning that once the Information Management Policy is triggered to run against the list item, the recurrence portion of the policy will run every time the Expiration Policy timer job runs. It does not go back and try to determine if the event portion of the Information Management Policy is still true. In fact, you can go into the list item and change column values that would make the event condition *not* true, but the Information Management Policy will still continue to run each night because it was already triggered the first time.

In effect, this means that if you set the two timer jobs to run nightly (separated by a couple of hours), you will basically have the ability to automatically run a workflow against a list item on a daily basis without manual intervention or action on the item (provided the event portion of the Information Management Policy has triggered).

So What If I Don’t Want My Workflow Logic To Run Every Night?

So while it’s cool to have that workflow run every night, what if I don’t want anything to happen most of the time? If that’s the case, you need to write logic to stop the workflow if certain conditions exist.

In the prior example, I was sending out an email and updating a date in the list item. I changed the workflow to also update a new column… Initial Email Sent. If that column is set to Yes (which is the case after the workflow runs the first time), the workflow will immediately stop and no additional processing will occur:

The workflow will still be triggered each night based on the recurrence logic in the Information Management Policy. The logic of the workflow will dictate exactly what does and does not happen, though.

What About Multi-Stage Retention Policies?

Since we’ve come this far…

I decided to add a second stage to my Information Management Policy to see if and when that would trigger. Here’s the set-up:

The first stage still runs the email and updates the trigger date. The second stage will run if today is greater than the Condition Date plus one year. The thought was that the first stage would run repeatedly due to recurrence, and then the second stage would trigger if the Condition Date changed.

My test cycles were as follows:

• I set the Condition Date to two weeks prior (to trigger the policy immediately) and ran the Information Management Policy and Expiration Policy timer jobs via Run Now. I got the email and the Initial Email Sent indicator was set to Yes.
• I then ran the Expiration Policy timer job again via Run Now to simulate another nightly run. The workflow ran again, and the logic stopped when it checked the Initial Email Sent indicator.
• For the third and final run, I set the Condition Date to two years prior. I then ran the two timer jobs. Within 30 seconds of the Expiration Policy timer job, the list item had been deleted and moved to the recycle bin. It showed in the Site Collection recycle bin as being deleted by the System Account, not by me as the person who set up the policy or changed the list item.

Gotchas Found In Testing

When I was updating my workflow during testing, I re-published it a couple of times. When I went back into the Information Management Policy, I noticed that the Action portion of the retention policy was still pointing to a previous version of the workflow:

I had to go back into the policy and update the action to point to the most current version in order to get the most recent version of the workflow to run. This is something you need to remember if you change the workflow being used.

Conclusions

This would work well in a scenario where we have list items that need automated reminders a year or so down the road (instead of having active workflows “waiting” for 365 days to run the next step):

• The initial event on the Information Management Policy could trigger on Created Date plus 0 days (so it starts running right away).
• The first stage is set to run a reminder email workflow with recurrence happening every 0 days.
• The workflow would check to see if the current date is greater than the reminder date and then set an indicator when the email first goes out. Other logic (maybe when the form is updated) would remove that indicator if the reminder date changes.
• The second stage could trigger on an Archive Date being added, and it could move the item to an archive list or trigger an archive workflow with appropriate logic. It would have no recurrence specified, so the Information Policy would be effectively completed by then.

There may be a number of other ways to accomplish this, but this would give us the ability to have “out of the box” workflows that run on a schedule rather than require manual triggering on each individual item.