One In Nine Partner Store Apps Is Running Out Of Runway

The n-3 rule: in our experience, a ServiceNow Store listing stays live while its newest certification is one of the last three family releases, and ServiceNow ships about two a year. In our study, 158 of 1,442 installable partner apps were certified to Yokohama and nothing newer, the oldest release inside that window.

When the Brazil release ships, that window slides and those apps fall out of it.

What is the n-3 rule?

ServiceNow’s App Publisher FAQ says: “We require you stay current (n-3) with our releases.” In our experience, a listing stays live while its newest certification is one of the last three family releases. Once it falls outside that window, the listing is unpublished: it stops appearing in the Store, and customers can no longer find or install it.

ServiceNow documents the mechanics of recertification thoroughly: how to recertify for a new release without code changes, and how to do it with them. What the public knowledge base does not spell out is the consequence of letting it slide.

The practical effect is a rolling deadline. In our experience, no reminder arrives. ServiceNow “generally releases two new release families per year”, according to its Upgrade Policy. So the window moves about twice a year, whether or not your roadmap has room for it.

Where did partner apps sit in our study?

Australia was a young release: early availability began on 12 March 2026 and general availability followed on 5 May. Fourteen weeks on, being one release behind was normal rather than negligent—most publishers were mid-cycle, not in trouble.

1. 73151%

   Australia

   Current release

2. 55338%

   Zurich

   One back — normal mid-cycle

3. 15811%

   Yokohama

   Oldest still in the window

In our study, no listing’s newest certification was older than Yokohama, which is consistent with the rule: apps that fell further behind no longer show.

What happens when the Brazil release ships?

Brazil is the next family release. Early availability began on 24 September 2026. ServiceNow’s Early Release Program page (KB0718545) says: “Early Availability (EA) is available at least 45 days prior to General Availability”. That places general availability (GA) in early November, the date ServiceNow staff have given in the community forum.

When Brazil ships, the Store’s three-release window becomes Brazil, Australia and Zurich. Yokohama drops off the end, and with it the 158 apps whose newest certification was Yokohama—spread across 119 publishers.

The three-release window in our study

1. Yokohamaoldest in the window
2. Zurich
3. Australiacurrent

When the Brazil release ships

1. Yokohama158 apps drop out
2. Zurich
3. Australia
4. Brazilenters

The runway is shorter than the GA date suggests. A release certification, for an app whose code has not changed, still means upgrading a vendor instance, regression-testing the app on the new release and going back through review. A recertification with code changes is a development cycle. Publishers who start when Brazil lands are starting late.

You do not have to wait for it to land. The KB adds: “technology partners can utilize the Early Availability build to build and submit for ServiceNow store certification prior to market launch”. So the work can start on that build, not after general availability in November.

Not all 158 were equally neglected. The median time since last publish was fifteen months. But the tail was long. Of these apps, 34 had not been republished in over two years, and the oldest had not been touched in nearly nine years.

What separates the 119 publishers?

Those publishers are not one group. They split into two situations that look identical in the numbers and are nothing alike in practice.

74 of the 119 had nothing current at all. Every listing they owned was on Yokohama. For many of these the app is probably no longer a live product: with no customer upgrading and pushing for compatibility, nothing forces the work. With the listing still up, the publisher is presumably still in the partner programme, holding a listing nobody appears to be maintaining.

The other 45 were actively maintaining a portfolio and had let specific apps lapse. They kept other listings current on Australia or Zurich, so this looks less like neglect than triage. Somewhere a decision probably got made, explicitly or by default, about which apps were worth the release cycle.

That second group suggests what recertification pressure actually does to a publisher. It does not cause a crisis. It causes quiet attrition at the edges of a product line.

Why do apps fall behind?

Look at the same catalogue from the other direction and the mechanism is obvious. 70 independent publishers whose Store profiles list up to 200 employees carried 372 live certified listings between them. The largest portfolio in that group was 37 apps, from a publisher whose Store profile lists 1–50 employees.

