ServiceNow platform assessment — TSANet Connect Developer Hub

Read this before you use anything below

Every claim on this page is documented, not observed — somebody read it in vendor documentation or a community thread, not that anybody watched it work. That distinction has mattered before: on the most recent platform TSANet assessed, published documentation turned out to be wrong or silent on the majority of the findings that ended up shaping the design.

Treat this as a research map with citations. Anything marked needs probe is a known unknown rather than an oversight, and the first verified fact on this page will be the first one worth designing against.

ConnectorNot built. Development committed for 2026.

ArchitectureOpen. Not settled publicly or internally.

ProbeNone run. No live instance tested.

Getting involvedEarly access enquiries to membership@tsanet.org

documented read in vendor docs or community sources needs probe unverified, and known to be unverified

Platform shape

Why ServiceNow does not fit either existing pattern

TSANet's connectors so far divide by one question: will the platform run your code inside the member's own tenant? Salesforce and Dynamics say yes and get managed packages. Intercom says no and gets a TSANet-hosted gateway. Zendesk sits between.

ServiceNow answers both at once, and that is the whole difficulty. It will happily run installed code — scoped applications are the native extension model. But it hosts none of the UI for you and provides no native webhooks. There is no Canvas Kit and no ZAF analogue: if an agent is to see anything, it is either code installed in their instance or a page served from somewhere else and framed in.

The platform settles the first question and leaves the second open. Because an installed component is unavoidable either way, the architecture decision does not change whether a member installs something — only how much of the integration lives in there, and therefore how often they have to upgrade it.

Agent surfaces

Where a collaboration panel could live

Two UI families, and a member is on one or the other. Classic UI means a UI Action opening a UI Page or modal on the Incident or Case form. Configurable Workspaces on Next Experience means UI Builder components on the record page. An app covering both typically ships a UI Action — which surfaces in each — plus optional workspace components. documented
Legacy Agent Workspace is not a target. Support ended at the Washington DC release. documented
The closest thing to a hosted surface is an iframe. The UI Builder now-iframe component can point at an externally served page and supports a postMessage channel back. That is the mechanism by which any hosted UI would appear. documented
Whether that iframe actually renders on the record page an agent works is unverified. Community reports say yes on CSM and Service Operations workspaces. This is the single highest-risk unknown on the platform, and it is precisely the class of question that can only be closed by installing the thing and looking — the equivalent question on the last platform assessed came out fine, but only after someone pinned the app and checked. needs probe
No platform-enforced render deadline in the way a server-rendered canvas has one, since the iframe loads a page served elsewhere. The latency that matters instead is the Table API's own round-trip, because that is what the agent waits on. needs probe

Table API

Traps to design around

Several of these rhyme with traps found on other platforms, which is a reason to take them seriously and not a reason to assume they behave identically.

Unknown fields are reportedly accepted and silently dropped. An invalid or misspelled field name is said to return 200/201 with the value discarded. If a probe confirms it, read-back-and-assert becomes a standing rule for every write on this platform. needs probe
Journal fields are write-only append, and this one bites hardest. work_notes and comments accept writes but read back empty unless you pass sysparm_display_value=true or query sys_journal_field by element and element id. An adapter that writes a note and reads the record back to verify will see nothing and conclude the write failed — when it succeeded. documented
Display values versus raw values. sysparm_display_value switches between sys_ids and labels; reference fields otherwise return {value, link} objects. Pick one convention per call site and hold it. documented
Create returns the record including sys_id, which is the handle everything downstream needs. documented
Custom fields are prefixed — u_ in global scope, or x_<vendor>_<app>_ when they belong to a scoped app. Rename behaviour is unverified. needs probe
ACLs can silently block writes by the integration user. This presents almost identically to the unknown-field trap and has a completely different fix, so the diagnostic has to distinguish them. documented
Rate limits are member configuration, not a platform constant. Limits come from per-instance Rate Limit Rules; with no matching rule there is no enforced default and no rate-limit headers at all. Violations return 429 with Retry-After. documented

Pagination has a correctness trap, not just a performance one. Offset pagination silently drops records when rows change mid-pagination, and sys_updated_on has one-second granularity and is not unique. A poller therefore needs a keyset cursor on the pair (sys_updated_on, sys_id) — a plain timestamp cursor will lose records that share a second. documented

Events

No native webhooks, and a licensing trap in the workaround

Nothing on the platform pushes to an external endpoint by default. Outbound delivery is configured inside the instance, and there are two ways to do it — which is where the trap is.

Mechanism	Licensing	Verdict
Async Business Rule calling `RESTMessageV2`	Base platform	The one to build on
Flow Designer REST step	Consumes IntegrationHub transactions	Costs the member per event
IntegrationHub spoke	Consumes IntegrationHub transactions	Costs the member per event

Keeping any installed app on scripted outbound REST is therefore not a style preference — the alternative bills the member's IntegrationHub entitlement on every event the integration emits. documented

Signing inverts the usual question. There is no native HMAC toggle for outbound REST; Basic auth, OAuth provider profiles, arbitrary headers and mutual TLS are supported. Because the emitter is code you ship, you specify the signing scheme rather than discovering it — a rare position to be in, and one worth using deliberately. documented
Delivery is not guaranteed by the platform. executeAsync routes through the ECC queue and can retry via ECC Failure Retry; synchronous calls cap at 30 seconds and the general outbound timeout defaults to 175. At-least-once delivery is something the installed app builds — a queue table plus a scheduled job — not something the platform provides. documented
Payload shape is yours to define, for the same reason the signature is. documented
Polling is a legitimate primary path, not just a fallback, and may be the only option where a member blocks inbound traffic. Query the Table API filtered on sys_updated_on, with the keyset cursor described above. documented

