Building ServiceNow® Apps with Claude Code and the Now SDK: An Agentic Developer Workflow

This article is human-conceptualized but written with the assistance of AI and may include some inaccuracies. Always validate independently. — DLYog Lab Research Services LLC is an independent research entity, not affiliated with or endorsed by ServiceNow, Inc. See footer for full disclaimer.

ServiceNow AI Platform Architecture

ServiceNow is not a single product — it is a layered enterprise platform. Understanding its structure is key to understanding why the SDK + Claude Code workflow fits so naturally.

Key ServiceNow Concepts for AI Developers

If you are an AI or software developer new to the ServiceNow ecosystem, these eight terms are the minimum vocabulary you need to be productive. Everything else builds on them.

ServiceNow Is Not Pure SaaS — The MID Server Bridge

One of the most misunderstood aspects of ServiceNow is the assumption that it is a closed cloud product. It is not. Enterprises run ServiceNow against their own on-premises infrastructure — databases, LDAP directories, VMware clusters, proprietary APIs, legacy systems — through a lightweight agent called the MID Server. Understanding this is essential for any AI developer building integrations.

What the MID Server Actually Does

The MID Server is a Java application (OpenJDK-based, no Oracle license required) deployed as a Windows service or Linux daemon inside the enterprise firewall. It polls the ServiceNow cloud via an outbound-only HTTPS connection — the cloud never opens an inbound connection to the enterprise. This single design decision makes enterprise adoption practical: no DMZ, no open inbound ports, just outbound port 443.

Once running, the MID Server enables four critical enterprise capabilities:

• Discovery — scans the internal network (SSH/SNMP/WMI) to find devices, servers, and applications, then auto-populates the CMDB
• Orchestration — executes remediation scripts and workflow actions on on-premises infrastructure
• Integration relay — bridges IntegrationHub spokes (180+ pre-built connectors) to on-premises systems like LDAP, VMware, databases, and custom REST APIs
• AI/LLM hosting — in the Zurich release, the MID Server can host a local MCP server and Ollama-based language models, enabling air-gapped or data-sovereign AI inference

Exposing On-Premises Services as MCP Tools to Now Assist

This is where things get interesting for AI developers. Starting with the Zurich release (Patch 4+), ServiceNow shipped native Model Context Protocol (MCP) support in both directions:

• ServiceNow as MCP Server — exposes Now Assist Skills as MCP tools via the built-in MCP Server Console. External AI clients (Claude, ChatGPT, Cursor, Copilot) can discover and call these tools automatically using OAuth 2.1 + PKCE authentication.
• ServiceNow as MCP Client — Now Assist AI Agents can call external MCP tools, including tools running on a MID Server inside the enterprise network.

The practical implication: any on-premises service can be wrapped as an MCP tool and made available to Now Assist as live context. A proprietary database, a legacy ERP API, an internal knowledge base, a local LLM — all can be exposed through the MID Server's MCP hosting capability and consumed by AI agents running in the ServiceNow cloud.

Think of it as a universal adapter: any service your enterprise runs — regardless of age, vendor, or protocol — can be surfaced to ServiceNow's AI layer as a typed, discoverable tool. The AI agent does not need to know how the ERP works internally. It just calls the tool and gets a result.

The Two Worlds of ServiceNow Development

Before diving into how we built the app, it helps to understand the landscape. ServiceNow is an enterprise platform that runs applications inside scoped apps — sandboxed namespaces that bundle tables, roles, business logic, and UI configuration together. Historically, developers create and manage these entirely inside the platform through a browser-based IDE called Studio.

The Now SDK introduced a fundamentally different path: write code locally, compile it, and push it to the instance. Both approaches produce identical artifacts on the platform. The difference is everything about the developer experience.

ServiceNow Architecture: What a Scoped App Actually Is

To understand what we're building, it helps to know how ServiceNow organizes applications under the hood. Every custom application runs inside a scope — a namespace that isolates its data, scripts, and metadata from other applications and the global platform. A scope looks like x_<company_code>_<app_name>. Our app uses the scope x_snc_itasset.

Within that scope, every artifact type maps to a platform table. When you define a table, a business rule, or an email notification in Fluent, the SDK compiles it to the corresponding sys_metadata record that ServiceNow already knows how to handle. Nothing proprietary — just metadata in a structured format the platform natively understands.

What is Claude Code?