Every one of those listings needs a regression pass and a review submission often enough to stay inside the three-release window. Indefinitely. It does not scale with headcount, it scales with the number of apps you have shipped—which is to say, with your past success.

Custom-table count makes it concrete. The apps certified only to Yokohama defined 1,585 custom tables between them. That is the retest surface: the data model somebody has to walk through and confirm still behaves on the new release. It is unglamorous work, it competes with the roadmap every single cycle, and in our experience it usually loses.

How do you check where your own app stands?

It takes a minute. Open your listing on the Store and look at the compatibility list on the version panel—the family names, not the version numbers. Then:

• Australia listed? You are current. Your next deadline is Brazil, in the ordinary way.
• Zurich newest? Normal position mid-cycle. You have room, but the work is now on the clock.
• Yokohama newest? You are on the last release inside the window. Brazil moves it. This one needs scheduling now, not after GA.

Then do the same for every app you own, not just the one you thought of first. The publishers most exposed are not the ones with a single neglected app. They are the ones with enough apps that a couple can slip without anybody noticing.

For the mechanics of review itself, see our ServiceNow app certification guide. It covers what the certification team actually inspects, the realistic timeline and what certification costs. For a concrete example of what a family release can change underneath a certified app, see what Australia did to the dictionary read-only checkbox. And if you are weighing whether a CMDB connector needs to be a Service Graph Connector at all, see how the two paths compare.

What the figures cover

Every catalogue figure on this page comes from the ServiceNow Store’s public listing and seller-profile data as it stood on 14 August 2026. The release dates come from the ServiceNow sources linked above. The catalogue data covers 1,653 listings from 695 publishers. It includes the release compatibility, publish date and custom-table count each listing publishes about itself, and the employee band on each publisher’s Store profile.

Of those 1,653, some 211 carry no version compatibility at all. Checking each one against the Store's own listing data: 203 are listing-only entries with no installable version, so they have no release to declare. The other eight are installable apps that publish no compatibility at all. All 211 are excluded from every percentage on this page, which leaves 1,442 installable apps as the denominator.

Individual publishers are not named here. The aggregate is the useful part; a list of firms whose listings are about to lapse is not.

Questions

Does my app really get removed from the Store?

In our experience, yes. Once your newest certified release falls outside the last three families, the listing is unpublished and stops showing in the Store. New customers can no longer find or install it. ServiceNow’s App Publisher FAQ says: “We require you stay current (n-3) with our releases.”

My app is on Zurich. Am I in trouble?

No. Australia is a few months old, and 38% of installable partner apps were in your position when we read the Store. The thing to avoid is treating that as a resting state. Zurich becomes the oldest release in the window the moment Brazil ships, and then the same question arrives with less time attached.

How long does a release certification take if nothing in the code changes?

Plan on roughly 2–3 weeks from upgrading your vendor instance to the release certification, the estimate in our recertification plan. The work is the regression pass, and that scales with your data model rather than your app's age. An app with two hundred tables is a project, and it is the same project every release.

Is it worth recertifying an app that is not selling?

Often it is not, and that is a legitimate answer. What is worth avoiding is arriving at that answer by default—letting a listing lapse without deciding to, while you are still in the partner programme. Either the app earns its recertification or it should be retired deliberately.

Does recertifying reset anything for customers already running the app?

In our experience, existing installations keep working—this is about the Store listing and its availability to new customers, not about breaking instances. The risk to existing customers is the opposite one. They get upgraded on ServiceNow's schedule, and an app that has not been tested on their new release is where the surprises come from.

Where do these numbers come from?

Every catalogue figure on this page comes from the ServiceNow Store’s public listing and seller-profile data as it stood on 14 August 2026. The 211 listings that carry no version compatibility are excluded from the percentages, which is why the denominator is 1,442 rather than 1,653.