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, and a findings list nobody can decode. The first four are build-time decisions; the fifth is how you respond when review comes back.

Security as an Afterthought

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, and the certification team does not like that. 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: a deletion in a scoped app lands in an internal folder that never reaches customer instances, and once a version is published, deleting application files in a recertification is not allowed at all. 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.

Shipping for a Single Release

ServiceNow ships two major releases a year, and platform behaviour moves underneath your app—Australia turning the dictionary read-only checkbox into a four-option choice field is a current example—Australia’s read-only options change: what to set before you recertify. Test across current-minus-two to current-plus-one: customers run releases both older and newer than your build baseline. Apps that do not stay current lose their Store listing.

Treating the Findings List as Self-Explanatory

Certification comes back as a list of findings, and 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 sit on it for three or four months—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 first four are avoided by decisions made before and during the build; the fifth is about how you respond when review comes back. The rest of this guide is the sequence we follow: enrol, build in the right place, meet the review criteria, and plan the calendar.

This is a paid, contractual relationship with ServiceNow—a flat annual membership fee, which ServiceNow quotes on application rather than publishing. It is a hard gate on certification: ServiceNow will not certify an app from an unpaid membership, and listing your app free does not exempt you.

• check_circleEnroll in the Technology Partner Program (TPP)—apply via ServiceNow’s partner portal. TPP carries an annual fee and its own commercial terms, and admission is not automatic—budget for it before you plan the build
• check_circleGet Build Partner designation—the partner tier that lets you develop and publish apps to the Store
• check_circleReceive vendor instances—once approved, ServiceNow provisions them—or converts the PDI you started on—for development and testing

Your company enrolls in TPP directly with ServiceNow. Development partners like XpertApps then build and certify on your vendor instances.

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—though ServiceNow can convert one into a vendor instance when you enroll as a Build Partner, so work you start there carries over—and customer instances are for production. Neither can submit an app for certification.

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

The area review flags most—ServiceNow’s own top ten failed certification checks are dominated by access control. Automated scans and manual reviews both look for it:

• check_circleACL enforcement on all tables and records
• check_circleNo GlideRecord in client-side scripts
• check_circleInput validation and output encoding to prevent XSS
• check_circleSecure handling of credentials and API keys
• check_circleExecute ACLs on client-callable Script Includes, Scripted REST endpoints, and UI Pages
• check_circleNo UI Actions without conditions or required roles
• check_circleProper scoping—no access outside app scope

Performance

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

• check_circleEfficient GlideRecord queries with proper filtering
• check_circleNo unbounded loops or recursive scripts
• check_circleMinimal use of synchronous AJAX calls
• check_circleProper use of caching where appropriate

Code Quality & Scoping

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:

• check_circleAll artifacts contained within the app scope
• check_circleClean, maintainable code following ServiceNow best practices
• check_circleNo hardcoded instance URLs, credentials, customer-specific data, or leftover personalized lists and reports
• check_circleProper use of system properties for configuration
• check_circleInbound 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:

• check_circleDesign Document and Test Plan with results—reviewed by the certification team, never published
• check_circleInstallation and configuration guide—the one document customers see
• check_circleStore listing with screenshots and feature descriptions
• check_circleRelease notes for each version
• check_circleSupport contact and SLA information

Listing Review

Listing Review is run by ServiceNow’s marketing team rather than engineers, and it looks at what a customer sees: the app name, your company logo, the screenshots, and the listing copy—checking 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 it addresses up to 90% of the issues found in the first few iterations; in practice, plan for nearer 80%, and read the official figure for what it is—a ceiling, scoped to the common findings rather than the whole review.

Run it on the exact version you are about to submit. 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. Publish the version you want certified to the ServiceNow Store from your application record, which places the app in the application repository. Then 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.

Three documents go with it. 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. The team reviews, flags what needs changing, and you fix and resubmit the same way. A code change means a new version number and a fresh submission; a release recertification means retesting on the new family release and submitting updated results.

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 review—3 to 5 weeks. ServiceNow reviews your submission; how long it takes depends on their queue and how cleanly your app meets the criteria.

That is roughly 5 to 8 weeks from build start to Store listing, with discovery adding a week or two in front. Complexity can push any of it longer, and TPP enrollment is a separate prerequisite—start it well in advance.