Claude Code is Anthropic's AI coding agent that runs directly in your terminal. Unlike autocomplete tools, Claude Code reads your entire repository, executes commands, edits files, and follows multi-step instructions autonomously. It can scaffold a project, write all the source files, run the build, interpret errors, and fix them — all in one conversational session.

What makes it powerful for ServiceNow development specifically is the plugin and skills system. ServiceNow open-sourced a set of build skills packaged as a Claude Code plugin that gives the agent deep knowledge of:

• Every Fluent API (Table, BusinessRule, Acl, EmailNotification, and 50+ more)
• Scoped app conventions, naming rules, and common pitfalls
• The correct patterns for before/after business rules, module imports, and Now.include()
• ACL evaluation order, the "trinity" (roles AND condition AND script), and deny-unless patterns
• Event registration requirements and the 40-character event_name limit

This knowledge is not baked into the model's training data — it is injected at runtime from markdown skill files that ship with the SDK itself. The documentation versions with the SDK, so the agent always works from docs that match the installed version.

Installing Claude Code with ServiceNow Plugin

# Install Claude Code (Mac/Linux)
curl -fsSL https://claude.ai/install.sh | bash

# Inside Claude Code, install the ServiceNow plugin
/plugin marketplace add servicenow/sdk
/plugin install fluent
/reload-plugins

What is the Now SDK (Fluent)?

The ServiceNow SDK (@servicenow/sdk) is a Node.js CLI toolkit that introduces Fluent — a TypeScript-based domain-specific language for defining ServiceNow metadata. Instead of clicking through forms to create a table, you write a TypeScript file:

import '@servicenow/sdk/global'
import { Table, StringColumn, DateColumn, ReferenceColumn } from '@servicenow/sdk/core'

export const x_snc_itasset_hardware_asset = Table({
    name: 'x_snc_itasset_hardware_asset',
    label: 'Hardware Asset',
    display: 'asset_tag',
    schema: {
        asset_tag: StringColumn({ label: 'Asset Tag', mandatory: true }),
        purchase_date: DateColumn({ label: 'Purchase Date' }),
        warranty_expiration_date: DateColumn({ label: 'Warranty Expiration Date' }),
        vendor: ReferenceColumn({
            label: 'Vendor',
            referenceTable: 'x_snc_itasset_vendor_contact',
            cascadeRule: 'none',
        }),
    },
})

Run now-sdk build and this compiles to the exact same table record that Studio would create. The SDK supports the full spectrum of ServiceNow development: tables, columns, roles, ACLs, business rules, flows, client scripts, service catalog items, UI pages, REST APIs, and more.

The App We Built: IT Asset Tracking

To demonstrate the agentic workflow end-to-end, we built a realistic enterprise application: an IT Asset Tracking system that lets Asset Managers manage hardware inventory, software licenses, and vendor contacts, while Read-Only Viewers can browse records without editing them.

The requirements came from a single PRD.md file placed at the project root. Claude Code read the PRD and translated every business rule, relationship, and notification requirement into production Fluent code with no manual scaffolding.

Data Model

Three tables form the core data model, with the Vendor Contact serving as a shared lookup for both hardware and software records:

Project Architecture: Files and Folders

The Now SDK organizes source into two directories: src/fluent/ for metadata definitions (.now.ts files) and src/server/ for server-side JavaScript modules. The agent structured the project by artifact type, which aligns with SDK conventions.

Step-by-Step: How Claude Code Built This

Step 1 — Scaffold the Project

With a single init command, the SDK creates the project skeleton with now.config.json, package.json, and the required SDK/Glide devDependencies. The scope name follows the x_<company_code>_<app_name> convention required for non-admin scopes.

npx @servicenow/sdk init \
  --appName "IT Asset Tracking" \
  --packageName "it-asset-tracking" \
  --scopeName "x_snc_itasset" \
  --template "base"

npm install

Step 2 — Claude Code Reads the PRD and Fetches SDK Docs

The agent was told: "read @PRD.md and build the ServiceNow app." Before writing a single file, Claude Code invoked the fluent:now-sdk-explain skill to read the SDK documentation — fetching the full reference for tables, roles, ACLs, business rules, email notifications, scheduled scripts, and the event registration guide. This is what separates an agentic SDK workflow from a generic code generator: the agent knows the platform's specific rules, not just general TypeScript.

Critical rules the agent learned from the docs before writing code:

