This is the first in a chapter-by-chapter series walking through ServiceNow's AI stack, from the ground up. Before touching Now Assist, Agent Studio, or MCP, it's worth being honest about something: every AI feature on this platform is only as good as the data and workflow foundation underneath it. This chapter covers that foundation, with real examples of what goes wrong when it's skipped.
1. Data Model & CMDB Basics
AI features don't reason over a clean abstraction — they reason over whatever records and relationships actually exist in your instance. Bad CMDB data doesn't just cause reporting headaches anymore; it now feeds directly into what an AI agent tells a user.
Example — a mismodeled relationship producing a wrong AI summary:
Say an incident is raised against a business application, "Expense Portal," which is supposed to run on a specific application server CI. If that cmdb_rel_ci relationship was never created — or was created against the wrong server after a migration — then when Now Assist generates a summary of "related incidents affecting this service," it will either miss genuinely related incidents or pull in unrelated ones tied to the wrong server. The AI isn't wrong; the data it was handed was.
What to actually learn:
- The difference between a
cmdb_cirecord and acmdb_rel_cirelationship record — they are separate tables, and a CI with no relationships is functionally invisible to anything doing impact analysis. - How to trace a CI's relationships visually using the dependency view, before assuming a relationship exists just because two records reference the same service.
- Why reconciliation identification rules matter — a duplicate CI created by a second discovery source silently splits your relationship data across two records instead of one.
2. Flow Designer Essentials
Most Now Assist and agentic features eventually call into, or get called from, a flow. You don't need to be a flow expert before touching AI features, but you do need to be able to read one and know where an AI-driven action would plug in.
Example — a simple approval flow, annotated:
Take a basic hardware request approval flow: Trigger (record created on sc_request) → Ask for Approval (manager) → If Approved: Create Task → If Rejected: Notify Requester. This is the kind of flow a beginner should be able to open in Flow Designer and narrate out loud, step by step, before ever adding an AI action to it. Once you can do that, an AI-driven insertion point becomes obvious — for instance, a generative action summarizing the request's justification text for the approver, inserted right before the "Ask for Approval" step, so the approver sees a two-line summary instead of a wall of free text.
What to actually learn:
- Triggers, actions, and subflows — and the difference between a flow and a subflow reusable across multiple parents.
- Reading flow logs to see exactly which branch executed and why, since this is the same skill you'll need later to debug an agent's tool-calling decisions.
- Where flow variables come from and how they're passed between steps — generative actions consume and produce these the same way any other action does.
3. ACLs and Roles
An AI agent doesn't get its own separate permission universe — it typically runs as a service account or inherits context from the user it's acting on behalf of. If that account's role is too broad, the agent can read or touch data nobody intended it to.
Example — an over-permissioned agent account:
Imagine a case-summarization agent given the itil role for convenience during setup, instead of a scoped role limited to the specific table and fields it needs. Because itil grants broad read access across incident, problem, and change tables, the agent's summaries can end up referencing details from records the requesting user was never meant to see — a classic over-scoping problem that predates AI, but that AI makes more visible because the output is now surfaced directly to an end user in prose.
The fix: create a dedicated role scoped to exactly the tables and fields the agent needs, apply it via an ACL rather than relying on a broad out-of-box role, and test by impersonating the agent's account directly rather than assuming the scope is correct.
What to actually learn:
- How ACLs evaluate — table-level, field-level, and the role requirements attached to each.
- The "Elevate Roles" and impersonation tools for actually testing what a given role can see, rather than assuming from the role name.
- Why least-privilege matters more, not less, once an account's output becomes user-facing prose instead of a raw list a developer would sanity-check.
4. Basic Scripting: GlideRecord & GlideAjax
This isn't about becoming a scripting expert before touching AI features — it's about being able to read what a generated script is actually doing, since Now Assist for Creator and Build Agent will hand you code, and you need to be able to sanity-check it rather than deploy on faith.
Example — a script a beginner should be able to read line by line:
var gr = new GlideRecord('incident');
gr.addQuery('priority', 1);
gr.addQuery('state', '!=', 7); // exclude closed
gr.query();
while (gr.next()) {
gs.info('High priority incident open: ' + gr.number);
}
A beginner should be able to say, out loud, exactly what this does: it opens a query against the incident table, filters to priority 1 records that aren't closed, runs the query, and logs each matching incident's number. That's the bar — not writing this from scratch, but reading it and catching if an AI-generated version of this query forgot the state filter and would have logged every priority-1 incident ever created, closed or not.
What to actually learn:
- GlideRecord query patterns —
addQuery,addEncodedQuery, and why the order of chained queries matters. - GlideAjax basics — the client-to-server call pattern, since generative actions and agent tools follow a similar request/response shape.
- Where to spot common AI-generated mistakes: missing null checks, unscoped queries that should have been scoped, and queries that will run but return the wrong data quietly rather than erroring loudly.
Checkpoint Before Moving to Chapter 2
You should be able to: trace a CI's relationships and explain what breaks if one is missing; open a flow in Flow Designer and narrate its logic step by step; impersonate a role to verify what it can actually see; and read a short GlideRecord script and say exactly what it does and doesn't filter for. None of this requires expert-level depth — it requires enough fluency that when Now Assist hands you a generated flow or script in the next chapter, you're reviewing it, not trusting it blindly.
Next in this series: Chapter 2 — Now Assist as a Consumer, with a walkthrough of enabling it for ITSM and a real before/after of an incident summary.
