Implement n-x versioning to track outdated software

Zach Allen1
Tera Contributor

3 weeks ago

Hi ServiceNow Community,

 

I’m exploring ways to track how our installed software compare to the latest versions available from the vendor.

 

Specifically, we want to:

  • Identify when installed software are n versions behind (e.g., 3 versions behind the latest release).

  • Understand where to source or pull the latest version that is available from the vendor and where to store that.

  • Generate reports or trigger actions when latest installed software fall behind a certain version threshold.

Has anyone successfully implemented n-x versioning in ServiceNow, or have any best practices for monitoring and reporting on outdated software?

 

From my understanding, TRM under EA can be useful to determine some of these lifecycle calculations, but EA is not on the roadmap anytime soon so we are trying to get creative.

 

Any guidance, examples, or recommendations would be greatly appreciated!

Labels:
0 Helpfuls
  • 395 Views
1 REPLY 1

SAMfluencer
ServiceNow Employee

2 weeks ago

Hi @Zach Allen1 ,

 

I haven't personally implemented this use case yet, I wanted to share a conceptual approach that might work natively within SAM Pro without needing EA or TRM. Happy to be challenged or refined by anyone who's actually built something similar.

 

Out of the box, SAM Pro gives you solid install-to-entitlement coverage, but version currency monitoring needs a bit of assembly. Here's how I'd think about approaching it.

 

Step 1 - Where to Store "Latest Vendor Version"

 

Two options worth considering:

 

Option A — Extend the Software Product Model record Add custom fields to Software Model:

 

  • u_latest_vendor_version (string)
  • u_latest_version_release_date (date)
  • u_version_n_x_threshold (integer - e.g., 3 = alert when 3+ versions behind)
  • u_version_source_url (link to vendor release page)

This keeps version currency data co-located with the normalized product record, which should make reporting cleaner.

 

Option B - Dedicated Custom Table If you want to track patch, minor, and major version gaps separately, a lightweight custom table like u_sw_version_currency  related back to the product model gives more flexibility without touching OOB schema.

 

Step 2 - How to Source the Latest Version

 

This is arguably the hardest part. Some options I'd explore:

 

  • Manual curation - ITAM team maintains a review cycle for top-N titles. Not glamorous, but pragmatic for a focused scope (top 20–30 business-critical titles)
  • Integration Hub + vendor RSS/API feeds - Some vendors publish release feeds. A scheduled Flow Designer flow could potentially poll these and update the product model record.

Step 3 - Version Gap Calculation : The idea would be to call this from a scheduled script that reads installed versions from cmdb_sam_sw_install , compares against the product model's u_latest_vendor_version, and writes a u_version_gap integer back which then drives reporting and notifications.

 

https://www.servicenow.com/community/sam-forum/software-installtion-table-cmdb-sam-sw-install/m-p/13...

 

Step 4 - Reporting and Actions

 

Once u_version_gap is populated, the standard toolset should take over:

 

  • List/bar reports filtered by u_version_gap >= 3, grouped by publisher or department
  • Scheduled Flow Designer notifications to asset owners when gap exceeds threshold
  • A simple dashboard KPI showing % of estate on current version as an exec-level metric

On TRM / EA:

 

You're right that TRM is the proper home for this kind of lifecycle data - it's specifically designed to govern approved software versions and flag technical debt. This community article on TRM (https://www.servicenow.com/community/enterprise-architecture-articles/manage-software-technology-sta...is worth bookmarking for when EA does land on the roadmap. Also worth noting - SAM Pro already maintains a sam_sw_product_lifecycle table that holds vendor lifecycle data synced weekly via content updates; it won't tell you "n versions behind" out of the box, but it's worth checking what's already populated before building custom fields. See this thread https://www.servicenow.com/community/sam-forum/sam-pro-how-to-get-software-model-lifecycle-data-reco...for context on how that table works.

 

Again - this is a conceptual suggestion I haven't personally validated end to end. If anyone has actually built something like this, I'd love to hear what worked, what didn't, and whether there's a simpler path I've missed.

 

If this helped - amazing, you're welcome, go click Helpful and Accept as Solution. If it didn't - well, at least you learned what not to do. Either way, we grow. 

 

Cheers, Abby

ITAM Principal Solution Architect

 

0 Helpfuls