Does the "Valid to" date always have to update to 12 months in the future?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-31-2024 05:29 PM
When an article is updated, the Valid to field automatically updates to 12 months from this date.
I would like this to only happen when an article is created, so that the Valid to field is 12 months from when version 1.0 was created.
Sometimes I'll need to edit an article throughout the year but still want to keep the original creation/valid date so I can have stakeholders review the content, after that, I'd want to be able to push the Valid to date out for 12 months from their review.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-31-2024 05:53 PM
No, you do not have to always have the "Valid to" date update to 12 months. We coded a customization to give us 13 months. You can also choose to have the Valid to field be manually updated and give permissions to knowledge managers, authors, whoever it makes sense to give that permission to. Then, once you've approved an author's updates, you can update the Valid to date to 12 months from whenever the review happened.
In order to keep all of our articles from expiring at the same time throughout the knowledge base (because we were up to close to 700 articles, last I checked), we tried to keep them relatively even, so batches of them expired every month. (At the time, we had to update them manually. We were able to give me, as knowledge manager, permissions to update the Valid to field from the list view, which was a lot faster, but we had to specifically change something in the backend to make that happen. I don't know if it's been automated yet or not.)
Changing Valid to fields and changing the permissions to allow more flexibility with them were both relatively easy.
It all depends on how you want to set up your governance.
I hope this helps! Please feel free to ask any follow-up questions.
P.S. This might be overkill, but I'm including a job aid I wrote for expiring and retiring articles a while back. Hopefully most of it is still accurate. Even is the screenshots, etc., aren't accurate, seeing how we set up the governance may help to give you ideas. Helpful context: At the time, I was a team of one. It was kind of rough. I can tell you right now that the section, "RENEWING EXPIRED AND SOON-TO-BE EXPIRED ARTICLES," isn't accurate at all. We changed that process to something easier. (i.e., updating the Valid to field from the list view) But hopefully other articles will be valuable. Thanks!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-01-2024 03:01 AM
Hi Keszia,
If you haven't already, I would suggest reading the Article Validity documentation from ServiceNow. You'll notice that you set the valid to timeframe by KB and that is easily configurable without customization. There are also notification information provided.
I hope that helps!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-01-2024 02:10 PM
Thanks - when I first took over the knowledge base I thought adding an article validity date would be of benefit, which it kind of is, but given I'm wanting something prompt me to ask "do you want to update the valid to date?" so in cases of me fixing a typo or something minor like that, the original valid to date remains for the purposes of annual content reviews.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-01-2024 02:44 PM
This is awesome information, thanks for sharing your solution. Do you know what was needed to give you access to edit the valid to field in a list view? I've wanted that ability for a few table/lists but unsure on where to start when discussing it with my developers as we anticipate there will be some you can't edit this way.
I'll read through what you've shared and see what gems lie within 🙂