Loading...
Loading...
Resolve two related App Manager issues affecting application version visibility and upgrade behavior on specific platform versions. PRB1981044 — App Manager incorrectly blocks upgrades When an application version that is lower than the actual latest available version is installed, App Manager may incorrectly mark the installed version as the latest. As a result, App Manager blocks subsequent upgrades because it determines no newer version is available. Impact: App upgrades are incorrectly blocked. You are unable to move to the correct latest application version. Example: PRB1986694 — Latest internally shared app versions not visible The latest versions of internally shared applications do not appear in My Company Applications. The App Manager sync process does not update as expected, preventing newly published versions from appearing. Impact: Latest internally shared app versions are not visible in My Company Applications. App Manager sync does not reflect newly published app versions. Affected versions (both PRBs): Yokohama Patch 10 (including Hotfixes) Yokohama Patch 11 (including Hotfixes) Yokohama Patch 12 Zurich Patch 5 (including Hotfixes) Zurich Patch 6
Go to an instance running Yokohama Patch 10 or later, or Zurich Patch 5 or later. Identify an application that has more than one version and is not currently installed. In the Remote App [sys_remote_app] table, note the latest version — it should show the highest available version number. Install the lowest available version of the application and wait for the installation to complete. Go to the Store App [sys_store_app] table and check the Latest version field. The value matches the Installed field value instead of the actual latest version.
Option 1: Upgrade to a fixed release (preferred) Upgrade to one of the following fixed releases to permanently resolve both issues: Yokohama Patch 12 HF1 or later Zurich Patch 6 HF1 or later Upgrading to these versions ensures correct app version detection, proper App Manager synchronization, and unblocked upgrade paths. Option 2: Apply the maintenance script workaround If upgrading to a fixed release is not immediately possible, apply the maintenance script workaround. This workaround resolves both PRB1981044 and PRB1986694. Running the script once fixes all affected applications. Go to System Definition > Script - Background. Run the PRB1981044 Maintenance Script . After the script completes, go to App Manager and select Sync Now. Wait for the sync to finish. Note: The workaround does not need to be run more than once. No further action is required after the script is applied. Option 3: Additional cache troubleshooting (if sync issues persist) If App Manager sync issues persist after applying the maintenance script and running a sync, try disabling the App Manager cache. Go to the System Properties [sys_properties] table by going to /sys_properties_list. Search for the property sn_appclient.enable_app_manager_cache. Set the value to false. Go to Admin > Application Manager and select Sync. Wait for the sync to complete. Retry the steps to reproduce the issue. If the issue is resolved: The cache property was the cause. If the issue is not resolved: Set sn_appclient.enable_app_manager_cache back to true. -- A maintenance is being scheduled for affected instances to add conditional logic and prevent incorrect updates to the Latest version field for an application. Subscribe to this Known Error article to receive notifications when more information is available. For additional details, see the Frequently Asked Questions section in this article. Frequently asked questions Q: How can I tell if I am affected by this issue? A: You may be affected if both of the following conditions apply: Your instance is running one of the affected platform versions: Yokohama Patch 10, Patch 11, or Patch 12 Zurich Patch 5 or Patch 6 You observe one or more of these symptoms: App Manager blocks an application upgrade even though a newer version exists. The installed application version is incorrectly shown as the latest version. Latest versions of internally shared applications do not appear in My Company Applications. App Manager sync does not reflect newly published app versions. If you are running Yokohama Patch 12 HF1 or later, or Zurich Patch 6 HF1 or later, your instance is not affected. Q: What does the maintenance script do? A: The script adds conditional logic to prevent incorrect updates to the Latest version field for an application. This stops the Update Checker from incorrectly setting the latest version number to the installed version number. Specifically: PRB1981044: Patches the UpdateChecker script include with the corrected version and clears App Manager caches, restoring the upgrade button. PRB1986694: Patches the AppsData script include so My Company Applications reads directly from database tables instead of a stale cache, and clears App Manager caches. Q: What are the expected script outputs? A: The maintenance script outputs a JSON object. The following are the expected payloads for each outcome: Success — All fixes applied: {"at_risk":false,"changed":true,"outcome":"Success","note":"Yokohama patch 11;UI Page redirect added to new app manager;","buildName":"yokohama","buildWar":"glide-yokohama-...","reason":"PRB1981044"} Skipped — Fix not needed: {"at_risk":false,"changed":false,"outcome":"Skipped","note":"Yokohama patch 11;Fix already applied - skipping;","buildName":"yokohama","buildWar":"glide-yokohama-...","reason":"PRB1981044"} Error — Fix failed to apply: {"at_risk":true,"changed":false,"outcome":"Error","note":"Yokohama patch 11;Error: <exception details>;","buildName":"yokohama","buildWar":"glide-yokohama-...","reason":"PRB1981044"} Q: What if I have multiple affected applications? A: Running the maintenance script once fixes all affected applications. Q: Will the maintenance script cause data loss? A: No. Running the maintenance script does not remove application data. Q: Is there any service impact from the maintenance? A: There is no service impact from this maintenance. Q: Do I need to roll back the workaround after upgrading to a fixed version? A: No. Manual rollback is not required. The fix included in the fixed releases supersedes the workaround. Q: Can an admin apply the workaround? A: Yes. Admins can perform all workaround steps. Q: Can I opt out of the scheduled maintenance? A: Yes. To opt out, go to the communication record on the portal and select Opt out in the upper right of the form. Opt out at least 24 hours before the scheduled maintenance date. If you opt out, apply the workaround as soon as possible. If you apply the workaround before the maintenance runs, the maintenance detects that the fix is already applied and takes no action. The communication record still shows the maintenance as performed. Q: Why were some of my instances skipped during maintenance? A: Instances may be skipped if customizations are detected in one or both of the following script includes: UpdateChecker (sys_script_include_46e8ba01eb002100d4360c505206fec3) AppsData (sys_script_include_233b6a00d72221004a1dcdcf6e61036f) To avoid overwriting your changes, the maintenance was not applied automatically. To resolve: If it is safe to overwrite the customizations, set replace_on_upgrade = true for the corresponding Update XML [sys_update_xml] records and reapply the workaround from this article. If the customizations cannot be overwritten, contact ServiceNow Technical Support so the fix can be applied while preserving your changes. Q: We are on Zurich Patch 6 HF1 (or Yokohama Patch 12 HF1) and still see App Manager sync issues. Why? A: If sync issues persist after upgrading to a fixed version, this may be caused by a separate issue ( PRB1992835) that occurs when the Classic App Manager is accessed using a bookmarked URI. See KB2804238 for more information. Q: Why is the maintenance script so large? A: The script is approximately 350 lines and 647,000 characters because it embeds the complete corrected source code for two script includes — UpdateChecker and AppsData — as base64-encoded payloads, one set per affected patch level. These six payloads account for approximately 98% of the character count. The actual logic code is approximately 14,000 characters.
PRB1981044
Click on a version to see all relevant bugs
ServiceNow Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.