Connecting Claude to ServiceNow: A Hands-On MCP Build Log

My last post walked through what ServiceNow Otto and EmployeeWorks actually are, conceptually. This one is different — no keynote summaries, no vendor framing. I connected a real AI client to a real ServiceNow PDI over MCP (Model Context Protocol) and just tried things. Some of it worked cleanly. One assumption I'd made going in turned out to be wrong. That gap between "what the docs imply" and "what actually happens" is the whole point of this post.

If you're a developer sitting where I was — comfortable with ServiceNow, new to MCP — this is the walkthrough I wish I'd had.

A framing note before you read on: what follows is not a test of Otto or EmployeeWorks. Those are ServiceNow's own products, tied to specific releases and licensing, and not something you can spin up on a free PDI. What I actually connected was a third-party, community-built MCP server (nowaikit) talking to my instance over ServiceNow's REST APIs — no Action Fabric, no AI Control Tower, none of ServiceNow's own governance in the loop. Why bother, then? Because the shape of the interaction — an external AI agent asking questions and taking actions against ServiceNow data — is the same shape Action Fabric is built to govern. This post is a look at what that pattern does without any governance wrapper around it, as a baseline for comparing against the real, native version later.

1. The Setup: Isolated, Not on My Local Machine

I didn't want to install anything globally on my work laptop for a first test, so I ran the whole thing inside a GitHub Codespace — a disposable, browser-based Linux container. Nothing here ever touched my local environment.

The stack, in order

