How to Publish an App on the ServiceNow Store

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:

The publishing process, step by step

1. Enrol in the Technology Partner Program. Company-level commercial agreement with ServiceNow. Begin early.
2. Obtain Build Partner designation. The tier that permits Store publishing.
3. Get vendor instances provisioned. Two are typically provided. All development and submission happens here.
4. Architect the scoped application. Namespace, data model, role model and API boundary agreed before build.
5. Build to certification standards. Develop against the review criteria rather than correcting afterwards.
6. Run the self-test tooling. Validate the application on the exact version you intend to submit.
7. Prepare submission documentation. Test plan, design document and installation guide to ServiceNow's templates.
8. Submit through the Store Publisher Portal. App review and listing review are separate assessments.
9. Respond to review findings. Triage, remediate and resubmit promptly — delay here extends the cycle considerably.
10. Complete the listing. Pricing model, marketing content and support contact for enterprise buyers.
11. 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.