How to manage plugin/application updates
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-24-2025 06:20 AM - last edited a week ago
Dear Community
We are struggling to find a proper way to manage plugin/applications updates. As you are aware plugin/applications are receiving outside upgrades and patches new versions that you can install. Frist of all when you look for updates for the plugins we see a difference in the new application manager:
And the old application manager:
Not sure why that is but therefore we stick to the old application manager. We really struggle how to manage this because of the following:
- We are not sure which of these plugins will be updated during a upgrade, during our last upgrade to Xanadu we could see 138 plugins where updated in the logs but it unclear in this overview which ones.
- It is nearly impossible to combine this with an upgrade, we received that request because during an upgrade all processes are being tested so it would be ideal to include these plugin upgrades there. Downside of this is that your upgrade time will be huge because you would need to manually upgrade all these plugins first so that why we don't really want to combine that with an upgrade.
- We have not found a way to easily export this overview so that you see the plugin name and the release notes, we now perform this as a manual action. We need this overview with the release notes to inform product owners about this so that they can use this information after installation to test it.
- We performed an update of all plugins a couple of months before an upgrade but after the upgrade we already have a new list of more than 100 plugins so it feels impossible to keep track of this.
So this a bit of braindump on this topic, I would really love to hear feedback from the community how you are managing this process.
UPDATE:
Best Approach: CI/CD Batch Install API via Background Script
This is the community-accepted solution and avoids manual clicking entirely. Here's how it works:
Step 1 — Run this background script in your instance after the family release upgrade. It queries the sys_store_apptable for all installed apps/plugins where the installed version differs from the latest version, builds a JSON payload, and hands you a URL + body to trigger a batch install:
var loadDemoData = false;
var prevName;
var appsArray = [];
var grSSA = new GlideRecord('sys_store_app');
grSSA.addEncodedQuery('install_dateISNOTEMPTY^hide_on_ui=false');
grSSA.orderBy('name');
grSSA.orderBy('version');
grSSA.query();
while (grSSA.next()) {
var curName = grSSA.getValue('name');
if (curName == prevName) { continue; }
var installedVersion = grSSA.getValue('version');
var latestVersion = grSSA.getValue('latest_version');
if (latestVersion != installedVersion) {
prevName = curName;
appsArray.push({
displayName: curName,
id: grSSA.getUniqueValue(),
load_demo_data: loadDemoData,
type: "application",
requested_version: latestVersion
});
}
}
var appsPackages = { packages: appsArray, name: 'Update Apps' };
var data = new global.JSON().encode(appsPackages);
var url = 'https://' + gs.getProperty('instance_name') + '.service-now.com/$restapi.do?ns=sn_cicd&service=CICD%20Batch%20Install%20API&version=latest';
gs.info('Open the following URL:\n\n' + url + '\n\nPaste this JSON as the Raw Request body:\n\n' + data);
Step 2 — The script outputs a URL and JSON payload. Open the URL in a browser tab and paste the payload into the raw request body to trigger the batch install.
Step 3 — Let it run overnight. It queues all updates and processes them sequentially without any further manual interaction.
Step 3 — To monitor it you can check sys_progress_worker.list and filter on name “CICDBatchInstallService$CICDBatchInstallWorker”
Important things to know
About the family upgrade itself: When you do a family upgrade (e.g. moving from Xanadu to Yokohama), apps and plugins will "true-up" to a compatible version but this doesn't mean the latest version. Individual product teams determine which version is aligned to a given family release. So you'll likely still have a batch of updates to run afterward, which is exactly what the script above handles. ServiceNow Community
Parent/child plugins: If you update a parent plugin, child plugins get updated automatically. So your amount of plugins may actually be fewer independent operations than you think prioritize parent plugins first and watch the count drop. ServiceNow Community
Timing matters: Plan the batch update to run overnight or over a weekend. It works, but it's not fast the system queues jobs one by one.
- 6,384 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-07-2025 01:09 AM
Hi Kevin,
I was indicating that this module within the admin experience is part of the roadmap of SN enhancing our ability to manage upgrades. It may not have plugin management to the degree you wish as of yet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-25-2025 06:33 AM
Thanks Kieran this is good to know!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2025 05:34 AM
Experiencing the same administrative issue. Curious if there have been any further updates or if others have implemented a process solution to track.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
09-26-2025 05:53 AM
No unfortunately not, still waiting for the golden answer 😉
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-08-2026 01:03 AM
Hi guys, I met the same issue with Yokohama. Joining you in this 🙂