What We Built

The first version of the AI chat widget proved the concept — employees could ask about their incidents and get real answers. This phase turned it into something an enterprise could actually ship: four distinct user tiers with different capabilities, a full L1 troubleshooting engine, write actions that let the bot take real steps in ServiceNow, and security hardening that clears CIS baseline.

Role-Based Tiers

The biggest architectural change was making the bot context-aware based on who's asking. A standard employee should never see another user's ticket. An ITIL agent needs to resolve and assign. An admin needs instance-wide visibility. One bot, four completely different behaviors.

The ClaudeChatUtil Script Include detects the user's role at runtime and routes them to the appropriate context builder and system prompt:


gs.getUserID() + getUserRole()
  → admin     → instance-wide incidents, P1 count, open problems, pending changes
  → itil      → group queue, unassigned tickets, SLA at risk, KB search, write actions
  → cso       → catalog requests, incident creation via conversation
  → standard  → own incidents/requests + L1 troubleshooting + limited write actions

Each tier gets a different system prompt loaded from a private ServiceNow property — no hardcoded instructions, fully configurable by admins post-install.

L1 Troubleshooting Engine

The standard tier includes a full L1 script covering 12 common scenarios: VPN, locked accounts, MFA, Outlook crashes, printer offline, slow PC, Wi-Fi, OneDrive, webcam, Remote Desktop, blocked email attachments, and shared drive issues. Each scenario runs through three steps before escalating to ticket creation.

The bot doesn't just list steps — it disambiguates. "I can't connect" triggers a connectivity question: is it VPN, Wi-Fi, or the specific app? Physical damage escalates immediately. Bypass phrases like "already tried" skip steps the user already covered.


User: "My computer is running really slow"
  → Bot: CPU/disk usage check → background process scan → disk space check
  → If unresolved: "Want me to create an incident with the steps we tried?"
  → User confirms → create_incident_post_troubleshooting ACTION signal fires
  → INC created with steps_tried field populated

Write Actions

Three write actions are available to standard users, gated by confirmation:

  • create_incident_post_troubleshooting — creates an INC after L1 exhaustion, includes every step tried
  • create_catalog_request — collects mandatory variables conversationally then submits the request on confirmation
  • request_update — adds a work note to an existing incident, but only if the last note is more than 2 hours old (prevents update flooding)

ITIL agents get additional write actions: add work note to any incident, assign to self, and change state. All write actions are triggered by structured ACTION signals in the bot response — the API layer parses them and executes the ServiceNow write separately from the response text.

Catalog Intelligence

Catalog discovery was the trickiest piece. The original version just listed available catalog items and hoped the user asked for the right one by name on the next turn. That caused a re-asking loop — the bot would recommend an item, the user would say "yes," and the bot would ask for the item name again.

The fix was history-aware matching: on each turn, the Script Include scans the last six assistant messages plus the current user message for catalog item names. If the bot already recommended an item, it finds it immediately and injects the mandatory fields for collection — no re-asking.

Items with no mandatory fields get a CATALOG_READY signal, which submits on a single user confirmation. Items with required fields trigger a conversational collection loop that asks for each field in plain language before submitting.

CIS Security Hardening

Moving from dev to enterprise meant closing the credential and logging gaps.

Credential storage — The API key moved from a plain-text system property to a ServiceNow Connection Alias backed by sys_credential. The credential is AES-256 encrypted at rest, never returned by the REST API, and role-controlled. This satisfies CIS Control 3 (Data Protection) and is required for ServiceNow Store submission.

Audit logging — Every chat interaction writes a structured record to a custom audit table: user ID, role tier, message preview, action signal, response preview, response time in milliseconds, and a flag for security probe attempts. Records purge automatically after 90 days via a scheduled script.

Rate limiting — A server-side check uses GlideAggregate on the audit table to count messages per user in the last 60 seconds. Limit defaults to 10 per minute, configurable by admins via a system property. No client-side enforcement — all of it happens in the Script Include before the AI call is made.

Security pre-filter — Common abuse patterns (jailbreak attempts, off-topic requests, reveal-prompt probes) are caught by a regex filter before the message reaches Claude. Security probes are logged and flagged in the audit table.

Skills Demonstrated

  • ServiceNow Script Include architecture with role-based routing
  • Multi-tier system prompt management via private system properties
  • Structured ACTION signal parsing for write operations
  • GlideAggregate-based server-side rate limiting
  • Custom audit table with scheduled retention purge
  • ServiceNow Connection Alias credential pattern (CIS-compliant)
  • History-aware context scanning across conversation turns

Why It Matters

The gap between "a working AI bot" and "an AI bot an enterprise will actually deploy" is almost entirely security and role control. Employees will find creative ways to use any tool you give them — the bot needs to handle that gracefully, log what happens, and never let a standard user touch another user's data. This build closes those gaps in a way that's configurable, auditable, and deployable to any ServiceNow instance.