Skip to content
threada Docs

ServiceNow Store

This guide defines the ServiceNow Store path after the Zapier public integration, Microsoft Teams Store, Google Workspace Marketplace, Atlassian Marketplace, Zendesk Marketplace, HubSpot App Marketplace, and Salesforce AppExchange work. It is a design and launch-control document, not evidence that a ServiceNow Store app has been uploaded, certified, listed, or approved.

Current Status

ServiceNow Store is planned as the final target in the active post-Slack integration-store wave. Threada already has a governed ServiceNow action proposal payload for service_now_create_incident in the public API action model and runtime automation support for posting to the ServiceNow incident Table API. A private ServiceNow Store app scaffold exists at packages/servicenow-store-app; it generates local private-scope app metadata, Store listing metadata, asset checklist, and submission-readiness blockers for governed Incident creation. Public setup and support guidance lives in ServiceNow setup and support.

No authenticated ServiceNow partner account, vendor instance, uploaded private-scope application, certified integration package, Store Publisher Portal submission, certification result, or listing approval has been observed in this repository.

Do not submit or market a public ServiceNow Store listing until the chosen ServiceNow package is built in the correct partner/vendor path, installable in a reviewer-safe ServiceNow instance, validated end to end, submitted through the Store certification/listing process, and approved by ServiceNow.

The existing ServiceNow action payload and committed scaffold remain tenant-specific governed action and package-preparation work. They should not be described as an approved public ServiceNow Store app.

The enterprise-safe first package should be a narrow ServiceNow Store app or certified integration that creates a governed ServiceNow Incident from a Threada WorkItem or ITSM request. Incident creation aligns with the live service_now_create_incident payload and avoids starting with broad request, change, problem, catalog, CMDB, attachment, user, group, admin, or knowledge-sync claims.

If ServiceNow requires a private-scope application for the public Store path, keep the scoped app limited to the minimum configuration, setup, and integration surface required for review. ServiceNow documentation says Store publishing requires a private application scope, Technology Partner Program participation, and certification; global-scope applications cannot be published to the Store.

Request, change, problem, catalog, CMDB, attachment, and knowledge-sync surfaces can follow only after Incident creation is installed, reviewable, scoped, idempotent, audited, and accepted.

Positioning

Threada for ServiceNow should let IT and operations teams create reviewable ServiceNow incidents from governed Threada work without bypassing Threada policy, approval, idempotency, and audit controls.

The narrow v1 app should stay focused:

  • Install or configure Threada through a ServiceNow Store-certified app or integration package.
  • Bind the ServiceNow instance to a Threada tenant, pack, queue, or workspace mapping.
  • Create a ServiceNow Incident only from an approved Threada action proposal.
  • Show clear setup-required, approval-pending, succeeded, and failed states in Threada.
  • Provide public setup/support documentation that explains least-privilege ServiceNow access, data handling, disconnect, uninstall, and retention behavior.

The v1 app must not claim that ServiceNow can execute arbitrary third-party actions through Threada. Direct external execution remains inside Threada’s governed Work, Studio, MCP, A2A, or first-party runtime paths.

Source Of Truth

Do not duplicate request or response schemas in this document. Public WorkItem shape and governed action proposal behavior are documented in Threada Public API and its generated OpenAPI artifact at /openapi/public-api.openapi.yaml. The committed source copy is docs/developers/public-api.openapi.yaml.

The committed package scaffold at packages/servicenow-store-app is the local source of truth for the intended v1 package posture: private scope, Incident Table API only, itil role posture, field allowlist, required public URLs, assets, certification documents, review behavior, and explicit non-goals. When real ServiceNow partner work starts, the ServiceNow app package, application scope, Store Publisher Portal records, certification design document, test plan, installation guide, selected releases, install/disconnect behavior, tenant mapping, reviewer setup notes, and ServiceNow approval result must become the source of truth for the public listing.

