---
sourceDocument: Australia Build or modify applications
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/application-development

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# Updating your app for a ServiceNow platform version

# Updating your app for a ServiceNow platform version {#ariaid-title1}

Release version: Australia  
Updated January 1, 2024  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Updating your app for a ServiceNow platform version

When ServiceNow releases a new platform version, your app may require updates to maintain compatibility.
Platform upgrades can affect APIs, system tables, UI frameworks, scripting behavior, security policies, and integration components.
Proactively reviewing and updating your app in a test environment before deploying to production reduces the risk of unexpected issues and downtime.
Show full answer Show less  

## Key Practices for Managing Upgrades

* **Use Git Branching:** Isolate upgrade work on a dedicated Git branch to allow ongoing feature development on other branches, ensure changes are reviewed via pull requests, maintain a clear change history, and enable easy rollback with tagged releases.
* **Focus Areas for Compatibility Checks:**
  * **Scripting APIs and GlideRecord:** Identify deprecated or removed APIs using release notes and update your app accordingly.
  * **System Tables and Columns:** Verify references to system tables or columns for renames or restructuring that could break queries.
  * **UI Components and Frameworks:** Examine changes in UI Builder, Service Portal widgets, or Now Experience components that could affect visual behavior or APIs.
  * **Security Policies and ACLs:** Review ACL rules for changes in evaluation order or scope that might alter app access and permissions.
  * **Flow Designer and IntegrationHub:** Check for updates in flows and spokes that might change behavior or require input adjustments.
* **Automated Testing:** Run Automated Test Framework (ATF) tests on the upgraded instance to quickly identify issues, followed by manual testing of key user workflows to detect behavioral or visual changes. Consider adding ATF smoke tests if not already in place.
* **Branch Strategy:** Create a branch named for the target version (e.g., *upgrade/yokohama*) from a stable release, commit fixes with clear messages referencing release notes, and tag the branch once the app is compatible.

## Post-Upgrade Actions

* Keep the upgrade branch as a reference for potential production issues that may arise after deployment.
* Update app release notes and internal documentation to reflect changes made during the upgrade.
* Add or enhance ATF tests to cover any gaps discovered during the upgrade cycle.
* Monitor upcoming ServiceNow release notes early to start planning the next upgrade with ample time.

This structured approach helps ServiceNow customers maintain app functionality across platform versions, minimize disruption, and build confidence in their upgrade process.  
When ServiceNow releases a new platform version, your app may need updates to keep working correctly. Learn how platform upgrades affect your app helps you plan and complete
the upgrade with confidence.

ServiceNow releases platform versions on a regular schedule. Each version can include changes to APIs, system tables, UI frameworks, and scripting
behavior. If your app uses any of these, parts of it might stop working after the upgrade.{#upgrading-your-app__upgrading-your-app-para-1}

Reviewing your app before the upgrade reaches production gives you time to find and fix compatibility issues in a safe, controlled environment. This reduces the
risk of unexpected failures on your production instance.{#upgrading-your-app__upgrading-your-app-para-2}

## How does Git makes upgrades? {#upgrading-your-app__how-git-helps}

When your app is linked to a Git repository, you can isolate all upgrade-related work on a dedicated branch. This approach provides several
benefits:{#upgrading-your-app__upgrading-your-app-git-1}

* Your team can continue feature development on other branches without interruption.
* All compatibility fixes are reviewed through a pull request before they reach your main branch.
* You have a clear record of every change made during the upgrade, who reviewed it, and why it was needed.
* You can roll back to a tagged release if issues appear after the upgrade goes to production.

## What to check before and after an upgrade {#upgrading-your-app__what-to-check}

Not every platform change affects your app. Focus your review on the areas most likely to cause compatibility issues:{#upgrading-your-app__upgrading-your-app-check-1}

Scripting APIs and GlideRecord methods
:   ServiceNow may deprecate or remove scripting APIs in a version. Check the release notes for your target version. Look for any APIs your app uses that are
    listed as deprecated or removed. Replace them with the current alternatives before testing.

System tables and column names
:   Platform versions sometimes rename or restructure system tables and columns. If your app queries or references these directly, the queries may return
    unexpected results or fail after the upgrade.

UI components and front-end frameworks
:   If your app includes UI Builder pages, Service Portal widgets, or Now Experience components, check whether the underlying framework has changed in the
    version. Visual behavior and component APIs can shift between releases.

Security policies and ACL rules
:   Changes to ACL evaluation order or scope boundary behavior can affect what your app can access and how it responds to user permissions. Review any
    security-sensitive parts of your app carefully after the upgrade.

Flow Designer actions and IntegrationHub spokes
:   If your app uses Flow Designer flows or IntegrationHub spokes, check whether those components have been updated or changed in the platform version. An
    updated spoke may behave differently or require updated input configurations.

## The role of automated testing in an upgrade {#upgrading-your-app__role-of-atf}

Running your Automated Test Framework tests on the upgraded test instance is one of the most reliable ways to find compatibility issues quickly.
ATF tests give you a structured signal about what is broken and where to focus your fix effort.{#upgrading-your-app__upgrading-your-app-atf-1}

Automated tests alone aren't enough. After your tests pass, manually walk through your App's key user flows to catch behavioral or visual changes
that tests might not detect. Check form behavior, UI rendering, workflow triggers, and any integration responses.{#upgrading-your-app__upgrading-your-app-atf-2}

If your app doesn't have ATF tests yet, an upgrade cycle is a good time to add basic smoke tests for your core workflows. This gives you a
reliable baseline for every future upgrade.{#upgrading-your-app__upgrading-your-app-atf-3}

## Using a branch strategy for upgrade work {#upgrading-your-app__upgrade-branch-strategy}

Create a dedicated branch for each platform upgrade. Name it clearly to identify the target version, for example
`upgrade/yokohama`. Branch from your current stable release line so you're working from a known good state.{#upgrading-your-app__upgrading-your-app-branch-1}

Commit each compatibility fix separately with a short message that explains the change and references the relevant release note. This keeps the
branch history readable and makes the pull request review straightforward.{#upgrading-your-app__upgrading-your-app-branch-2}

After the pull request is approved and merged, tag the release to mark the point at which your app became compatible with the platform version.
A tag like `v2.4.0-yokohama` gives you a clear reference for future comparisons and rollbacks.{#upgrading-your-app__upgrading-your-app-branch-3}

## What to do after the upgrade is complete {#upgrading-your-app__after-the-upgrade}

After your app is running on the platform version in production, take a few steps to close out the upgrade properly:{#upgrading-your-app__upgrading-your-app-after-1}

* Keep your upgrade branch in the repository as a reference. Don't delete it right away. Issues sometimes appear on production in the weeks following an upgrade, and the branch gives you useful context.
* Update your app's release notes and internal documentation to reflect any API or behavior changes made during the upgrade.
* Add ATF tests for any coverage gaps the upgrade revealed so you're better prepared for the next cycle.
* Monitor the release notes for the next ServiceNow platform version early. Starting your review sooner gives you more time to plan and reduces the pressure of the next upgrade cycle.