• A free Personal Developer Instance (PDI) from developer.servicenow.com — pre-loaded with demo incidents, CMDB CIs, and users.
• A GitHub Codespace as the sandbox (note: Codespaces won't launch against a completely empty repo — commit at least a README first, or tick "Add a README" at repo creation).
• Claude Code, installed inside the Codespace as the AI client (npm install -g @anthropic-ai/claude-code).
• nowaikit, a community MCP server for ServiceNow (npm install -g nowaikit, then npx nowaikit setup), which auto-detected Claude Code and wrote the connection config for me.

The only real hiccup: the setup wizard hung for a bit right after I entered the instance name, with no prompt for credentials yet. Turned out my PDI hadn't been accessed in a while and needed a moment to wake from hibernation — worth checking if you hit the same pause.

2. First Contact: What's Actually Exposed

Once connected, I asked Claude Code directly what tools it had available for ServiceNow. I expected a handful of simple read operations — get incident, list incidents, that kind of thing. What came back was different: 27 capabilities, grouped into five categories — Scan & Monitor, Review & Audit, Build & Generate, Operations, and Documentation. Slash-commands like /scan-cmdb, /review-acls, and /build-flow — this tool is leaning toward developer and governance tooling, not just a conversational query layer.

And separately — the tool also handled plain natural-language questions outside that named list. Asking "list my 5 most recent incidents" returned real data cleanly, with no slash-command needed. Two distinct capability layers stacked in the same tool, which isn't obvious until you actually poke at it.

3. Where the Slash-Commands Broke — Honestly

I tried /scan-cmdb next, expecting an AI-generated CMDB health report. It failed with two distinct errors:

• "No instance specified and no default instance configured. Run nowaikit setup first." — odd, since setup had already run successfully for the natural-language path.
• "Ollama not available."

That second one is the more architecturally interesting finding: the slash-commands aren't just querying data, they're running their own local AI reasoning step to generate the report — and they expect a local Ollama model for that, entirely separate from the Claude Code session already running. So even inside an active AI chat, this tool doesn't reuse that model for its own scan logic; it wants its own.

What impressed me here wasn't the scan succeeding — it didn't. It's that Claude Code, when the built-in scan failed, fell back to pulling the raw CMDB data directly from the instance and gave me an honest partial answer (CI records present, relationship records present, a few sample CI names) instead of pretending the scan had completed. Worth noting as a good behavior, not a given one.

4. The Write Test — Where My Assumption Was Wrong

Going into this, I expected community MCP tools to default to read-only, requiring an explicit opt-in flag before any write reached the instance. That's a reasonable design default, and it's what several tools in this space advertise. So I asked, in plain language: "Create a test incident."

It just did it. No confirmation prompt. No "are you sure." No opt-in flag to enable first. The response came back as:

Created a test incident in ServiceNow — number INC0010001, short description "Test incident created by Copilot".

Two things stood out immediately. First, the write executed instantly, no gate at all — a meaningfully different safety posture than I'd assumed going in, and worth correcting plainly rather than glossing over. Second, and almost funnier: the short description read "Test incident created by Copilot" — not Claude, not nowaikit. Almost certainly a hardcoded default string left over in the tool's template from wherever it was originally built or copied from, rather than content actually generated from my request. A small detail, but a telling one: the write executed a canned template rather than reasoning about what to write.

5. Why This Matters More Than It Looks Like It Does

It's easy to read the above as "a demo tool did a demo thing on a demo instance, who cares." But it's worth being precise about what this does and doesn't demonstrate. It's not a flaw in Otto, EmployeeWorks, or Action Fabric — none of those were involved here. What it does demonstrate is exactly the baseline risk ServiceNow's own AI Control Tower materials describe as the reason that governance layer exists: an ungoverned agent operating with more autonomy than intended, no confirmation step, and — this is the part worth sitting with — no clearly attributable audit trail. If the "opened by" field on that incident shows a generic admin user rather than something identifying the AI agent that created it, that's the exact gap a governed setup is designed to close.

That's the actual test I want to run next: the same kind of request, but through ServiceNow's native MCP Server Console with real AI Control Tower governance attached — the genuine Action Fabric experience, not a community stand-in for it. My prediction, to be tested rather than assumed: a governed write should require an explicit permission grant, log the agent identity distinctly from the human operator, and show up in an auditable trail — none of which this community setup gave me by default.

6. If You Want to Try This Yourself

None of this requires a production instance, a ServiceNow AI license, or much time — a free PDI and an afternoon is genuinely enough. A few things worth doing differently than I did, based on what surprised me:

Lessons for your own testing

• Use a disposable environment (Codespace, Gitpod, or similar) for a first test rather than a global local install, especially on a managed work laptop.
• Don't assume "read-only by default" for any community MCP tool — verify it yourself, on a PDI, before trusting it near anything that matters.
• Be deliberate with instruction-style phrasing ("create," "update," "delete") until you've mapped out what actually executes without confirmation.
• Treat slash-command failures as information, not dead ends — the fallback behavior often tells you more about the tool's real architecture than a clean success would.

Final Thoughts

The gap between reading about MCP and actually connecting an AI agent to a live ServiceNow instance is smaller than I expected — a free PDI and an afternoon gets you a working setup, no ServiceNow product required. But the gap between "it works" and "it's safe to point at production" is exactly as real as the governance conversation around Otto and Action Fabric suggested it would be — this was the ungoverned baseline, not the real thing.

The wrong assumption I walked in with — that a community tool would default to read-only — is exactly the kind of thing you only find by actually running the test, not by reading a README. That's really the point of this whole series: understanding what Otto and Action Fabric are is one skill; knowing what happens when the guardrails aren't there is a different one, and it's the one that actually protects a production instance. The next post picks up from here: the same test, run through ServiceNow's actual governed Action Fabric setup, to see how much of what I found today gets caught.

ServiceNow Otto & EmployeeWorks: Understanding the Shift to Agentic AI

At Knowledge 2026, ServiceNow introduced Otto — a unified AI experience layer that sits above Now Assist, Virtual Agent, and the rest of the platform, deciding which system or agent should handle a request and executing it end to end. It's already live inside ServiceNow EmployeeWorks and AI Control Tower, with a full rollout across the platform planned over the coming year.

If your first reaction was "don't we already have an assistant for this?" — you're asking the right question. This guide walks through what Otto and EmployeeWorks actually add on top of Now Assist and Virtual Agent, how they're built, what they cost, and — just as importantly — the practitioner-level questions worth asking before you bring this into your own instance: roles, clone behavior, integration impact, and what happens when it gets something wrong.

1. What Problem Is Otto Actually Solving?

Most enterprises already have AI everywhere — a copilot in the ticketing tool, a chatbot on the intranet, a summarizer inside the CRM. Each one works reasonably well in isolation, but none of them talk to each other, and none can see past the system it lives in. Employees still switch tabs, chase approvals, and repeat themselves to every tool that doesn't remember the last conversation.

What Otto changes

• Employees describe what they need in plain language — no portal-hunting, no knowing whether it's an ITSM incident, an HR case, or a GRC exception.
• Otto understands intent, decides which agent or workflow should handle it, and routes across departments without the employee orchestrating anything themselves.
• Every action — human-initiated or agent-initiated — is logged, policy-enforced, and explainable through AI Control Tower.

Otto is not sold as a separate SKU, and it's not a rip-and-replace of anything you've already built. It's an experience layer that runs on top of the ServiceNow AI Platform, unifying Now Assist, EmployeeWorks, and AI Experience into one governed interface.

2. The Layered Architecture: Otto, EmployeeWorks, Now Assist, and Virtual Agent

The naming gets confusing fast, so it's worth anchoring on the layers rather than the product names. Four layers, bottom to top: Now Platform (execution — workflows, data, the engine everything runs on), Now Assist / Virtual Agent (capability — smarter within one module, but still bound to it), EmployeeWorks / AI Agents / Action Fabric (the layer that actually acts — built-in agents like Build Agent, or external agents like Claude and Copilot connecting in through Action Fabric), and Otto at the top (experience — decides where a request goes and orchestrates it). AI Control Tower wraps around all four layers as governance, not as a tier of its own.

The part worth remembering: nothing in the lower two layers goes away. Now Assist and Virtual Agent keep doing exactly what they already do. Otto doesn't replace them — it decides when to hand a request down to them versus routing it somewhere else entirely. If you've invested in Virtual Agent topics or Now Assist skills, that work carries forward; it just stops being the only front door.

3. What Actually Makes This "Agentic"

"Agentic AI" gets used loosely, so it's worth being precise. Generative AI answers or drafts — you ask, it produces something, you still decide and click. Agentic AI plans a sequence of steps toward a goal and executes them, often across system boundaries, without a human performing each individual step.

Where Otto fits that definition

• Intent understanding — parsing what's actually being asked, not matching a keyword to a topic flow.
• Autonomous routing — deciding which agent or department handles the request without a human pre-wiring the path.
• Cross-system execution — acting across systems through a shared, governed runtime rather than staying inside one module.

One distinction worth getting right when explaining this to others: Otto itself isn't "an agent" in the singular sense — it's an agent orchestrator. Individual AI Agents (Build Agent, ATF Troubleshooting Agent, and anything built with Now Assist for Creator) do the bounded task work. Otto sits above them and decides which one gets invoked for a given request. Conflating the two is the single most common mix-up in this space.

4. How Otto Accesses Data: Roles, ACLs, and Agent Identity

This is the question every security-minded architect asks first, and the honest answer is: it's not magic, it's still your existing ACL and role model, just invoked by an AI instead of a human clicking through the UI.

What holds true

• Otto and its agents act as the requesting user, not as a superuser — if an employee's role doesn't grant visibility into a record, an agent acting on their behalf shouldn't surface it either.
• Cross-system reach runs through Action Fabric and the MCP Server, which consume the same Assist licensing model as Now Assist and AI Agents — agent-driven actions are governed and metered the same way human-driven ones are, not through a side door.
• Agents themselves are increasingly getting their own scoped, least-privilege identity — tracked separately from the human they're acting for — rather than inheriting a blanket service account.

Practical implication for admins: your existing ACL hygiene work isn't obsolete — it's the foundation this depends on. Role-less ACLs, over-broad data conditions, or table-level access gaps don't get safer just because an AI is making the request instead of a person; if anything, they get exercised more often, since Otto is designed to be asked things constantly.

5. When Otto Can't Resolve It: Ticket Creation and Escalation

Resolution isn't the only outcome Otto is designed for — escalation is a first-class fallback, not an afterthought.

The pattern

• Attempt resolution first, against knowledge articles, catalog items, and workflow actions.
• If it can't close the loop, generate the incident or case itself — pre-filled with the conversation context, not a blank form the employee has to re-explain everything into.
• Route to the correct assignment group automatically, and let the employee track status through the same conversational interface rather than a separate portal.

The context pre-fill is the real time-saver on the fulfiller side — L1/L2 teams inherit a ticket that already has the conversation history attached, instead of starting cold.

6. AI Control Tower: Governance as a First-Class Layer

Every Otto interaction — and increasingly, every AI action on the platform regardless of source — passes through AI Control Tower.

What it actually does

• Discover — inventories AI models, agents, datasets, and prompts across 30+ enterprise integrations, including non-ServiceNow environments like AWS, Azure, GCP, SAP, and Workday.
• Observe — runtime visibility into how an agent reasoned and where it made a decision, not just what it returned.
• Govern — risk assessment aligned to frameworks like NIST and the EU AI Act, with compliance controls out of the box.
• Secure — least-privilege identity enforcement extended to every AI system, agent, and human identity.
• Measure — cost and ROI dashboards, since AI token consumption is now a metered line item, not a flat fee.

The most operationally important piece here is real-time containment: AI Control Tower is designed to detect when an agent operates outside its intended permission boundary and shut it down automatically, generating a security incident and audit trail in the same motion — an enforcement point, not just a monitoring dashboard.

7. What Can Break: Failure Modes Worth Knowing

Yes, this can misdirect or misguide a user — and it's more useful to your team to name the specific failure modes than to wave generally at "AI can be wrong."

The failure modes, and the mitigation for each

• Misrouting — an ambiguous request gets sent to the wrong department or system. Low-stakes: an extra hop. Higher-stakes: an HR-sensitive case routed through a channel without the right confidentiality controls. Mitigate with clear category boundaries and periodic routing audits, the same discipline you'd apply to Virtual Agent topic design.
• Hallucination — a confident answer that isn't grounded in your actual data. AI Control Tower is explicitly built to surface where this is happening, not to pretend it doesn't.
• Over-scoped or drifting agent behavior — an agent acting outside its intended permission boundary. This is exactly what real-time containment exists for.
• Model or data drift — a model that routed correctly at rollout can quietly degrade as your CMDB, org structure, or workflows change underneath it. AI Control Tower generates drift alerts, but someone still has to act on them.
• Autonomy level mismatch — whether a given workflow should run fully autonomous or human-in-the-loop is a real configuration decision, not something the platform forces on you either way. Get this wrong and you either lose the efficiency gain or take on more risk than the use case warrants.

8. Platform Requirements: Release, Licensing Tier, and Plugins

There isn't a classic "install this plugin" checklist here, which trips people up if they're expecting one.

What you need in place

• Otto is an experience layer, not a separately licensed product — it runs on top of Now Assist, AI Control Tower, and EmployeeWorks (which itself bundles the Moveworks-derived conversational front door). Confirm those are provisioned rather than looking for an "Otto plugin."
• Release-wise, this is surfacing with the Australia release; if you're still on an earlier family, this is one more reason to prioritize the upgrade path.
• Licensing runs through ServiceNow's current three-tier model — Foundation, Advanced, and Prime — with Otto's underlying components bundled at every tier, and fully autonomous agent capability reserved for Prime. What changes across tiers isn't whether the AI is present, it's how autonomously it's allowed to operate.

9. Clone Behavior and Integration Impact — What to Validate, Not Assume

This is genuinely new enough that ServiceNow hasn't published Otto-specific clone documentation yet — which makes it worth treating as an open validation item rather than assuming it behaves like anything you've cloned before.

What to check before you assume anything survives a clone

• AI Control Tower's registered integrations and model bindings — treat these like the API keys and OAuth tokens you already know don't survive a clone cleanly, until proven otherwise on your own instance.
• Agent skill and topic definitions — verify whether these clone as configuration or need re-registration per environment.
• Existing IntegrationHub spokes touching Employee Center, Virtual Agent, or HRSD — these have historically followed independent release cycles from the core family upgrade and needed separate post-clone validation; there's no reason to expect EmployeeWorks-related spokes to behave differently.
• Any point-to-point integration with external agent platforms (Copilot Studio, custom agents) that predates your Action Fabric adoption — these are candidates to re-map through Action Fabric's governed runtime rather than left running outside it.

The honest position to take with stakeholders: don't assert clone behavior you haven't verified on your own sub-production instances. Build a specific clone-validation pass for AI Control Tower and EmployeeWorks configuration into your next lower-environment refresh, and treat the results as your actual documentation — not a vendor datasheet.

10. Skills Your ITSM and Dev Teams Will Actually Need

The good news: this isn't a brand-new skill stack from zero. It's your existing ServiceNow skill set, plus three additions.

What to build now

• Conversational and agent design — extends directly from Virtual Agent NLU/topic work most teams already have.
• AI Agent orchestration — comfort building with Now Assist for Creator and Build Agent, since dev teams building custom scoped apps will increasingly work through this agent rather than only by hand.
• AI governance literacy — reading AI Control Tower dashboards, drift alerts, and explainability logs. This is the genuinely new muscle, closer to observability/SRE work than classic ServiceNow administration.

On timing: don't wait for "Otto" specifically to land on your instance before upskilling. Now Assist and AI Agent fluency transfers directly, and the platform readiness work — clean CMDB/CSDM data, documented workflows, defined AI governance ownership — is the actual prerequisite regardless of how far the Otto rollout has reached. That foundation work realistically takes many months, which lines up well with a CoP-driven, phased upskilling plan rather than a scramble.

11. Cost for Existing Customers: What's Bundled, What's Metered

This is more favorable than most new platform capabilities, with one important variable cost to model carefully.

The shape of it

• Every current tier — Foundation, Advanced, Prime — includes Otto's underlying components automatically; what changes across tiers is autonomy level, not presence.
• Capabilities that were previously separate purchases — a subset of EmployeeWorks, Workflow Data Fabric, AI Control Tower, and a Context Engine — are now folded into the tiers.
• The Moveworks-derived conversational layer ships as a bundled SKU rather than a separate procurement.
• The variable to actually watch: AI token consumption. Each tier includes an Assist pool, and usage beyond it is metered — model this as a variable line item, not a flat fee, when you budget.

Confirm the specifics with your account team rather than treating any public figure as authoritative — ServiceNow's pricing remains custom-quoted, and third-party estimates vary.

12. Now Mobile, and How Otto Compares to Market Alternatives

Otto is designed to reach employees through conversational chat, enterprise search, voice, and mobile — it's explicitly not a desktop-only experience, and ServiceNow's own mobile documentation now leads with Otto messaging directly.

Where it sits against the market

• Microsoft Copilot — positioned as interoperable rather than purely competing; Copilot is a named design partner for Action Fabric, meaning employees already living in Copilot can trigger governed ServiceNow actions without switching tools.
• Point-solution AI helpdesk tools (Workativ, eesel AI, and similar) — compete on cost and simplicity for teams that don't want a platform rip-and-replace, but don't offer the same cross-departmental orchestration depth.
• BMC Helix, Freshservice, Jira Service Management — traditional ITSM competitors layering on their own AI, generally narrower in scope than Otto's cross-system ambition today.

Final Thoughts

Otto and EmployeeWorks aren't a rebrand of Now Assist, and they're not a reason to throw out anything you've already built on Virtual Agent. What's actually new is the orchestration layer above them — the piece that decides which system should handle a request, executes across boundaries, and governs the whole thing through AI Control Tower rather than leaving governance as an afterthought bolted onto each integration separately.

For practitioners, the questions worth carrying forward aren't "will this replace my job" — they're the ones this guide walked through: what roles does an agent actually need, what happens during clone, which integrations need re-mapping, and where does autonomous execution need a human in the loop. Those don't have one-size-fits-all answers. They're the kind of judgment calls that separate a team that's read the keynote from one that's actually ready to run this in production — and getting ahead of them now is exactly the kind of thought leadership worth bringing to a CoP or POD conversation before someone else frames the narrative for you.

RaptorDB in ServiceNow: What It Is, What "No Impact" Really Means, and How to Test Before You Trust It

Every few years, ServiceNow makes a change that sits underneath everything else you build — invisible on the surface, but consequential enough that "we'll find out when it breaks" isn't a real strategy. RaptorDB is one of those changes. It's not a plugin. It's not a module. It's the database engine your entire instance runs on, and ServiceNow is migrating customers onto it whether or not those customers have thought hard about what's underneath their dashboards, their CMDB, and their integrations.

This guide walks through what RaptorDB actually is, what ServiceNow's own "no impact" assurance means in practice, where real customers have reported friction, and how to build a test and communication plan that catches problems in a lower environment instead of in production — including the harder, less-documented question of what this means for the modules that don't get much airtime in ServiceNow's marketing: GRC, IRM, BCM, WSD, and the vulnerability/security integrations that quietly carry more risk than people assume.

1. What RaptorDB Actually Is

RaptorDB is ServiceNow's next-generation database engine, built to eventually replace the MariaDB/MySQL foundation that's powered the platform for years. It's designed as an HTAP database — hybrid transactional and analytical processing — meaning a single engine handles both the fast, everyday transactional work (creating an incident, updating a case) and the heavy analytical work (running a report across millions of rows) without one starving the other.

Its lineage traces back to ServiceNow's acquisition of Swarm64, a company that specialized in accelerating Postgres for complex analytical workloads. ServiceNow spent several years building that acquisition into a purpose-built engine for its own platform, rather than bolting on a generic third-party database.

There are two tiers, and the distinction matters more than most teams realize:

• RaptorDB Standard — the baseline engine replacement, rolled out progressively to instances largely on ServiceNow's own schedule.
• RaptorDB Pro — a premium, separately licensed tier that adds column-store indexing, deeper parallel processing, and integration with ServiceNow's Workflow Data Fabric (including Live Connect to external BI tools and Live Archive for offloading historical data while keeping it queryable).

Before you build a business case, a test plan, or a stakeholder message around "the performance gains RaptorDB delivers," confirm which tier your contract actually includes. The headline performance numbers — dramatically faster reports, list views, and transaction throughput — are associated with Pro-tier capabilities. If your organization is on Standard, don't let a leadership deck quietly inherit Pro-tier expectations.

2. The "No Impact" Assurance — What It Means and What It Doesn't

ServiceNow's official position is straightforward: nothing should need to change at the application layer. Applications, integrations, customizations, tables, and queries are expected to behave identically before and after migration — the database is meant to be transparent to the customer and to end users.

That's a reasonable design goal, and for a meaningful share of customers, it appears to hold. But "designed to be transparent" and "guaranteed to be transparent for every instance's specific customization footprint" are not the same claim, and the second one is the one that actually matters to a platform team. Community reports since rollout began include a real, if not universal, set of friction points:

• Broken custom dictionary elements on fields whose names contained multiple special characters.
• Issues with Database Views behaving differently, or breaking, post-migration.
• System Clone table exclusions not being respected — child-table data copied over even when the parent table was explicitly excluded.
• Report and list-view runtime patterns shifting unpredictably, which broke downstream SLA or overnight jobs that had quietly depended on the old timing.

None of this means RaptorDB is broken or that ServiceNow's assurance is disingenuous. It means the assurance describes the intended behavior of a generic instance, not the guaranteed behavior of your instance, with your specific years of accumulated customization. The right response to "ServiceNow says there's no impact" isn't skepticism for its own sake — it's the same instinct you'd apply to any platform-level change: verify against your own footprint before you trust it against production.

3. The Highest-Risk Mechanism: IRE and CMDB

If your instance leans on the Identification and Reconciliation Engine — and almost every instance running Discovery, Service Mapping, Service Graph Connectors, or CI-linked security integrations does — this is the area to test first and most rigorously, not because it's guaranteed to break, but because it's where the underlying data model is most complex and where a schema-level change has the most surface area to interact badly with.

This isn't theoretical. A retry loop tied to an IRE schema mismatch following simultaneous plugin upgrades can generate millions of log entries an hour and quietly degrade instance performance long before anyone connects the symptom to its root cause — the kind of incident that's easy to misdiagnose as "the integration is broken" when the real issue is one layer deeper, in how identification and reconciliation rules interact with the underlying schema.

What to actually check:

• CI match rates for every integration writing through IRE, before and after — auto-matched percentage, not just "did the job complete."
• sys_object_source record counts per data source, watched for unexpected growth or duplication.
• Unclassed CI creation rates — a rise here usually means identification rules aren't resolving the way they did pre-migration.
• Live error-log monitoring during the first post-migration run of each IRE-dependent integration, filtered specifically for the identification engine source.

4. Database Views, Custom Dictionary Fields, and Clone Exclusions

These three don't get much attention because they're not architecturally dramatic, but they're exactly the kind of quiet, specific breakage that turns into a support ticket nobody can immediately explain.

• Database Views — inventory every DB View across your instance before migration, and validate them by checking actual returned values afterward, not just confirming they still run without error. A view that executes cleanly but returns subtly wrong data is a worse outcome than one that fails loudly.
• Custom dictionary fields with special characters in the name — a small population on most instances, but worth a deliberate audit rather than discovering them one broken report at a time.
• System Clone table exclusions — if your CMDB or other tables have configured exclusions, verify explicitly that a post-migration clone actually respects them. Don't assume exclusion behavior is unchanged just because the exclusion configuration itself looks unchanged.

5. Don't Let a Faster Database Hide a Slow Business Rule

This is the most important framing in this entire article, so it earns its own section: RaptorDB changes how fast the database answers a query. It does nothing for how much work your synchronous Business Rules do on every insert or update.

A real pattern worth watching for: report and dashboard load times improve noticeably post-migration, while a specific transaction — say, incident creation — gets slower, because a custom Business Rule was already the actual bottleneck and the faster database just made that bottleneck more visible by comparison. Teams that only test reports and dashboards miss this entirely. Teams that test "golden transactions" — create incident, approve change, close case, fulfill a request — catch it immediately.

The same logic applies to bulk operations. An import set updating a couple million rows, running through synchronous Business Rule logic, can turn what should be a 30-minute job into a multi-hour one — a problem that has nothing to do with the database engine underneath it, and everything to do with logic that was already marginal and is now the visible ceiling.

6. It's Not Just ITSM and CMDB — Map Every Module's Exposure

Most RaptorDB commentary online is written with ITSM and CMDB in mind, because that's where the volume and the marketing numbers live. If your instance also carries GRC, IRM, SPM, HRSD, BCM, WSD, SecOps, and Request Management — which describes most mature multi-module implementations — each of those modules inherits the same underlying risk mechanisms, just in different proportions.

A rough exposure map, based on how these modules actually touch the mechanisms above:

• CMDB and SecOps (Vulnerability Response, SIR) — highest exposure, driven by IRE dependency and CI-matching integrations (Rapid7, CrowdStrike, USEM, Discovery, Service Graph Connectors).
• ITSM — high exposure on reporting and dashboards, plus approval and assignment Business Rules that run at real volume.
• GRC and IRM — moderate CI/asset linkage exposure, high exposure on risk and compliance dashboards specifically.
• SPM — lower CMDB exposure, but meaningful exposure through portfolio dashboards and collaborative workspace concurrency.
• HRSD — lower CI exposure, but real exposure through bulk case operations and custom case fields.
• BCM — moderate exposure through business-impact-to-service/CI linkage, plus a distinct consideration covered in Section 8 below.
• Request Management — high exposure through bulk fulfillment and approval logic at transaction volume.

The point of a map like this isn't precision — it's prioritization. You will not get equal test coverage across ten modules in a realistic timeline. Weight your effort toward IRE-dependent and high-volume modules first, and treat the rest as scoped spot checks rather than skipping them silently.

7. This Is Not a Reversible Experiment

One detail changes the entire risk conversation, and it belongs in front of leadership, not buried in a technical appendix: ServiceNow's approach to a post-cutover failure is fix-forward. If your instance needs to be returned to MariaDB after a problem is found, that requires emergency maintenance, additional downtime, and carries the possibility of data loss depending on the issue.

That reframes this migration from "a performance upgrade we can always undo if it doesn't work out" to "a committed platform change that deserves the same rigor as any other one-way infrastructure decision." Whoever holds go/no-go authority for your production migration should hear this explicitly, in those terms, before they approve it — not discover it after something has already gone wrong.

8. Change Management: Treat It as Its Own Event

A recurring mistake worth naming directly: teams plan their RaptorDB readiness around a family release upgrade, assuming the two land together, only to learn the database cutover is scheduled separately by ServiceNow. The release upgrade completes, everyone breathes out, and then the actual database migration lands weeks or months later — at which point all the performance testing already done is effectively meaningless, because it validated the wrong variable.

Give this its own CAB entry, its own freeze window, and its own UAT cycle. Don't let it inherit a change record built for something else.

One more scheduling nuance worth confirming early: control over the cutover date itself varies by licensing tier, and how your non-production environments get migrated — independently, or only by cloning from an already-migrated production instance — materially changes how you should sequence your own testing.

9. Building a Defensible Pre/Post Test Plan

A vague impression that "everything looked fine" isn't a finding — it's an assumption wearing a lab coat. A defensible test plan captures real numbers, before and after, on the same instance, at the same data volume.

Minimum baseline to capture before migration, for every module in scope:

• Row counts for core tables, so post-migration comparisons are normalized rather than misleading.
• Timed runs of key list views, dashboards, and reports at real data volume — not a thin dev-instance approximation.
• Timed runs of scheduled bulk jobs — imports, bulk approvals, batch closures — measured in rows processed per second, not just wall-clock duration.
• CI match rates for anything writing through IRE.
• A seven-day error log baseline, filtered to the module's own scripts, Business Rules, and transform maps, so a new error pattern is recognizable as new.

After migration, re-run every measurement the same way, and close the loop with one end-to-end "golden transaction" per module — the sequence a real user would actually run, not just the components in isolation.

10. Communicating This Without Causing the Incident You're Trying to Prevent

A surprising share of "major incidents" tied to platform changes aren't really technical failures — they're communication failures wearing a technical costume. The database migration goes fine, but a business process owner wasn't told what to watch for, so the first symptom they see gets reported as an emergency instead of routed to the people already expecting it.

A few habits that materially reduce this risk:

• Give every module owner a short, specific, non-technical heads-up before cutover — what might change, what almost certainly won't, and exactly who to contact if something looks off.
• Open a proactive support case with ServiceNow ahead of the migration window if your instance has any history of IRE-related or schema-related incidents, so support already has that context if something similar resurfaces.
• Run a defined hypercare window after cutover — a few business days of heightened monitoring — with a runbook of known symptom patterns and who owns each one, so the service desk doesn't misroute a generic "system feels slow" ticket away from the team that already knows the migration context.
• Close the loop explicitly. An "all clear, hypercare has ended" message matters as much as the initial warning — silence reads as either "nothing happened" or "no one's watching anymore," and only one of those is true.

Final Thoughts

RaptorDB is a legitimate architectural improvement, and for most instances, ServiceNow's transparency claim will likely hold up in practice. But "likely" isn't the standard for a change you can't cleanly reverse. The teams that come through this migration without a major incident aren't the ones who trusted the assurance the most — they're the ones who tested their own specific footprint against it, weighted their effort toward the modules and mechanisms that actually carry risk, and made sure every stakeholder who needed to know something, knew it before cutover rather than after.

That's not really a database question. It's the same discipline that separates a platform team that reacts to incidents from one that quietly prevents them — and a new database engine, however well-engineered, is just the latest place that discipline gets tested.

The Complete ServiceNow Career & Learning Guide (2026)

ServiceNow has quietly become one of the broadest platforms in the enterprise software world — part ITSM tool, part low-code application platform, part AI control tower. That breadth is exactly what makes it confusing for newcomers: the first two weeks feel easier than most competing tools, and then the learning curve turns into a wall.

This guide is written for anyone deciding whether to invest in ServiceNow as a career, and for anyone already in it trying to choose a direction — admin, developer, business analyst, architect, or a COE/practice-level specialist. It also covers the honest comparisons nobody puts in a marketing deck: what ServiceNow scripting genuinely can't do compared to a language like Java or C++, realistic (not brochure) timelines for each role, and the pitfalls that quietly damage credibility in front of a customer.

1. Can Anyone Really Become a ServiceNow Expert?

Yes — almost anyone with basic computer literacy can become competent, and anyone with genuine curiosity and consistency can become an expert. ServiceNow was deliberately built with a low floor and a high ceiling: you can build a working workflow in week one, and still be discovering platform depth after ten years.

There are no hard prerequisites. You don't need a computer science degree. But a few backgrounds accelerate you significantly:

• ITIL/ITSM familiarity — ServiceNow's data model mirrors ITIL processes almost 1:1.
• Relational database concepts — everything is a table, and "dot-walking" is just following relationships.
• Basic JavaScript — Business Rules, Client Scripts, Script Includes, and Flow Designer scripts all run on it (server-side on a Rhino/Mozilla-based Glide engine, not Node.js).
• Basic REST/SOAP knowledge — needed the moment you touch Integration Hub, Spokes, or custom integrations.
• An analytical, process-mapping mindset — this matters more than coding skill for Business Analyst and Architect tracks.

Expertise here is a function of how many different modules, releases, and real customer messes you've been exposed to — not raw intelligence, and not certificate count.

2. What Beginners Should Expect, Compared to Other ITSM Tools

Coming from Remedy, Ivanti, Cherwell, Freshservice, or Jira Service Management, a few mental resets are worth making early:

• It's a platform, not a product. ITSM, HR, CSM, SecOps, and ITOM are all just applications running on the Now Platform. You're learning a PaaS, not a ticketing tool.
• Everything is metadata-driven. Forms, logic, and security live in tables you can query and modify — powerful, but "it's just a config change" can silently break things you didn't know were connected.
• The out-of-box process is deep and opinionated. Beginners often don't realize how much already exists and waste effort rebuilding it.
• Upgrades are continuous, not optional. Two major releases a year (Xanadu, Yokohama, Zurich, and so on) mean heavy OOB customization survives far better than raw script overrides.
• There's nothing to install. Pure multi-tenant SaaS — you get an instance URL, not a server to provision.
• The curve is a hockey stick. Easier than most competitors for the first 2–3 weeks, then steep once ACLs, Business Rules, Flow Designer logic, and scoped apps enter the picture.

3. What You Can't Do Like You Would in C++, Java, or .NET

This is where strong software developers get frustrated if expectations aren't set correctly. ServiceNow scripting is a constrained, governed, declarative-first environment — not a new framework for the same language habits.

• No true classical OOP. Server-side scripting is JavaScript — prototype-based, not class-based. Script Includes simulate classes, but it's a workaround, not native language support.
• Limited debugging. Studio's Script Debugger is far less capable than Visual Studio, IntelliJ, or Eclipse — a lot of real debugging is still gs.log() statements and log queries.
• No thread or memory control. You don't manage servers, threads, or memory — you work within Scheduled Jobs, Async Business Rules, Events, and Flow Designer's orchestration model instead.
• Restricted library imports. No freely pulling in npm, Maven, or NuGet packages — scoped applications sandbox what APIs you can call.
• No OS or filesystem access. By design, for security and multi-tenancy.
• Version control is improving but not native-feeling. Update Sets (XML diffs, collision issues) were the original change unit; Git/Source Control integration via Studio has closed the gap, but it's still not as seamless as a git-native ecosystem.

The platform rewards configuration-first thinking — Flow Designer, ACLs, Business Rules — over "let me just code this from scratch." Fighting that instinct is the number one reason experienced developers struggle in their first 3–6 months.

4. Realistic Timelines by Role

These assume consistent, hands-on practice on a free Personal Developer Instance — not passive video-watching. Cut them roughly in half for 20+ hrs/week of practice, or double them for a few hours a week.

System Administrator (CSA track)

• 0–1 month: navigation, users/groups/roles, ACL basics, notifications, UI policies.
• 1–3 months: catalog items, basic Flow Designer, update sets, import sets.
• 3–6 months: ready for CSA certification and a junior admin role.
• 6–12 months: real production exposure builds true competence that courses can't teach.

Developer (CAD track)

• 2–4 months: Client Scripts, Business Rules, Script Includes, GlideRecord/GlideAjax, scoped app basics.
• 4–8 months: Flow Designer + Integration Hub actions, REST/SOAP basics, widget or UI Builder development.
• 8–14 months: confident, production-safe developer who understands ACLs and script performance deeply.
• 2–3 years: true SME-level scripting depth across multiple real projects and data volumes.

Business Analyst / Functional Consultant

• 0–3 months: strong grasp of OOB process, able to run fit-gap sessions and write scoped user stories.
• 3–9 months: comfortable owning requirements across two to three modules.
• 1–2 years: leads process workshops independently and knows when a "simple ask" is really a three-week build. This track can move faster than developer timelines if you already carry ITIL/process background.

Technical / Solution Architect (CTA/CMA track)

• Prerequisite: 3–5+ years of hands-on implementation across multiple modules and full project lifecycles.
• CTA prep: roughly 3 months of intensive, structured study on top of that experience.
• CMA prep: typically 6+ months on top of 5+ years of real consulting/architecture experience.
• True architect maturity — defending CMDB, integration, and security design decisions to a CIO — realistically takes 4–7 years, not a certification timeline.

Center of Excellence (COE) / Platform Owner

• This isn't a certification you pass — it's organizational maturity. Expect 3–6+ years before you're the one setting governance standards (naming conventions, CSDM/CMDB governance, ATF strategy, release cadence, AI governance policy) across multiple business units.

5. Pitfalls: What You Should Never Take for Granted

These are the mistakes that damage credibility with a customer far more than a lack of raw skill ever does.

• Assuming configuration can't break anything. ACL and dictionary changes silently break unrelated processes — always test in a sub-production instance first, every time.
• Sloppy update set hygiene. Moving update sets out of order, or bundled with unrelated changes, is one of the most common causes of preventable production outages.
• Reinventing what's already out-of-box. Approval logic, SLA definitions, and notification templates usually already exist — customers notice when a team charges to rebuild the wheel.
• Touching CMDB without understanding CSDM first. Bad CI classification or relationship modeling quietly poisons every downstream ITOM, Event Management, and reporting effort for years.
• Overusing heavy client-side scripting when a UI Policy would do — a habit inherited from traditional web development that hurts maintainability and performance at scale.
• Ignoring GlideRecord performance — unbounded queries or queries inside loops are invisible on demo data and a production disaster at real data volumes.
• Treating security as an afterthought. Retrofitting ACLs and data policies after a build is far more expensive than designing them in from day one.
• Assuming Service Portal, UI Builder, and classic UI are interchangeable. They're architecturally different rendering frameworks — skills don't fully transfer between them.
• Underestimating integration complexity. Authentication, payload transformation, error handling, and retry logic all need real design, not a quick REST message.
• Demoing only as an admin. A feature that works for an admin often breaks for a fulfiller or end-user role due to ACLs — test across personas before a customer sees it.
• Deploying AI features on messy data. Now Assist, AI Search, and AI agents are only as good as the CMDB/CSDM data and knowledge base hygiene underneath them — confidently wrong answers are worse than no AI at all.
• Falling behind on release notes. Missing deprecated APIs or licensing changes damages both technical and commercial credibility with a customer.
• Assuming you (or your team) know "all of ServiceNow." No one does — say "let me confirm" rather than guessing in front of a customer.

6. Choosing Your Development Style: Service Portal, Classic UI, UI Builder, or Mobile

These four attract genuinely different personality types — don't try to master all of them at once.

• Service Portal — AngularJS 1.x, widget-driven. Attracts traditional front-end HTML/CSS/JS developers. Still widely used for self-service portals and knowledge bases, but increasingly treated as a legacy investment for new greenfield builds.
• Native/Classic Platform — Forms, Lists, Business Rules, Flow Designer. Attracts people who like structured, backend/process-oriented logic — often those with a backend, ERP, or systems-administration background.
• UI Builder / Next Experience / Workspaces — component-based, low-code, closer in spirit to modern frameworks like React. This is ServiceNow's clear strategic direction — Agent Workspace, Employee Center, and most new persona-based experiences are built here, and it's increasingly the highest-demand skill for developers entering fresh.
• Mobile (Now Mobile / Mobile Studio) — a distinct discipline again, with offline considerations, push workflows, and mobile-specific security patterns. Smaller, more specialized group, often with prior native/hybrid mobile app experience.

7. Choosing an Application Specialization: ITSM, GRC, SecOps, CMDB, ITOM, and More

Once you're comfortable on the platform, most careers narrow into an application-level specialization:

• ITSM — Incident/Problem/Change/Request, SLAs, Major Incident Management. The most common entry specialization, best suited to classic IT operations minded people.
• GRC (Governance, Risk & Compliance) — policy, risk, audit workflows. High demand and premium rates, well suited to audit/compliance backgrounds.
• SecOps — Security Incident Response, Vulnerability Response, threat intel integration. Consistently one of the highest-paying specializations, ideal for people with a SOC background.
• CMDB / CSDM / Discovery — data modeling, CI classification, relationship mapping, normalization. Unglamorous but foundational — everything else in the platform depends on it being right.
• ITOM — Discovery, Service Mapping, Event Management, Cloud Insights, Orchestration. A good fit for infrastructure/ops-minded, systems-thinking people.
• HRSD, CSM, FSM, Strategic Portfolio Management, and other verticals — each has its own process depth and persona; pick based on domain interest, not just technical curiosity.

8. The Data and Integrations Tracks: The Unglamorous Backbone

Two specializations rarely get attention in beginner content but are among the most valuable and hardest-to-find skill sets in the ecosystem.

• Foundation data, normalization, and performance — people who focus purely on data quality, foundation tables, and platform tuning. Nearly every major platform failure traces back to bad foundation data, not bad UI.
• Integrations — REST/SOAP, Integration Hub + Spokes, MID Server architecture, event-driven patterns, and increasingly the Action Fabric / MCP Server pattern that lets external AI agents (including tools like Claude, Copilot, and custom agents) call governed ServiceNow actions directly. This is more architecture and protocol-thinking than form or workflow design.

9. The AI, GenAI, and Agentic AI Layer (2026)

This part of the ecosystem has moved the fastest of anything on the platform — treat any snapshot, including this one, as something to verify against current release notes.

• Now Assist — originally a conversational/summarization assistant launched in 2023, now expanded into agentic capability that plans and executes multi-step workflow actions across ITSM, CSM, HRSD, and SecOps, rather than just answering questions.
• AI Agent Studio / AI Agent Orchestrator / AI Control Tower — the toolset for building custom agents through natural-language configuration, coordinating multiple agents across cross-department workflows, and governing agent activity at scale. Think of it as the new Flow Designer, but for autonomous agents.
• Build Agent — an AI coding assistant inside ServiceNow Studio that turns natural-language prompts into production-ready applications, flows, UI Builder pages, and Now Assist AI agents, with generated test cases. It reached general availability in mid-2026 and extends into external developer tools (Cursor, Windsurf, GitHub Copilot, Claude Code), still governed through App Engine Management Center so AI-generated work passes through the same change-management, ACL, and audit gates as human-built work.
• Action Fabric / MCP Server — opens ServiceNow's platform actions to external AI agents (not just ones built on ServiceNow) through a generally available Model Context Protocol server, blurring the line between "ServiceNow developer" and "AI agent integrator."
• AI Search, Instance Observer, Accelerators — part of ServiceNow's push to embed AI-assisted discovery and platform health analysis directly into admin and developer workflows, reducing manual searching and reactive firefighting.
• Licensing shift to watch: in 2026 ServiceNow restructured its packaging from five legacy tiers into three AI-native tiers — Foundation, Advanced, and Prime — bundling Now Assist and related AI capabilities into every tier instead of selling them as separate add-ons, with usage measured on a consumption model. Anyone advising customers commercially needs to understand this shift.

Don't chase an "AI expert" label in isolation from platform fundamentals. Every one of these capabilities is only as trustworthy as the CMDB/CSDM data, ACL model, and knowledge base quality underneath it. The strongest emerging specialists combine solid fundamentals with AI Agent Studio / Build Agent fluency — not people who skip fundamentals to chase the newest feature name.

Final Thoughts

There is no single "correct" ServiceNow career — the platform is genuinely broad enough to fit almost any technical or analytical personality, from process-minded business analysts to security specialists to data purists to AI-agent builders. Pick a direction based on your natural inclination, get genuinely good at it over 12–24 months of focused depth, and only then broaden.

Trying to be equally expert in every module and every UI framework at once is the most common reason ambitious beginners burn out or stay permanently shallow across the platform. Depth first, breadth later — that sequence, more than any certification, is what actually produces ServiceNow experts.