SnapX Studio · AI agents for ServiceNow
Describe the work. Review every change. Ship to DEV with proof.
Like an engineer embedded in your team, Studio learns your instance first, then plans, builds, configures and tests on it. You approve the plan, see the exact record diff before anything installs, and get evidence when it lands: every record checked, the tests run.
A build on a developer instance, from request to proof: a meeting management app is planned, the plan approved, the record diff reviewed, then installed to DEV, verified record by record and tested. Now showing: All tests passed, checkpoint saved
How it works
The agents do the work. You make the decisions. Nothing reaches the instance until you have seen exactly what will change, and nothing counts as done without evidence.
Describe an app, a change, a setting or a test in plain words. Studio reads your instance first: what exists, what uses it and what your request would touch.
An editable blueprint: stories with acceptance criteria, the data model, a roles × tables access grid, logic and tests. Nothing is built until you approve it.
Your decisionA record-by-record diff of what will be added, changed or removed. ACL, role, schema and delete changes are flagged, with a plain-language checklist.
Your decisionThe install is bound to the exact build you reviewed and goes to development instances only. Platform configuration goes into a named update set instead.
Every record is checked on the instance and in the app's scope, and the ATF tests run. A feature counts as verified only with that evidence.
Each verified feature is a checkpoint. Restoring goes forward through review again, and says plainly what it cannot undo, such as data rows and manual edits.
Capabilities
Each view below is drawn from what Studio did on a ServiceNow personal developer instance: the names, records and results are the real ones.
Describe the app. Studio writes it as Fluent code with the ServiceNow SDK and installs it as a scoped application, so every table, role, ACL and menu lands in the app's own scope.
x_174120_meetings, with its own tables, roles, ACLs, approval flow, notification and menu.Add to or fix an app already on the instance. Studio reads the app's current records first, plans only what is new, and proves each feature landed before the next begins.
Upcoming Meetings
| Title | Start | Meeting room |
|---|---|---|
| Supplier review | Thu 10:00 | Online |
| Design review | Fri 14:30 | Boardroom |
| Team retrospective | Mon 09:30 | Room A |
Change out-of-box apps and global settings through a named update set. You review each change group's before and after, with its impact from where-used, then apply it, revert it or promote it.
| Field | Before | After |
|---|---|---|
| Short description | none | Incident: Caller mandatory for Service Desk |
| Conditions | none | Assignment group is Service Desk |
| Order | none | 200 |
| Reverse if false | none | true |
Impact. The out-of-box ‘Set Caller field mandatory state’ policies run first; order 200 lets this one win for Service Desk. Form only: list edits, imports and REST are not covered.
| Field | Before | After |
|---|---|---|
| Category choices | Inquiry / Help, Software, Hardware, Network, Database, Password Reset | + Facilities (value facilities) |
Captured via choice list sys_choice_incident_category.
Uses it, unchanged: UI policy ‘Make fields read-only on close’, inbound email actions ‘Create Incident’ and ‘Create Incident (Forwarded)’, ACL *.category.
Write ATF regression tests for configuration that is already there, and run them with your existing suites. Tests that need a browser run in a headless Chrome runner on this machine.
Finding: resolution notes are enforced on the form only, not server-side. A server-side update can resolve an incident without notes. Reported to you; the test was not edited to pass.
Six specialist agents share one box. Type once: the right one takes it, or several work through a plan you can see and change before it runs.
Write user stories for visitor sign-in at reception, then check which existing tables we could reuse.
Plan · Business Analyst, then ArchitectStories first, then reuse analysisChange
Run a whole delivery: scoping, architecture, stories, plan, build, test and report, one role per stage, with an approval gate after every stage.
Gate · Build
The Developer submitted the build log, with the Studio's own record of every ServiceNow write.
Document pack
Agents start from a context index of your instance, not from guesses: configuration and its code, a dependency graph, and foundation data. They use it before they query live.
Where-used: incident.category
Data map · path
Give a role a goal and it keeps working without being asked: on a schedule, on a watch over ServiceNow records, or when an event arrives. When it is unsure, it asks.
Review queue
“Change request moved to Assess”: not clearly relevant to this goal, so it waits for you.
Trust and control
The safeguards that matter are enforced by Studio and its ServiceNow connector, not left to the model's good behaviour.
Agents read freely; every write waits for you. The approval card names the role asking, focus never jumps to Approve, and Approve unlocks only after a short pause.
Builds, installs and schema changes are accepted on development instances only. On test instances agents read and run tests; on production they read and raise change requests.
An ACL write takes security_admin for that call only, then drops it. The approval card turns red, and Approve unlocks only when you type the table name.
ServiceNow credentials stay in the connector. Agents run with no shell, no files outside their workspace and no web access, and never see a password or token.
Studio records every approval, install, configuration change, sign-in and admin action with the person responsible. Each ServiceNow call is logged with what, where and the outcome; field names are recorded, their values never are.
Everyone signs in. Admins choose who may use which agents and instances, and can act as a user, with a banner on screen and every change recorded under both names.
Security and ISO/IEC 27001
ISO/IEC 27001 certifies an organisation's information security management system, not a piece of software. SnapX Studio is not certified. What it brings to your ISMS are working controls, mapped below to ISO/IEC 27001:2022 Annex A.
A.8.32 · Change management
Changes are planned, shown record by record or field by field, and approved before they are applied. Configuration lands in a named update set that can be reverted and exported for promotion.
A.8.31 · Separation of environments
Installs, schema and ACL changes are accepted on development instances only. Test instances run tests; production is read-only apart from change requests.
A.8.2 · Privileged access
An ACL change takes security_admin for that call only, with a typed confirmation. Admin rights in Studio are a separate role, and acting as a user is shown on screen and recorded.
A.5.15 · A.8.3 · Access control
Everyone signs in. Threads, builds, projects and Dots belong to their owner, and admins decide which agents and instances each person may use.
A.8.5 · Secure authentication
Passwords are hashed with scrypt, accounts lock after repeated failures, sessions are held on the server, and invite links work once.
A.8.15 · Logging
Approvals, installs, configuration changes, sign-ins and admin actions are recorded with the person responsible, and values never enter the ServiceNow call log.
A.8.28 · Secure coding
A strict Content Security Policy, escaped output and parameterised queries. Agents get no shell and no web access, and never see a credential.
A.8.29 · Security testing
Automated tests cover sign-in, lockout, record ownership, connector policy and workspace confinement on every change to Studio.
Where we stand. We have completed an ISO/IEC 27001:2022 gap assessment of Studio and the way it is run. Multi-factor sign-in, encryption at rest, backups and tamper-evident audit storage are on the roadmap it set. Ask your SnapX contact for the current assessment.
Sign in with the account your admin made for you. No account yet? Ask an admin for an invite link.