• The exported variable name of a Table() must exactly match the name property — a mismatch causes build failures
• Event names in scoped apps have a 40-character maximum — silently truncated otherwise
• Scheduled script script property is string-only (no ES module imports) — use Now.include() for file-based scripts
• Business rules using server modules can use ES module imports via @servicenow/glide
• Engine-based email notifications (generationType: 'engine') do not need a triggering business rule

Step 3 — Roles and ACLs

Two roles are defined first because ACLs reference them. The security pattern covers all four CRUD operations per table — twelve ACLs total. Read access grants both roles; write, create, and delete restrict to asset managers only.

export const assetManagerRole = Role({
    $id: Now.ID['asset_manager_role'],
    name: 'x_snc_itasset.asset_manager',
    description: 'Can create, edit, and retire assets and licenses.',
})

export const readOnlyViewerRole = Role({
    $id: Now.ID['read_only_viewer_role'],
    name: 'x_snc_itasset.read_only_viewer',
    description: 'Read-only access to all asset records.',
})

// Read: both roles. Write/Create/Delete: asset manager only.
Acl({
    $id: Now.ID['hardware_asset_read'],
    type: 'record',
    table: 'x_snc_itasset_hardware_asset',
    operation: 'read',
    roles: [assetManagerRole, readOnlyViewerRole],
    adminOverrides: true,
})

Step 4 — Business Rules with Server Modules

The PRD defined two validation rules. Both are before rules that run on insert and update, calling setAbortAction(true) if validation fails. The logic lives in src/server/ as ES module functions, imported directly into the .now.ts definition — giving full TypeScript/Glide API type checking in the IDE.

// src/server/business-rules/validate-hardware-asset.js
import { gs } from '@servicenow/glide'

export function validateHardwareAsset(current, previous) {
    var purchaseDate = current.getValue('purchase_date')
    var warrantyDate = current.getValue('warranty_expiration_date')

    if (purchaseDate && warrantyDate) {
        var purchase = new GlideDate()
        purchase.setValue(purchaseDate)
        var warranty = new GlideDate()
        warranty.setValue(warrantyDate)

        if (warranty.before(purchase)) {
            gs.addErrorMessage(
                'Warranty expiration date cannot be earlier than the purchase date.'
            )
            current.setAbortAction(true)
        }
    }
}

Step 5 — Event-Driven Notifications

The 30-day license and 60-day warranty alert requirements were implemented as an event-driven pipeline: a daily scheduled script fires a custom event per expiring record, and an EmailNotification rule responds to that event. The event name must fit within 40 characters including the scope prefix.

// Register custom events (sysevent_register)
// "x_snc_itasset.lic_renewal" = 26 chars ✓
Record({
    $id: Now.ID['license_renewal_event'],
    table: 'sysevent_register',
    data: {
        event_name: 'x_snc_itasset.lic_renewal',
        suffix: 'lic_renewal',
        table: 'x_snc_itasset_software_license',
        fired_by: 'Scheduled Script: Check License Renewals',
    },
})

// Email notification responds to the event
EmailNotification({
    $id: Now.ID['license_renewal_notification'],
    name: 'Software License Renewal Approaching',
    table: 'x_snc_itasset_software_license',
    triggerConditions: {
        generationType: 'event',
        eventName: 'x_snc_itasset.lic_renewal',
    },
    recipientDetails: { eventParm1WithRecipient: true },
    emailContent: {
        subject: 'Action Required: License "\${software_name}" Expires in 30 Days',
        messageHtml: `<p>Expiration Date: \${expiration_date}</p>`,
    },
})

The scheduled script fires the event daily at 06:00 UTC, passing the record creator's username as parm1 so eventParm1WithRecipient resolves to the right Asset Manager:

// src/server/scheduled/check-license-renewals.js (IIFE — modules not supported here)
(function checkLicenseRenewals() {
    var targetDate = new GlideDate()
    targetDate.addDaysUTC(30)

    var gr = new GlideRecord('x_snc_itasset_software_license')
    gr.addQuery('expiration_date', targetDate.getValue())
    gr.addQuery('renewal_status', 'active')
    gr.query()

    while (gr.next()) {
        gs.eventQueue(
            'x_snc_itasset.lic_renewal',
            gr,
            gr.getValue('sys_created_by'), // parm1 → recipient
            gr.getValue('software_name')
        )
    }
})()

