The ServiceNow App Certification Guide for ISVs

Apps run into trouble at ServiceNow certification for five recurring reasons:

• Security retrofitted after development
• Artifacts created outside the application scope
• Deleted application files
• Building against a single platform release
• A findings list the team can’t read

The first four are build-time decisions; the fifth is how you respond when review comes back.

Security as an Afterthought

In our experience, security is the most expensive thing to retrofit. Adding ACLs and fixing GlideRecord usage after development costs far more than building with certification-compliant security patterns from sprint one.

Scope Creep into Global

Anything created outside your application’s scope is not part of the application files—it does not ship with the app. It has to be bundled as a separate update set and handed to the customer alongside the install. In our experience, the certification team does not like that, and a fully global application cannot be listed at all—the Store takes scoped apps only.

A few things are legitimately global. A CMDB integration cannot ship a custom Data source choice, because that choice list lives in the global scope. The clean pattern is documented instructions for the customer to create the value on their own instance.

Deleting Application Files

Deleted records do not ship. Once the first version is published, ServiceNow says “Deletion entries are not packaged as part of app file”, so a deletion never reaches customer instances.

Scrub anything unwanted before your first submission. After that, deactivate instead of delete—set the record inactive, or mark it deprecated where there is no active flag. In our experience the certification team accepts a deletion if you commit to giving existing customers an update set that removes it. With no customers yet, you don’t need one.

Shipping for a Single Release

ServiceNow’s Upgrade Policy says it “generally releases two new release families per year”. Platform behaviour moves underneath your app—Australia turning the dictionary read-only checkbox into a four-option choice field is a current example.

Test across current-minus-two to current-plus-one: customers run releases both older and newer than your build baseline. In our experience, apps that fall outside the Store’s three-release window lose their Store listing. In our study, 158 of the 1,442 installable partner apps were one release away from that.

Treating the Findings List as Self-Explanatory

Certification comes back as a list of findings. In our experience, the certification team explains them, suggests fixes, and will even join calls to help. Even so, teams seeing that list for the first time can stall on it. Not because the fixes are hard, but because the platform context behind each finding is unfamiliar. If the list reads like a foreign language, bring in someone who has sat on the review side of it.

The rest of this guide is the sequence we follow: enrol, build in the right place, meet the review criteria, and plan the calendar.

ServiceNow’s certification guide says “you must be a Build Partner to list an application on the ServiceNow Store” (KB1270874). ServiceNow’s announcement of 20 January 2026 calls the programme the “reimagined Build Program”, with the tiers “Registered, Select, Premier, and Elite”. It adds: “A new Access Tier also invites aspiring and entry-stage partners to start building immediately”.

Membership carries a fee (see what it costs). In our experience, ServiceNow won’t certify an app while the membership is unpaid, and listing the app free doesn’t change that.

• Apply to the Build Program—through ServiceNow’s partner portal. In our experience admission is not automatic—budget for the membership before you plan the build
• Receive vendor instances—once approved, ServiceNow provisions them—or converts the PDI you started on—for development and testing

Your company joins the Build Program directly with ServiceNow. Development partners like XpertApps then build on your vendor instances and take the app through certification.

A Store app is submitted for certification from a vendor instance—no other instance type can submit one. A PDI is for learning and prototyping. But ServiceNow can convert one into a vendor instance when you join the Build Program, so work you start there carries over: the developer-instance plan sets out the move. Customer instances are for production. Neither a PDI nor a customer instance can submit an app for certification.

The table reflects our experience; the PDI reclaim rule is ServiceNow’s own (KB3140725).

Two reviews run in parallel and you submit for both at once. App Review is the technical one—the first four areas below. Listing Review is a separate marketing check on everything a customer sees on the Store.

Security Review

In our experience, security is the area review flags most. Several of ServiceNow’s own top ten failed certification checks are access controls. They include missing ACLs on tables, UI pages and client-callable script includes, and unconditioned UI actions. Automated scans and manual reviews both cover it:

• ACL enforcement on all tables and records
• No GlideRecord in client-side scripts
• Input validation and output encoding to prevent XSS
• Secure handling of credentials and API keys
• Execute ACLs on client-callable Script Includes, Scripted REST endpoints, and UI Pages
• No UI Actions without conditions or required roles
• Proper scoping—no access outside app scope

