Skip to content
threada Docs

ServiceNow setup and support

Threada for ServiceNow is the planned ServiceNow Store integration for turning governed Threada work into reviewable ServiceNow Incident operations. The first reviewable package is intentionally narrow: it supports a private-scope ServiceNow Store app or certified integration path, ServiceNow instance mapping, setup-required feedback, governed Incident creation proposals, and safe links back to Threada. It does not create requests, changes, problems, catalog items, CMDB records, attachments, user/group/admin records, export jobs, packaged knowledge sync, or act as a generic ServiceNow AI agent.

This guide supports private ServiceNow reviewer testing once a Store review package is available and public ServiceNow users after ServiceNow certification and listing approval. Until the ServiceNow Store listing is approved, existing governed ServiceNow action payloads remain tenant-specific integration work and should not be treated as the public ServiceNow Store app.

Requirements

Before installing or testing the ServiceNow integration, make sure you have:

  • An active Threada tenant.
  • Studio or Admin access for the Threada workspace that should create ServiceNow Incidents.
  • A ServiceNow vendor, test, or reviewer-safe instance prepared for the reviewed package.
  • A ServiceNow user and role posture approved for the reviewed package. V1 should require only the role posture needed to create incidents, such as itil, unless ServiceNow certification requires a different reviewed posture.
  • A private-scope ServiceNow app or certified integration package prepared through the approved ServiceNow partner/vendor path.
  • A configured ServiceNow instance mapping in Threada for the reviewed package.
  • For private reviewer testing, the exact Store install or configuration URL, ServiceNow instance, reviewer user, setup notes, expected Incident fields, and cleanup instructions provided through the approved ServiceNow review channel.

Do not use production customer ServiceNow instances, customer incident records, raw exports, OAuth tokens, API tokens, cookies, admin credentials, personal developer instance credentials, or screenshots containing private tenant data for Store certification evidence.

Install the app

After ServiceNow approves the public listing, open Threada from the ServiceNow Store. During private review, use only the Store install path, vendor instance, or configuration link provided in the approved review notes.

  1. Open the ServiceNow Store listing or approved review install URL for Threada. The Threada-side install handoff URL is https://studio.threada.ai/integrations/servicenow/install; use it only with the approved Store package, certified integration, or private review notes for the reviewed ServiceNow instance.
  2. Review the app name, publisher name, pricing information, shared-data disclosure, privacy, terms, and support links.
  3. Install or configure the private-scope Threada app or certified integration.
  4. Confirm the package is installed in the reviewed private application scope.
  5. Confirm the integration uses the reviewed credential posture and incident role posture.
  6. Confirm ServiceNow shows the app as installed or configured and Threada shows the ServiceNow instance as connected.

If install or configuration fails, stop and fix the Store package, private scope, vendor instance, credential posture, production URL, role posture, certification documentation, or reviewer setup before continuing.

Connect ServiceNow to Threada

The ServiceNow integration must be mapped to a Threada tenant and receiving workspace before approved proposals can create Incidents.

  1. Sign in to Threada Studio with an admin or builder account.
  2. Open the workspace or pack that should create ServiceNow Incidents.
  3. Open the integration or channel setup area for ServiceNow.
  4. Bind the authorized ServiceNow instance to the Threada workspace or pack.
  5. Select the receiving queue, approval policy, duplicate-matching rule, and Incident field allowlist.
  6. Save the mapping and run the connection test if one is available.

If the reviewed build does not yet expose a self-service Studio mapping UI, follow the reviewer setup notes for the exact ServiceNow instance, Threada workspace, queue, allowlisted Incident fields, and cleanup steps prepared for review. Do not infer tenant mappings from instance names, user emails, caller emails, assignment group names, or incident titles alone.

Create a governed ServiceNow Incident