Step 6 — Deploy

The SDK uses an environment variable SN_SDK_NODE_ENV=SN_SDK_CI_INSTALL to activate non-interactive CI mode, where credentials are read from environment variables instead of a stored keychain entry. We store credentials in a .env file (gitignored) and source it in a deploy script:

# .env (gitignored — never commit credentials)
SN_SDK_NODE_ENV=SN_SDK_CI_INSTALL
SN_SDK_INSTANCE_URL=https://dev351321.service-now.com
SN_SDK_USER=admin
SN_SDK_USER_PWD=your_password_here

#!/usr/bin/env bash
# deploy.sh
export $(grep -v '^#' .env | xargs)
npx @servicenow/sdk build
npx @servicenow/sdk install

$ bash deploy.sh

[now-sdk] Build completed successfully
[now-sdk] Running in CI mode, using instance https://dev351321.service-now.com
[now-sdk] Starting installation...
[now-sdk] Attempting to log into instance https://dev351321.service-now.com as admin.
[now-sdk] Installation completed.
[now-sdk] Access the application at:
          https://dev351321.service-now.com/sys_app.do?sys_id=6b30759afde9413999535f0b0a56572c

What Makes the Agentic Approach Different

The traditional workflow for building an app of this scope in Studio would involve navigating to seven or eight different sections of the platform: Tables, Dictionary, Roles, ACLs, Business Rules, Email Notifications, Scheduled Jobs, Event Registry. Each record is created separately by filling out form fields. It is reliable and well-understood, but it is also inherently sequential and non-reproducible — there is no file you can check into git that recreates the app from scratch on a new instance.

The agentic workflow collapses this into a conversation. Claude Code:

1. Read the PRD and identified every entity, relationship, and business rule
2. Fetched the correct SDK documentation for each artifact type before writing code
3. Applied platform-specific knowledge (40-char event limit, IIFE for scheduled scripts, module pattern for business rules) without being told
4. Organized the project into a clean, maintainable folder structure
5. Caught and applied the correct CI environment variable after investigating the SDK source to understand why env vars were being ignored
6. Wrote the change_tracker.md and backup as per project conventions

Agentic vs. Traditional: A Developer's Perspective

When to Use Each Approach

The SDK and Studio are genuinely complementary. Neither replaces the other for all scenarios:

• Use Studio for Flow Designer canvas work, form layout design, visual debugging of execution flows, and real-time collaboration with non-developer stakeholders.
• Use Now SDK + Claude Code for tables, ACLs, business rules, scripts, notifications, and any work where repeatability, version control, and code review matter.
• Combine both by using ServiceNow's Build Agent in-platform to scaffold the initial data model and navigation menus, then now-sdk init --from <sys_id> to pull it locally for iterative development with Claude Code.

Getting Started

Key Takeaways

• ServiceNow scoped apps are metadata records. The Now SDK compiles Fluent TypeScript into those exact records — Studio and the SDK produce the same platform output.
• Claude Code's value for ServiceNow development comes from the SDK plugin's skills — runtime-injected platform knowledge that keeps the agent accurate across SDK versions.
• The agentic workflow converts a PRD into a deployable, git-versioned codebase in a single session. The same deploy command reproduces the app on any instance.
• Server-side JS modules in src/server/ support ES imports and typed Glide APIs. Scheduled script bodies must use IIFEs or Now.include() — a platform-specific nuance the agent knows from the docs.
• The SN_SDK_NODE_ENV=SN_SDK_CI_INSTALL flag is required for non-interactive deployments; without it the SDK ignores env var credentials even when they are correctly set.
• Studio remains the right tool for Flow Designer, form layouts, and visual work. The SDK is the right tool for everything where code review, repeatability, and AI assistance matter most.

Resources

1. "Building ServiceNow Apps via Claude Code and the ServiceNow SDK" — Earl Duque, Developer Advocate, ServiceNow. (Original reference that inspired this experiment.)
2. ServiceNow SDK Documentation — npx @servicenow/sdk explain --list --format=raw (versioned with SDK, always current)
3. Claude Code Documentation — claude.ai/code
4. ServiceNow Fluent Overview — npx @servicenow/sdk explain fluent-overview --format=raw
5. Now SDK GitHub — @servicenow/sdk on npm
6. ServiceNow Developer Portal — Personal Developer Instances (PDI) for free development environments