Object model

Three candidate homes for a collaboration case

Unusually, the right answer here is probably per member rather than per platform.

Option	Consideration
ITSM `incident`	Natural for ITSM shops, but puts partner collaborations into queues the member's own team already works
CSM `sn_customerservice_case`	Natural for customer-service shops; case types extend this table
Dedicated companion task table	Keeps TSANet cases out of existing queues entirely. This is the shape a well-known publicly listed ServiceNow integration chose for exactly this problem

The one that must not be got wrong: note visibility. work_notes are internal; comments are customer-visible. Partner collaboration content is not customer-facing by default, so inbound partner notes belong in work_notes unless a member explicitly asks otherwise. Getting this backwards publishes another vendor's content to the member's end customer. documented

"eBonding" is the platform's own word for cross-company ticket exchange, and it is the vocabulary to use with ServiceNow-side stakeholders. There is an out-of-the-box eBonding spoke for ServiceNow-to-ServiceNow, and an established third-party middleware market — so an externally hosted hub bonding tickets across companies is a well-precedented pattern here, not a novel one. documented
The eBonding convention for a foreign identifier is the Task table's correlation_id and correlation_display. Whether that field is efficiently searchable decides how load-bearing an integration's own link table has to be. needs probe
Whether a CSM case type can be created via API rather than by admin action is unverified. needs probe
Status mapping is deliberately not proposed here. OPEN / INFORMATION / ACCEPTED / CLOSED / REJECTED — and PENDINGACTION, which the API enum also carries — have to land on whichever object model a member uses, and inventing a ServiceNow-local convention before that choice is made would add a dialect rather than settle one.

Tenancy & auth

Per-instance, and reachable only sometimes

Every member has their own instance at https://<instance>.service-now.com, publicly reachable by default. documented
But inbound access is a per-member question, not an assumption. Customers can enable IP Address Access Control, and security-conscious enterprises do — an entire third-party static-IP proxy market exists to serve integrations that hit this. Any externally hosted component needs stable egress addresses, and where ingress is blocked the traffic direction inverts: the instance polls out instead. This is the single most likely thing to reshape a design per member. documented
Regions do not change the host for commercial instances regardless of hosting country. The exception is US Government Community Cloud, which uses servicenowservices.com. Store a full base URL per member rather than deriving one from an instance name. documented
Server-to-server auth is an OAuth client registered in the member's own instance, client-credentials grant, bound to a dedicated OAuth Application User — available from the Washington DC release onward. Older instances fall back to Basic auth on a dedicated integration user. Inbound API keys with HMAC and inbound mutual TLS exist as separate mechanisms. documented
Secret rotation appears to be a manual admin action. Unverified, and it matters for the credential runbook. needs probe
Members will span two or three release families at any time. Two family releases ship a year and customers upgrade on their own schedules, so anything built has to tolerate a trailing-edge instance. The Table API itself is URL-versioned and has been stable for years; it is the auth surface that varies with release level. documented

Distribution

Certification gates the Store, not the platform

A member's admin can install a third-party scoped app directly, with no ServiceNow review, no partner program and no fee — by update-set XML import, or by source-control import in Studio. That is the same private-install model TSANet already uses elsewhere. documented

Channel	What it costs	What it buys
Update set / source-control import	Nothing. Each member's admin imports each version by hand	Viable immediately; fine at pilot scale
ServiceNow Store	Certification review per submission (reported 3–5 weeks), partner-program membership, and development on provisioned vendor instances rather than a developer instance	Listing, plus versioned push-install across customers

Recertification recurs. New app versions with code changes and new release families both require it — which makes the recertification cadence a direct function of how often the installed component has to change. documented
Without the Store there is no central upgrade push. The app repository is intra-company only, so every member's admin imports every version. Manageable for a pilot, painful across a fleet. documented
A member's own IT governance may require a certified app regardless. That is member policy rather than a ServiceNow rule, and it is an onboarding question. documented
Development runs on a free Personal Developer Instance, which is adequate for the Table API, Business Rules, UI Builder, and — importantly — update-set and source-control installs. It hibernates when idle and is reclaimed after roughly ten days of inactivity, so treat anything built there as disposable and keep artifacts in version control. A PDI cannot install Store apps. documented

Open questions

What has to be answered, and what each one blocks

These are listed because they are unresolved, not because they are hard. Each blocks real design work downstream.

Question	Blocks
How much of the connector lives in the installed app	Everything. It decides what a member installs and how often they upgrade it
Does `now-iframe` render on the Incident and Case record pages an agent actually works	The agent surface, and therefore the entire outbound flow design
Is the unknown-field silent-ignore real on the Table API	Whether read-back-and-assert is mandatory on every write
Which object holds a case, per member	Object mapping, token placement, status mapping
Is the correlation field efficiently searchable	How load-bearing an integration's own link table has to be
Per-member ingress: can an external service reach the instance, or must the instance poll out	Inbound topology — and it may differ member to member
Secret rotation mechanics for an instance-registered OAuth client	Credential lifecycle and the operational runbook
Whether any member's own policy requires a Store-certified app	Distribution path and the cost model

Interested in shaping this? ServiceNow members who want to influence the design — or to be a pilot instance once a spike has run — should contact membership@tsanet.org. A member willing to lend a real instance and a real workflow is worth more at this stage than any amount of further desk research.