App Surface

Governed Incident Creation

The first reviewable capability should create a ServiceNow Incident from a Threada WorkItem or ITSM request. The implementation should use the chosen ServiceNow Store app or certified integration path, then let Threada create a governed action proposal that writes to ServiceNow only after the configured policy and approval path permits it.

Inputs should map to the live service_now_create_incident payload fields for short description, description, urgency, impact, caller email, assignment group, category, and tenant-approved custom fields. Field names and values must be allowlisted or tenant-configured so the public app cannot create noisy, misrouted, or overprivileged incidents.

Server-side ServiceNow API calls should use OAuth, a ServiceNow-approved credential posture, or a server-side Threada integration path. Do not use manually shared admin credentials, personal developer instance credentials, or customer-specific API tokens as the public Store install path.

Outputs must give the Threada user a clear success, setup-required, approval-pending, or failed state and preserve the ServiceNow incident reference when one is returned. Do not return only a generic success message; reviewers need to see the install-to-action-to-incident journey.

Request, Change, Problem, And CMDB Follow-Ons

Threada does not yet document public Store-ready governed payloads for ServiceNow request, change, problem, catalog, CMDB, attachment, or knowledge-sync surfaces. A Store listing can reference those capabilities only after the corresponding payloads, ServiceNow scopes/roles, tenant mapping, field allowlists, reviewer flow, audit behavior, and ServiceNow certification evidence exist.

Setup And Tenant Mapping

The app must bind a ServiceNow instance to a Threada tenant, pack, queue, or workspace mapping before claiming production readiness. If setup is incomplete, Threada should show a clear setup-required response instead of silently dropping the request or attempting an unauthenticated ServiceNow write.

Reviewer setup notes must include the exact ServiceNow test or vendor instance, ServiceNow test user role posture, Threada tenant, test pack or queue, install or configuration URL, expected incident fields, and cleanup instructions. Credentials, tokens, cookies, raw incident exports, requester PII, and customer data must stay out of repo evidence and screenshots.

Store Package Requirements

ServiceNow’s Store publishing documentation says Store apps must be created in a private application scope, the publisher must join the Technology Partner Program, and the application must be certified before publishing. ServiceNow’s app-publisher guidance also describes app review and listing review as distinct workstreams, with certification documentation such as a design document, test plan with results, and customer-facing installation guide.

Required package work before submission:

  • Confirm the current ServiceNow Technology Partner Program, Build Partner, vendor instance, Store Publisher Portal, and certification path with the Threada business owner and ServiceNow partner account.
  • Rebuild packages/servicenow-store-app with the real vendor instance ID, Store Publisher app ID, private scope ID, production URLs, support/privacy links, and evidence references. The default placeholder build is structural validation only and must not be submitted.
  • Create a private-scope ServiceNow application or certified integration package for the v1 ServiceNow surface. Do not build the public package in global scope.
  • Configure supported ServiceNow releases, app metadata, roles, properties, install behavior, and dependency posture.
  • Implement install/setup mapping, setup-required behavior, governed incident creation proposal, execution, idempotency, audit trail, and failure handling.
  • Use OAuth, a ServiceNow-approved credential posture, or a server-side Threada integration path for ServiceNow API access.
  • Limit ServiceNow Table API use to the incident fields required for v1 and document the roles required for that access.
  • Add field allowlists for short description, description, urgency, impact, category, assignment group, caller/requester, and custom fields before exposing them in public copy.
  • Prepare public setup/support, privacy, terms, security/data-handling, and data-deletion documentation.
  • Prepare the ServiceNow certification design document, test plan with results, customer-facing installation guide, listing copy, screenshots, demo media where required, reviewer account access, setup notes, expected incident output, and cleanup instructions.
  • Run the current ServiceNow self-test, validation, or publisher checks required by the Store Publisher Portal before submitting for App Review and Listing Review.
  • Complete ServiceNow certification, listing review, and approval before making public-readiness claims.

