Safe harbor statement

This presentation may contain "forward-looking" statements that are based on our beliefs and assumptions and on information currently available to us only as of the date of this presentation. Forward-looking statements involve known and unknown risks, uncertainties, and other factors that may cause actual results to differ materially from those expected or implied by the forward-looking statements. Further information on these and other factors that could cause or contribute to such differences include, but are not limited to, those discussed in the section titled "Risk Factors," set forth in our most recent Annual Report on Form 10-K and Quarterly Report on Form 10-Q and in our other Securities and Exchange Commission filings. We cannot guarantee that we will achieve the plans, intentions, or expectations disclosed in our forward-looking statements, and you should not place undue reliance on our forward-looking statements.

The information on new products, features, or functionality is intended to outline our general product direction and should not be relied upon in making a purchasing decision, is for informational purposes only, and shall not be incorporated into any contract, and is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for our products remains at our sole discretion. We undertake no obligation, and do not intend, to update the forward-looking statements.

Today, start to finish

👋 Welcome — 10:00 AM – 5:00 PM. By the end of today, you'll build, test, source-control, and release a real app end-to-end.

• 1️⃣Foundations & build-ready requirements
• 2️⃣Build & Test with Build Agent & ATF
• 3️⃣Lunch
• 4️⃣Off-instance development
• 5️⃣Source control
• 6️⃣ReleaseOps
• 7️⃣Push to production & choose-your-own adventure

What is an "app" in this model?

The prescribed stack

Before Fluent: one representation, twice

Fluent separates build time from runtime

That's shifting left in practice: mistakes get caught at build time, in your editor, before an install — not at runtime, after something's already broken.

SDK + Fluent = source-driven development

export const MaintenanceRequest = Table({
  label: 'Maintenance Request',
  fields: { equipment: Reference('equipment') }
});

Git is the authoritative source of truth

We'll go deeper on this contrast later in the Source Control module.

Get your source control ready

• 1️⃣Initialize your first Fluent application with nowSDK.
• 2️⃣Create a new git repo, push it, and connect your instance to it with a personal access token.
• 3️⃣Build and install it, and confirm it lands on your dev instance.

Vague story vs. build-ready story

Your turn: rewrite it

• 1️⃣5 minutes — as a team, rewrite a vague story into one with entities, roles/access, and Given-When-Then.
• 2️⃣We present the requirements you'll actually build against this morning.
• 3️⃣Goal: finish the core requirements first — add extensions only if you finish early.

One instance, many developers, zero collisions

Allocate a sandbox before you start, create your feature branch inside it, decommission it when you're done.

Get your sandbox ready

What is Build Agent?

Build Agent in ServiceNow Studio

It reads your app's existing metadata, explains what a flow actually does in plain language, and proposes concrete fixes — grounded in your instance, not a generic answer.

Tests live in the dev loop, not bolted on

• 1️⃣Build Agent uses Test Agent to generate test cases from natural language.
• 2️⃣Run them, let Test Agent triage a failure, and fix it.

Build + test the maintenance app

// the Fluent code Build Agent writes under the hood
export const MaintenanceRequest = Table({
  label: 'Maintenance Request',
  fields: { equipment: Reference('equipment') }
});

🍽️

Back soon to re-anchor

Where we left off

Your app is built and tested. Next: source control and release.

The same app, off the platform

• 💻Same Fluent project, opened in VS Code or your terminal instead of Studio.
• 🤖Claude Code (or Cursor/Codex) in place of Build Agent — same SDK underneath.
• 🔁now-sdk build / now-sdk install work identically, on- or off-platform.

Exercise: ship it with Git

• 1️⃣Off instance (GitHub): push branch → open PR → review → merge → publish pre-release to the App Repo.
• 2️⃣On instance: open the instance and pull the changes in SNS / the IDE using git.

The App Repository: your bridge to ReleaseOps

ReleaseOps doesn't connect to source control directly — it's this auto-generated Update Set that gets promoted into a Deployment Request next.

ReleaseOps: Two objects, one pipeline

Two paths get you here: promote an Update Set into a Deployment Request (this lab), or trigger it from Git via the CI/CD REST APIs with an approval gate (see choose-your-own-adventure).

Why you need three instances

Assessment already moves the payload from dev to your test/staging target. If that's also your final destination, release has nowhere new to push — you need a separate instance for each stage.

The quality-control model

LAB: CREATE A DEPLOYMENT REQUEST, MARK "READY TO ASSESS," WATCH IT RUN

Promote, deploy, and roll back if needed

• 1️⃣Promote the Deployment Request to a release.
• 2️⃣Push to "production."
• 3️⃣Roll back within the fixed window — only when installed from the Application Repository.

Pick a track, go deep

Explore whichever track interests you most — we're here for questions. Head to the exercise for ideas to get started.

One picture, your app traced across it

QUESTIONS? PING Ashwin Patti, Shelby Cohen.

Warp Speed — vibe coding, on the platform

🙏

Full SDLC guide, reference, and troubleshooting:
servicenow.github.io/sdk/guides/sdlc-guide

Build Agent — Autonomous Engineering

• 📋Give it requirements — a prompt, a file upload (e.g. a CSV of user stories), or an MCP-connected tool like Jira — and Build Agent interviews you to resolve anything ambiguous, then produces a full implementation plan: work items in Agile-story format, sequenced by a dependency graph.
• ✅You review and approve every work item first — nothing builds until you sign off on the plan.
• ⚡Once approved, Build Agent runs a background agent per work item, building all of them in parallel — each one generates and runs its own ATF tests, with automatic retries and root-cause analysis on failures — then bundles everything into one Update Set when the plan completes.
• 🔑Requires the "Autonomous Engineer" app from the ServiceNow Store — check entitlements before promising this to a customer.
• 🖥️If accessible, show the new Studio UI live here instead of a screenshot — permissions-dependent, confirm access before the session.

Test Agent in Autonomous Engineering

• 🤖No separate prompt needed: Test Agent reads each work item's stories and acceptance criteria straight from the plan and generates ATF tests automatically as execution begins.
• 🔁Same auto-heal loop as today's flow — RCA on failure, safe fixes auto-applied or surfaced for your review — just running per work item, in parallel, instead of one prompt at a time.
• 🆕What's new here: UI tests are now generated too, not just functional ones — multi-step, browser-level flows — plus list and related-list test steps (filtering, related-list visibility).
• 💬Example prompt (works outside AutoEng too): Generate ATF tests for all the feature permutations on the app we built. Then: Execute all ATF tests.

Build Agent + MCP

One-time admin setup (Connect Hub + AI Control Tower approval), then any developer turns it on for themselves in their own Build Agent settings.

Custom rules — changing language

• 📝TODO: what a "custom rule" actually is in this context (terminology/localization? tone/style guidance for Build Agent output?) — confirm before presenting.
• 📝TODO: where it's configured, and whether it's app-scoped or instance-wide.
• 📝TODO: example prompt or before/after, if available.

BONUS SLIDE — PENDING/ROADMAP CONTENT PER LEGAL (SLIDE 2). PRESENTER TO FILL IN BEFORE SESSION.