sn vs. the alternatives

Clicking through the UI

Studio, UI Builder, the form layout editor, the Flow Designer canvas, manual update sets. This is how most ServiceNow work has been done for fifteen years, and it’s how most of it still gets done today.

What this gets right. Visual feedback is immediate. Junior developers can start producing real output within a day. There’s no build step, no toolchain, no framework churn. Every artifact lives where you’d expect it on the platform, which matters during a live client demo. For work that is inherently visual — a portal page, a complex form layout, a Flow Designer trigger — the built-in tools are simply the right answer.

What this costs at scale. Nothing you build is reusable across engagements without manual re-creation. Nothing you build is covered by automated tests unless someone separately writes ATF suites by hand. Nothing you build is code-reviewable before it lands on the instance. The update set is the only version history, and update sets don’t diff. A junior who mis-clicks a reference field at 4:55pm on a Friday is a Monday-morning client incident. And the same artifact you build for Client A takes the same hours to rebuild for Client B.

Under time-and-materials, most of those costs were absorbed by the billing model. Under fixed-price engagements, they come straight out of margin. None of this is a reason to stop using the UI — some work belongs there. It’s a reason not to build your entire delivery model on it.

@servicenow/sdk (the Fluent DSL)

ServiceNow’s own TypeScript SDK, published on npm as @servicenow/sdk. It lets you declare artifacts in a typed DSL that compiles to a Now Experience XML update set you then deploy to the instance.

What this gets right. It is the first-party, officially supported answer to “how do we put ServiceNow artifacts under version control and review them as code.” The DSL is typed, composable, and reviewable in a PR the way any other code change would be. For the artifact types Fluent supports well, it is a genuine step change over clicking through the UI, and the fact that it’s officially supported by ServiceNow is a real advantage — especially for firms where “first-party” is a procurement checkbox.

Where the gaps are, honestly. Fluent’s artifact coverage is partial — several primitives that show up in real consulting work (certain catalog patterns, parts of Flow Designer internals, some instance-scan shapes) either aren’t there yet or are thinly supported. The SDK also doesn’t manage the update-set lifecycle on the target instance: you produce an XML bundle, you upload it, and what happens next is not Fluent’s problem. There is no first-class execute → validate → test loop, no built-in backout, and no story for idempotent re-runs if a deploy fails partway through. These aren’t criticisms of the design; Fluent is a code-to-XML compiler, and it’s a good one. They’re reasons the SDK alone doesn’t cover everything a consulting firm needs for a production delivery workflow.

We respect the project enough that sn has a first-class sn export-sdk command that takes a manifest and emits a Fluent project — so if a client standardizes on @servicenow/sdk, you can still develop in sn and hand them a Fluent export at the end.

AI guessing the ServiceNow API

“Just ask Claude to write a runScript that creates the business rule” is the fastest-growing way ServiceNow work gets done this year. It deserves a fair look.

What this gets right. It is fast. The first manifest an AI produces for a new artifact type feels like magic, and for throwaway exploration work that’s a real gain. AI is also unreasonably good at reading existing code and explaining it, which is a productivity lift independent of the tooling question. And in a world where clients are pricing in what AI can do, “we use AI aggressively” isn’t a differentiator anymore — it’s the baseline.

What this costs the minute it isn’t throwaway. The model guesses field names, and ServiceNow has a lot of close-but-wrong fields (collection vs table, when vs timing, order vs sequence). It writes code that creates a new record every time it runs, because nothing told it to check for an existing one. It can’t see the table schema unless you paste it in. It has no way to verify the artifact landed correctly on the instance — it can only look at what it generated, not at what the API actually accepted. When the model is wrong, it is wrong confidently, and the first time anyone learns about it is when a client reports a duplicate record.

The fix for this isn’t to stop using AI. That option left the building. The fix is to give the AI a constrained surface to work against: a schema it can query, an operation set it can enumerate, and a runner that is idempotent by construction. That’s what sn is.

sn’s approach

sn is a single binary CLI that sits between your team (plus the AI assistants they use) and the target ServiceNow instance. The pieces that matter are structural, not add-ons:

• Idempotent by default. Every operation is an upsert against a stable key. Re-running a manifest after a partial failure updates existing records and fills in the missing ones. No duplicates, no cleanup scripts. This is the single most important property for making fixed-price delivery work — a failed deploy is recoverable, not a rework engagement.

• Update-set lifecycle on the instance. sn opens the update set, activates it for the session, tracks every record it writes, validates at the end that nothing leaked into Default, and offers sn backout <sys_id> when something needs to come back out.

• Execute → validate → test as first-class commands. After sn execute lands records, sn validate confirms they’re structurally correct and tracked correctly, and sn test runs ATF suites, instance scans, and catalog lifecycle checks declared in the same manifest. That means the SOW line item “tested and validated” is a command you can run, not a line in a status report.

• AI-native schema discovery. sn ops and sn ops --json expose every skill, operation, and input schema in a form an AI assistant can enumerate and validate against. Claude doesn’t guess at collection vs table on a business rule — it checks.

• Ships with scoped AI instructions. Installing sn drops a .claude/sn-skills.md file into the project, which tells the AI exactly what skills exist and how to use them. The model works against a fixed API, not against the whole ServiceNow platform.

Honest comparison

What sn doesn’t solve

A few things sn is deliberately not trying to be:

• A visual designer. If the work is figuring out a Flow Designer canvas, laying out a portal page, or previewing a UI Builder screen, the native tools are the right surface. sn is for the parts of delivery where the intent is code-shaped.

• Complete artifact coverage on day one. The skill set covers most of what consulting-firm work touches — business rules, script includes, catalogs, flows, ATF, instance scans, decision tables, and more — but there are still corners where the right answer is to drop to a Fluent export or a direct UI action. We’re adding coverage; we’re not pretending the list is done.

• A replacement for TypeScript literacy. AI can write manifests, but reviews still happen, and reviews require someone who can read a .ts file.

• A client-data tool. sn manages platform configuration — the shape of the instance — not operational data like tickets, users, or CMDB rows. Those belong in different tools.

• First-party software. We are independent of ServiceNow. If that matters to your procurement path, factor it in up front.