Create a ServiceNow Incident only through a governed Threada action proposal.

  1. Open or create the prepared Threada WorkItem or ITSM request.
  2. Create a ServiceNow Incident proposal using the reviewed workflow.
  3. Confirm the proposal shows the short description, description, urgency, impact, category, assignment group, caller/requester, correlation ID, and other allowlisted fields that will be sent to ServiceNow.
  4. Approve the proposal when the configured policy allows it.
  5. Confirm Threada shows a succeeded state and records the ServiceNow Incident reference.
  6. Open the Incident in ServiceNow and confirm the fields match the approved proposal.

Request, change, problem, catalog, CMDB, attachment, user/group/admin, export, and packaged ServiceNow knowledge-sync capabilities are follow-ons. They must not be marketed until the public app proves the required private-scope package, roles, field allowlists, tenant mapping, reviewer flow, audit behavior, and ServiceNow certification evidence.

Setup-required responses

If the integration is installed or authorized but not connected to a Threada tenant or workspace, Threada should show a setup-required response instead of silently dropping the request or attempting an unauthenticated ServiceNow write.

Common setup issues:

  • The ServiceNow instance is not mapped in Threada.
  • The mapped Threada workspace or pack was disabled.
  • The receiving queue, duplicate-matching rule, or approval policy is missing.
  • Required Incident field allowlists are incomplete.
  • The Store package still uses placeholder vendor instance, Store Publisher app ID, scope ID, install URL, support, privacy, terms, or setup identifiers.
  • The app points to a development, staging, ngrok, or otherwise non-production Threada URL.
  • The credential posture, role posture, Table API permission, disconnect, or uninstall handling failed.
  • Certification design document, test plan with results, installation guide, self-test or validation output, App Review, Listing Review, or reviewer notes are missing.

For review builds, include the ServiceNow instance, Threada workspace, proposal ID, approximate test time, and sanitized error text in support requests. Do not send admin passwords, OAuth tokens, API tokens, cookies, requester PII, incident exports, incident lists, or private incident content.

Disconnect or uninstall

To stop creating ServiceNow Incidents:

  1. In Threada Studio, disable or remove the ServiceNow mapping for the workspace, pack, or instance.
  2. Revoke the reviewed credential posture or uninstall the Threada Store app in ServiceNow if the instance should no longer be connected.
  3. Run the reviewed test workflow and confirm Threada returns setup-required feedback rather than creating an Incident.

Disconnecting the integration stops future ServiceNow Incident writes. Existing WorkItems, proposals, approvals, ServiceNow Incident references, and audit events remain available in Threada according to the tenant retention policy.

Data handling

For v1, Threada stores the ServiceNow instance mapping, authorization or credential metadata, ServiceNow Incident identifiers returned by ServiceNow, and the Incident fields required for approved Incident creation. Threada uses this data only to create governed ServiceNow Incidents, show setup and execution status, support disconnect/uninstall, and maintain an auditable record.

The public install path must use a ServiceNow-approved Store package and credential posture for multi-customer distribution. Do not use global-scope app delivery, update-set-only delivery, personal developer instance artifacts, manually provisioned admin credentials, or customer-specific API tokens as the public Store install path. The shared-data disclosure in the listing must match the selected roles, tables, and v1 Incident data flow.

If a future version adds requests, changes, problems, catalog, CMDB, attachments, users, groups, admin records, exports, or packaged knowledge sync, Threada must update this guide, explain the exact data use, complete the required security and privacy review, and submit the updated app for ServiceNow review before marketing the new capability.

Support

For setup help, contact support@threada.ai. For privacy or deletion requests, contact privacy@threada.ai. To report a security issue, contact security@threada.ai.

Support requests for the ServiceNow integration receive a response within 2 business days. Include the Threada tenant, ServiceNow instance, proposal or Incident reference when available, app version when known, approximate test time, and sanitized error text. Do not send secrets, tokens, cookies, incident exports, customer data, screenshots containing customer data, or raw Table API logs.