To publish an app on the ServiceNow Store you must enrol in ServiceNow's Technology Partner Program, obtain Build Partner designation, develop your application as a scoped app on a provisioned vendor instance, and pass ServiceNow's certification review covering security, performance, code quality and documentation. The review itself typically takes three to five weeks, and most teams should plan five to eight weeks from build completion to a live listing.
Why the Store matters for enterprise ISVs
If your buyers are enterprises running ServiceNow, the Store removes the single largest source of friction in your sales cycle: vendor security review. A Store-listed application arrives through a channel their procurement and security teams already trust, with certification ServiceNow has performed. For a product that would otherwise face months of bespoke review at every account, that is a structural advantage rather than a marketing one.
The trade-off is that listing is a genuine engineering and compliance exercise, not a submission form.
The prerequisites nobody can bypass
Technology Partner Program enrolment
Publishing requires a commercial relationship with ServiceNow through the Technology Partner Program. This has its own terms, approval process and timeline, and it sits with your company — a development partner cannot enrol on your behalf. Start it early; it frequently takes longer than teams expect.
Build Partner designation
Within the partner programme, Build Partner designation is what permits publishing applications to the Store. Requirements and tiers change over time, so confirm the current position directly with ServiceNow rather than relying on any third-party summary, including this one.
Vendor instances — not a PDI
This trips up more teams than any other prerequisite. Store applications must be developed and submitted from provisioned vendor instances. A Personal Developer Instance is for learning and prototyping; a customer instance is for production. Neither supports Store app development or certification. Building a prototype on a PDI and expecting to submit it is a rebuild waiting to happen.
Architecture decisions made in week one
The decisions that determine whether certification is achievable are all made before meaningful code exists.
- Scoped, never global. Your application must live in its own scope with an explicit API boundary. Global-scope prototypes are not certifiable and require re-architecture.
- Data model designed up front. Tables, relationships and extension points reviewed before build. This is the decision most expensive to reverse.
- Least-privilege role and ACL model. Designed alongside the data model, not retrofitted. Access control is the most common source of review findings.
- Supported APIs only. Using undocumented or unsupported platform internals will fail review and will break at a family release even if it does not.
What certification review examines
Reviewers assess the application against published criteria. The areas that generate most findings:
| Area | What reviewers look for |
|---|---|
| Access control | ACL coverage on every table, least privilege enforced, no privilege escalation paths |
| Credentials | No hardcoded secrets in script, update sets or logs; credentials in the platform store |
| Input validation | Injection protection, payload validation at every boundary |
| Data handling | What is stored, where, for how long, and what leaves the instance |
| Third-party dependencies | Bundled libraries reviewed for licence compatibility and known vulnerabilities |
| Upgrade safety | Scoped isolation, supported API usage, no reliance on platform internals |
| Documentation | Architecture, security model, installation, configuration and upgrade notes |
The publishing process, step by step
- Enrol in the Technology Partner Program. Company-level commercial agreement with ServiceNow. Begin early.
- Obtain Build Partner designation. The tier that permits Store publishing.
- Get vendor instances provisioned. Two are typically provided. All development and submission happens here.
- Architect the scoped application. Namespace, data model, role model and API boundary agreed before build.
- Build to certification standards. Develop against the review criteria rather than correcting afterwards.
- Run the self-test tooling. Validate the application on the exact version you intend to submit.
- Prepare submission documentation. Test plan, design document and installation guide to ServiceNow's templates.
- Submit through the Store Publisher Portal. App review and listing review are separate assessments.
- Respond to review findings. Triage, remediate and resubmit promptly — delay here extends the cycle considerably.
- Complete the listing. Pricing model, marketing content and support contact for enterprise buyers.
- Plan for recertification. Store apps can require recertification, and your customers will upgrade.
Realistic timelines
Certification review typically runs three to five weeks. End to end, plan roughly five to eight weeks from a completed, standards-compliant build to a live listing. Add to that your own build time and, critically, the partner programme enrolment which runs on ServiceNow's schedule rather than yours.
The variable that most extends timelines is rejection cycles. A submission that comes back with access control findings and hardcoded credentials — the two most common — can add weeks. This is why pre-submission review is worth more than it costs.
The mistakes that cost the most
- Prototyping in global scope on a PDI. Guarantees a rebuild.
- Treating certification as a final gate. It is a construction standard, not an inspection.
- Starting partner enrolment last. It is frequently the longest-lead item.
- No plan for family releases. A listed app has customers who upgrade; define your release testing process before you list.
- Writing the listing for engineers. Enterprise buyers search for workflows and outcomes, not architecture.
Is the Store worth it for your product?
It is worth it if your buyers are ServiceNow customers and procurement friction is genuinely slowing your sales cycle. If enterprise security review is adding months to every deal, the Store removes much of that. If your buyers are not on the platform, listing will not create demand that does not exist — and any partner who tells you otherwise is selling you a project rather than an outcome.
⚡ Key takeaways
- Store publishing requires TPP enrolment, Build Partner designation and provisioned vendor instances — a PDI will not do.
- Certification review typically takes 3–5 weeks; plan 5–8 weeks from finished build to live listing.
- Scoped architecture and least-privilege ACLs must be decided in week one; retrofitting is the expensive route.
- Access control gaps and hardcoded credentials are the two most common causes of rejection.
Certified ServiceNow consultants and AI practitioners sharing what we learn delivering implementations, agentic AI, and managed services for US enterprises.