Performance

Your app must not degrade the host instance. In our experience, ServiceNow tests query efficiency, script execution time, and resource consumption:

• Efficient GlideRecord queries with proper filtering
• No unbounded loops or recursive scripts
• Minimal use of synchronous AJAX calls
• Proper use of caching where appropriate

Code Quality & Scoping

In our experience, scoping in ServiceNow is automatic. Every artifact is created into whichever application scope is selected at the time, so the discipline is selecting the right application before you create anything. Whatever lands outside the app’s scope is not part of the application and will not ship with it. Cross-scope access must be explicitly declared and justified:

• All artifacts contained within the app scope
• Clean, maintainable code following ServiceNow best practices
• No hardcoded instance URLs, credentials, customer-specific data, or leftover personalized lists and reports
• Proper use of system properties for configuration
• Inbound integrations write through import-set staging tables with transform maps—never directly to target tables

Documentation & Store Listing

Your Store listing needs clear documentation, screenshots, and a complete description of what the app does and how to configure it:

• Design Document and Test Plan with results—reviewed by the certification team, never published
• Installation and configuration guide—the one document customers see
• Store listing with screenshots and feature descriptions
• Release notes for each version
• Support contact and SLA information

Listing Review

In our experience, Listing Review is run by ServiceNow’s marketing team rather than engineers. It looks at what a customer sees: the app name, your company logo, the screenshots, and the listing copy. It checks each against ServiceNow’s terms and trademark guidelines.

Naming is what catches vendors out. You cannot build ServiceNow’s marks into your application’s name—not ServiceNow, not SNC or SNOW, and not a compound made from them. The app has to carry your own brand. Saying what it integrates with belongs in the description, where naming the platform is expected. Putting it in the product name reads as implied endorsement, and that is the line the review enforces.

Run the Self-Test Tool Before You Submit

ServiceNow’s Certification Self-Test Tool, installed on your vendor instance, runs the automated portion of the review. ServiceNow says the tool “will help you address up to 90% of the commonly discovered issues we find in the first few iterations of the certification process” (Saikiran Guduri, ServiceNow, 14 February 2023). It covers the automated checks, not the whole review.

Run it on the exact version you are about to submit. In our experience, failed results do not block submission—but every issue it would have caught becomes a finding, and a finding becomes a cycle.

You submit from your vendor instance, not from the Store.

1. Publish the version you want certified to the ServiceNow Store from your application record, which places the app in the application repository.
2. Request certification from the Store Publisher Portal, completing two forms: App Review for the technical assessment and Listing Review for the marketing one. Both can be submitted at once, and they run in parallel.
3. Three documents go with it: the Design Document, the Test Plan with its results, and the Installation Guide.
4. The team reviews, flags what needs changing, and you fix and resubmit the same way.

The Design Document and the Test Plan with its results are for the certification team and are never published. The Installation Guide is the one your customers see, so it is worth writing properly—it becomes your admin documentation either way.

From there it is findings and cycles. A code change means a new version number and a fresh submission. For an unchanged app, a release certification means retesting on the new family release and submitting updated results. ServiceNow’s blog calls both recertifying.

1. Discovery and architecture—1 to 2 weeks. Define scope, map certification requirements, design the technical blueprint.
2. Build and test—2 to 3 weeks. Sprint-based development with a demo at the end of each sprint, and security and performance reviewed as you go rather than at the end.
3. Certification documents—1 week. The design document and test plan on ServiceNow’s templates, the installation guide, and your Store listing. In our experience, it is the step teams most often leave too late.
4. Certification review—3 to 5 weeks. ServiceNow reviews your submission; its certification guide (KB1270874) says certification “typically requires 3-5 weeks”, and how long yours takes depends on how cleanly your app and its documents meet the criteria.
5. After listing—each family release. A release certification retests an unchanged app on the new release with a revised test plan; any change is a recertification.

In our projects, the first four steps take roughly 7 to 11 weeks from the start of design to a Store listing for a typical scoped app. Complexity can push any of it longer, and Build Program admission is a separate prerequisite—allow 2 to 6 weeks and start it well in advance. The Store App Planner dates each kind of build.