Explicit Non-Goals

  • No public ServiceNow Store claim until a first-class private-scope ServiceNow app or certified integration package exists and ServiceNow certification or listing review passes.
  • No global-scope app, update-set-only delivery, personal developer instance artifact, manually provisioned admin credential, or customer-specific API token as the public Store install path.
  • No unmanaged direct ServiceNow writes from the Store app.
  • No broad incident, request, change, problem, catalog, CMDB, attachment, user, group, admin, or export scopes unless the exact v1 capability requires them and the implementation is validated end to end.
  • No packaged ServiceNow knowledge sync claim until an authenticated, tenant-scoped, auditable sync path exists and is certified or otherwise approved for the Store path.
  • No customer-data screenshots, raw incident exports, ServiceNow instance dumps, OAuth tokens, cookies, or private tenant payloads in Store screenshots or review evidence.
  • No positioning as a generic “AI agent executes any ServiceNow action” app. Public copy must stay anchored to governed Incident creation, setup, and review.

Review Gates

Implemented:

  • Public API action types include service_now_create_incident.
  • Runtime automation can post a governed ServiceNow incident action to /api/now/table/incident for a tenant-scoped ServiceNow integration.
  • Public API docs and generated OpenAPI are published.
  • A private ServiceNow Store app scaffold exists at packages/servicenow-store-app for governed Incident creation package metadata, Store listing metadata, asset checklist, and readiness blockers.
  • Public setup/support guidance exists at ServiceNow setup and support.

Missing:

  • ServiceNow Technology Partner Program or Build Partner readiness, vendor instance, and Store Publisher Portal path.
  • Real ServiceNow partner/vendor app records, uploaded private-scope app or certified integration package, and Store Publisher app ID.
  • Install/setup mapping, setup-required, approval-pending, success, failure, idempotency, and audit behavior for a reviewer-safe ServiceNow instance.
  • OAuth or ServiceNow-approved credential posture for public install/review.
  • Incident field allowlist, role posture, and safe custom-field handling.
  • Certification design document, test plan with results, customer-facing installation guide, Store listing copy, screenshots, test instructions, setup notes, reviewer access, and cleanup instructions.
  • ServiceNow self-test/validation output, certification report, listing review, and approval evidence.

Blocked:

  • Public ServiceNow Store submission is blocked until the first-class ServiceNow package is built from real partner/vendor values, runtime behavior is implemented and testable, certification gates pass, reviewer setup is complete, and ServiceNow approves the listing.

Launch Checklist

  1. Confirm the active ServiceNow partner/vendor path, Store Publisher Portal access, supported releases, and certification submission requirements.
  2. Choose the v1 ServiceNow surface. Recommended first: governed Incident creation from a Threada WorkItem or ITSM request.
  3. Rebuild packages/servicenow-store-app with real ServiceNow partner/vendor values, production URLs, public setup/support links, and review evidence references.
  4. Create the private-scope ServiceNow app or certified integration package.
  5. Implement install/setup mapping, setup-required behavior, governed incident creation proposal, execution, idempotency, audit trail, and failure handling.
  6. Add OAuth or another ServiceNow-approved credential posture and Secret Manager storage for any Threada-owned secrets.
  7. Add an incident field allowlist and safe custom-field mapping.
  8. Use the public setup/support guide and prepare final Store listing copy.
  9. Create sanitized screenshots and demo material for install, setup, proposal, approval, execution, resulting ServiceNow incident, and disconnect.
  10. Prepare ServiceNow certification design document, test plan with results, customer-facing installation guide, reviewer credentials, test instance, setup notes, and cleanup instructions through approved channels.
  11. Run ServiceNow self-test or validation tooling required by the current Store Publisher Portal.
  12. Submit through ServiceNow App Review and Listing Review and resolve all certification issues before claiming Store readiness.

References