I want to set Expiry Date of Content Items, but I don't want to use a scheduled core service to check for the expired content periodically because Daily Run of Scheduled service would be overhead on the servers.

Is it possible to schedule UnPublishing of Expired Content items (based on Metadata) on Publishing Itself? (Using Deployer Extension )

  • A lightweight option could be: use the Eventsystem to store/update an unpublish action in a custom database (uri - unpublishdate) whenever the metadata is updated/saved/deleted. Run a Scheduled service (every x seconds/minutes/hours/days) to loop through this database and unpublish it. Whenever a publishtransaction FAILS, check if it's for an item in your custom database and don't delete it yet. (also Eventsytem). Scales nicely too. Just install your custom service on multipe machines. Commented Aug 17, 2018 at 21:11

3 Answers 3


What you can do is combination of different events in Event System. For example, every time your item is successfully published (transaction state changed to Success), you can schedule same item to unpublish at specific time in future based on metadata. You also must take care of the following issues:

  1. what if someone removes transaction from queue before its executed,
  2. what if item MetaData value is changed
  3. what if unpublish failed?

Honestly, I would do this as combination of Core Service and Windows Service. I would have one scheduled windows service which uses Core Service as connection to database, and would take care that item is INDEED UNPUBLISHED WHEN NEEDED.

Also, you can use direct database access to Tridion_cm database, if using core service is to extensive to you. Database in general shouldn't be used, but single select statements can be, if you know the structure of database and items. Also, you should take care of clogging transaction queue with transactions... etc...


You could do that as part of your templates, as a custom resolver or event system.

Then a task would be scheduled to unpublish content at a given date in the future. You'd need to do some testing to ensure that the unpublish task gets changed if you need to change the unpublish date, and also to ensure that it doesn't create a new unpublish task every time you (re)publish the content.


You can do it during render (using templates), resolving (using custom resolver) or deployment (custom deployer). Best case would be to use event system to ensure that your publishing activities are successful.

The simplest would be to schedule a unpublish based on the date that the item is published or a date captured in the metadata. The cons of this is already explained by Marko above.

Since expiration is something that is typically tied with different levels of compliance, you would not want to have a 'brittle' solution. Another solution would be to write all your publish transactions to a custom database based on the publish transaction and item IDs on SUCCESSFUL publish. An expiration job can be scheduled every day (if expiration is based on date only) or a scheduled time intervals (if expiration is based on date and time). This job should use Core Services to unpublish the items and also update the custom database. If an item has been published multiple times during the above interval, you should probably use the latest transaction; which is why a custom job may still be the way to go. The overhead, to be honest, should be very minimal and can be run from publisher or deployer servers in an out-scaled environment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.