ServiceNow architecture, end to end, in plain English
Every ServiceNow instance is the same eleven layers stacked on top of each other, from the cloud machines it runs on to the AI agents now working inside it. This page walks all eleven, shows you exactly what happens in the milliseconds after you click Save, and explains the rules that decide which code runs when. No prior ServiceNow experience assumed.
The whole platform in sixty seconds
ServiceNow is one application server talking to one database, wrapped in a very large amount of configuration. Almost everything you will ever touch is a record in a table, including the tables themselves, the forms, the scripts, the workflows and the security rules. Once that clicks, the rest of the architecture stops feeling like magic and starts feeling like layers.
It is your own instance
You do not share a database with other customers. Each customer gets dedicated application nodes and a dedicated database, which is why you can change the schema, run your own scripts and upgrade on your own schedule.
Everything is a table
Incidents, users, forms, business rules, flows, roles and even the definition of a table are all just rows. The platform reads its own configuration out of the database at runtime, which is why a change takes effect without a deployment.
The order is fixed
Client scripts, UI policies, business rules, data policies and ACLs always run in the same sequence. Most bugs that look mysterious are really a misunderstanding of that sequence, which is documented below in full.
Click any layer to jump straight into it
Five pictures that explain most of the platform
If you only take five things away from this page, take these. Each diagram is drawn to match how the platform really behaves, not how it is usually drawn on a whiteboard, and each one is explained in words underneath so you are never guessing at what a box or an arrow means.
Where your instance physically lives
One customer, one instance. This is the shape of the thing your login actually reaches, and the reason ServiceNow is described as multi-instance rather than multi-tenant.
Scroll the diagram sideways, or tap Enlarge for a bigger view
How ServiceNow reaches things inside your network
The MID Server is the single most misunderstood piece of ServiceNow integration architecture. This diagram shows why it never needs an inbound firewall rule.
Scroll the diagram sideways, or tap Enlarge for a bigger view
The eleven layers, in order
Every request you will ever trace enters at the top, works its way down as far as it needs to go, and the answer comes back up the same way.
Scroll the diagram sideways, or tap Enlarge for a bigger view
The task tree, and the trap inside it
Table extension is how ServiceNow reuses one set of fields across every kind of work. It is also the source of the most common misunderstanding in the platform.
Scroll the diagram sideways, or tap Enlarge for a bigger view
task inherits every field, every business rule and every list behaviour defined on task itself, which is why an incident and a change request both have a number, a state, an assignment group and an approval field without anyone building them twice. The trap is at the bottom. Request, requested item and catalog task all extend task as siblings; they are not parents and children of each other. A RITM is joined to its REQ by a reference field, and an SCTASK to its RITM the same way. Writing a script that assumes inheritance there is one of the fastest ways to break service catalog fulfilment.How the platform decides what you may see
Access control in ServiceNow is not a single check. It is an ordered sequence, and every stage of it can say no.
Scroll the diagram sideways, or tap Enlarge for a bigger view
Where to start, depending on who you are
This page is long on purpose, because architecture is not something you can learn from a single diagram. You do not have to read it top to bottom. Pick the path that matches why you are here.
I am new to ServiceNow
Start at the top of the stack explorer and read the layers in order. Do not skip Data and Data Model - they explain more of the product than anything else. Then read the 'saves an incident form' trace twice.
- Read layers L1 Data and L2 Data Model
- Walk the form save trace
- Read the client vs server comparison
- Skim the glossary and come back to it
I am an admin or developer
You already know the surface. The value here is in the order of execution, the platform services layer and the decision guide.
- Layer L3 Platform Services, especially semaphores
- The full order of execution
- The decision guide
- The anti-patterns list
I am preparing for an architect role
Focus on the decisions and the trade-offs rather than the mechanics. Be able to defend an instance strategy, a CMDB data source model and an AI governance position.
- L0 Cloud and Instance
- CMDB, IRE and CSDM
- L7 Security, especially domain separation
- L10 Development and Release
- The decision guide, out loud, with reasons
I have an interview next week
Interviewers probe the same handful of areas. Know the order of execution cold, be able to draw the MID Server round trip, and have an opinion on business rule versus flow.
- Order of execution
- MID Server and ECC Queue trace
- ACL evaluation
- The Service Catalog REQ / RITM / SCTASK chain
- Two anti-patterns you have personally fixed
All eleven layers, one at a time
Each layer answers four questions: what it actually is, what lives inside it, how it connects to the layers above and below, and what usually goes wrong. The plain-English analogy at the top of each layer is there for anyone new to the platform. Everything below the analogy is the real detail.
Cloud & Instance
Where your ServiceNow physically runs
An instance is one complete, self-contained ServiceNow system: a URL such as acme.service-now.com, a set of Java application nodes that run the platform code, a dedicated database, and file storage for attachments. Nothing in your instance is shared with another customer at the application or database level. Because of that you can be upgraded on your own schedule, cloned, restored and encrypted independently, and a badly written script on someone else's instance can never slow yours down.
sys_cluster_state | One row per application node in your cluster, with node status and last heartbeat. |
sys_properties | Instance-wide configuration switches (glide.* properties) read by almost every platform service. |
sys_upgrade_history | Record of every family release upgrade and patch applied to the instance. |
syslog_transaction | One row per HTTP transaction with response time and SQL time. The starting point for any performance investigation. |
Multi-instance, not multi-tenant
ServiceNow's Advanced High Availability white paper states it plainly: instances are deployed on a multi-instance architecture that provides separate application nodes and database processes for each customer. Practical consequences: your data is never co-mingled, you can be on a different release than another customer, you can be restored from backup without affecting anyone else, and noisy-neighbour problems are limited to your own instance.
Advanced High Availability (AHA): two live sites, not a cold standby
Production data is hosted simultaneously across two geographically paired data centres. Both sites are live and each is sized to carry the full production load on its own, kept in sync by continuous database replication. There is no permanent primary site for a given customer - the instance simply runs at whichever site is currently active. ServiceNow targets a recovery time objective of two hours and a recovery point objective of one hour for a full site outage.
Planned transfer vs unplanned failover
A planned transfer is a scheduled move of your instance between paired sites, usually for maintenance, with a short and communicated interruption. An unplanned failover is the emergency path: the standby database is promoted to active and the previously active database becomes passive. Because both sites already hold your data, this is a promotion rather than a restore.
Backups
Full backups run weekly and are retained for a minimum of fourteen days across both sites. Differential backups run daily with seven-day retention. Backups are for disaster recovery, not for undoing a bad update set - for that you want update set rollback, or a clone from a good sub-production instance.
Instance types and the sub-production estate
A normal customer runs at least three instances: development, test and production. Larger programmes add QA, UAT, training, a sandbox, and sometimes a dedicated integration or performance instance. Sub-production instances are smaller (fewer nodes) than production, which is why load testing on a dev instance tells you very little. Individual learners get a free Personal Developer Instance (PDI) from the developer portal, which hibernates after ten days of inactivity.
Cloning
Cloning copies production over a sub-production instance so developers work against realistic data and configuration. A clone profile controls what happens: exclusion lists skip large or sensitive tables (typically sys_email, syslog, ecc_queue, sys_attachment on some estates), and data preservers protect target-instance records that must survive the clone, such as integration credentials, LDAP configuration, email properties and MID Server records. Clones overwrite the target completely, so anything in flight on the target that has not been captured in an update set is lost.
Family releases and patching
ServiceNow ships two major family releases a year, named alphabetically after cities and countries. The current family as of mid-2026 is Australia, which entered early availability on 12 March 2026 and reached general availability in Q2 2026. The sequence around it is Yokohama (GA March 2025), Zurich (Q4 2025), Australia (Q2 2026), Brazil (Q4 2026), Canada (Q2 2027) and Denmark (Q4 2027). Between family releases you get patches and hotfixes. Upgrades are applied to sub-production first, and the Upgrade Monitor plus the skipped-changes list tell you which of your customisations collided with a platform change and now need review.
Hosting and sovereignty options
Beyond ServiceNow's own Advanced Cloud there are hyperscaler-hosted options (Microsoft Azure and Google Cloud for certain regions and customers), self-hosted deployments for organisations that must run the platform on their own infrastructure, and regulated offerings such as the Government Community Cloud for FedRAMP workloads. The application architecture is identical across all of them; what changes is who operates the underlying infrastructure and where the data physically sits.
- Adding application nodes increases how many transactions run at once. It does not make one slow query faster.
- A clone is not a backup and a backup is not a rollback. Know which of the three you actually need before you ask for it.
- Sub-production instances are deliberately smaller than production, so performance results from dev are not transferable.
- AHA protects against a site failure. It does not protect against someone deleting a table - replication faithfully copies the delete to the other site.
- Instances are upgraded, not migrated. If you have heavily customised a platform table, every family release is a merge negotiation you have to attend.
Database & Persistence
Everything is a table, every row has a sys_id
Nothing in ServiceNow escapes the database. Incidents are rows. Users are rows. But so are business rules, ACLs, UI policies, form layouts, scheduled jobs, update sets and the definitions of the tables themselves. This is the single most important idea in ServiceNow architecture: configuration and data live in the same store, and the same query, security and audit machinery applies to both.
sys_db_object | The list of every table in the instance, including its parent table and scope. |
sys_dictionary | Every field of every table. Editing a row here changes your schema. |
sys_documentation | Column and table labels, plural forms and hints, per language. |
sys_glide_object | The catalogue of field types (string, reference, glide_date_time, journal, and so on). |
sys_choice | Choice list values for choice fields, per table, per field, per language. |
sys_attachment / sys_attachment_doc | Attachment metadata and its chunked content. |
sys_audit | Field-level change history for audited tables. |
sys_journal_field | The actual text of every work note and comment in the instance. |
sys_number | Per-table number prefixes and counters (INC, CHG, RITM and friends). |
sys_id: the universal primary key
Every row in every table has a sys_id: a 32-character hexadecimal GUID that is unique across the entire instance and never changes. Reference fields store a sys_id, not a display value. Update sets identify configuration records by sys_id. When you move an application between instances the sys_id travels with it, which is exactly why a record created in dev can be updated in production rather than duplicated.
The system columns every table inherits
sys_created_on, sys_created_by, sys_updated_on, sys_updated_by, sys_mod_count (how many times the record has been saved), sys_class_name (which table in an extension hierarchy the record really belongs to), sys_domain and sys_domain_path (domain separation), sys_scope (which application owns a configuration record) and sys_tags. These are free, indexed, and worth knowing by heart because they answer most audit questions without any custom work.
The dictionary is live schema
sys_dictionary is not documentation, it is the schema. Adding a row adds a column. Changing max length alters the column. Adding an attribute changes runtime behaviour. This is what makes ServiceNow feel low-code: the same forms-and-lists interface that manages incidents manages the database structure. It is also why an unreviewed dictionary change can be a genuinely disruptive event.
Journal fields are rows, not columns
Work notes and additional comments look like fields on the form but they are append-only entries in sys_journal_field, keyed by element name and the record's sys_id. That is why you cannot sort a list by work notes, why reporting on comments is awkward, and why the activity stream can be expensive to render on a record with thousands of updates.
Table rotation and table extension for high-volume data
Some tables would grow without limit - syslog, sys_email, ecc_queue, event logs. ServiceNow handles these with rotation (a set of shadow tables where the oldest is truncated and reused on a schedule) or extension (new shadow tables created over time and old ones dropped). You query the logical table and the platform transparently spans the shards. It is the reason you cannot simply add an index to syslog and expect it to behave like a normal table.
The Table Cleaner
sys_auto_flush defines age-based deletion for chosen tables: keep syslog for a month, keep sys_email for a quarter, and so on. It runs on the scheduler. On instances that have been live for years, an unreviewed Table Cleaner configuration is one of the most common causes of both runaway growth and unexpectedly missing history.
Database views
A database view (sys_db_view) joins two or more tables at query time so you can report across them - the classic example joins incident to metric_instance for resolution time analysis. Views are read-only, they are defined in the platform rather than the database, and a badly built view is an excellent way to bring an instance to its knees at 9am on a Monday.
RaptorDB: the HTAP engine
RaptorDB is ServiceNow's own hybrid transactional/analytical processing database engine. It runs transactional and analytical queries against the same live dataset by combining row storage with column-store indexing and parallel query execution, so heavy reporting stops fighting with day-to-day form saves. ServiceNow cites 45 percent faster data processing and a 59 percent reduction in compute time for user-initiated transactions. Architecturally the important point is that it removes a whole class of ETL-to-a-warehouse patterns, and it supports cloud, self-hosted and hybrid deployments.
- Reference fields hold a sys_id. A report that appears to compare names is really comparing GUIDs, which is why a badly built reference qualifier silently returns nothing.
- Deleting a field in the dictionary drops the column and the data. There is no undo outside a restore.
- Do not build reporting on sys_journal_field. If you need to report on it, the process design is usually the real problem.
- sys_mod_count is a cheap and reliable way to spot records that are being updated far more often than the process should require.
- Adding indexes helps reads and costs writes. On a table with heavy inserts, an extra index is not free.
Data Model & Schema
Table extension, the task hierarchy, and the CMDB
Table extension is class inheritance applied to a database. A child table inherits every field, business rule, ACL and UI policy defined on its parent, adds its own, and stores its identity in sys_class_name. Query the parent and you get every child. This single mechanism explains the Task hierarchy, the CMDB, the Service Catalog request chain and most of the platform's product lines.
task | The parent of nearly every work item: number, short description, assignment group, assigned to, state, priority, SLA hooks, approvals. |
sys_user / sys_user_group / sys_user_grmember | Users, groups and the many-to-many membership table between them. |
sys_user_role / sys_user_has_role / sys_group_has_role | Roles and how they attach to users and groups, including inherited roles. |
core_company / cmn_location / cmn_department | Foundation data that most processes reference and most implementations under-plan. |
cmdb_ci | The root of the configuration item hierarchy. |
cmdb_rel_ci | Every relationship between two CIs, with a relationship type. |
sys_metadata | The parent of application-file tables, which is how the platform knows what belongs in an update set. |
The Task hierarchy
task is the workhorse parent. Its direct and indirect children include incident, problem, problem_task, change_request, change_task, sc_request, sc_req_item, sc_task, sn_customerservice_case, sn_hr_core_case, kb_submission, and any custom task-based application you build. Because they share a parent, they share the assignment model, the state model, the approval engine, SLAs, the activity formatter and Agent Workspace behaviour. This is why building a new work-management app on task takes days instead of months.
How extension is stored
ServiceNow uses table-per-class storage: the parent table holds the shared columns, each child table holds only its own additional columns, and a query on the parent joins across them. sys_class_name records the real class of each row. The upside is a clean model and free polymorphic queries. The cost is that queries against a deep hierarchy join more tables, which is one reason very deep custom extension trees are discouraged.
The Service Catalog request chain
One of the most-asked interview topics and one of the clearest illustrations of the model. Ordering from the catalog creates one Request (sc_request, prefix REQ) that represents the order. Each item in the cart creates a Requested Item (sc_req_item, prefix RITM). Each RITM's workflow or flow generates one or more Catalog Tasks (sc_task, prefix SCTASK) that people actually work on. All three extend task, which is why they all have assignment groups and SLAs without anyone building that.
Reference fields and dot-walking
A reference field stores the sys_id of a row in another table. Because the platform knows the target table from the dictionary, it lets you dot-walk: on an incident you can filter or display caller_id.department.dept_head.email without writing a join. Dot-walking is powerful in conditions, reports and flows, and it is expensive if you dot-walk across several hops in a list of ten thousand rows.
Reference qualifiers
A reference qualifier limits what a reference field can point at - only active users, only groups of a given type, only CIs in a certain class. Simple qualifiers are a condition, dynamic qualifiers call a script include, and advanced qualifiers build an encoded query. Getting these right is most of the difference between a form that guides a user and a form that lets them create bad data.
When to extend, when to create, when to reuse
Extend task when your record is a piece of work someone is assigned and must complete. Extend an existing product table only when your thing genuinely is a specialisation of it. Create a standalone table for reference or configuration data that nobody works on. Do not extend incident to create a near-copy for another team - use the existing table with a category, or build a proper application. Every unnecessary extension is a permanent tax on upgrades, reporting and performance.
Foundation data is architecture
Users, groups, locations, companies, departments and cost centres feel like data-entry rather than design, but they determine assignment, approval routing, cost allocation, entitlement, reporting hierarchies and access control. Deciding which system is the source of truth for each of them - typically an HR system for people and structure - is one of the earliest and most consequential architectural decisions in a programme.
Number maintenance
sys_number holds the prefix, current number and padding per table. It is why incidents are INC0010023 rather than a GUID. Two things surprise people: numbers are allocated at insert and are not reused, so gaps are normal; and after a clone, the counter comes from the source instance, which is why sub-production numbers can leap forward.
- Extending a table you did not build ties you to its future. Every family release can change the parent underneath you.
- A query on task with no filters touches every incident, change, request, catalog task and HR case in the instance.
- Dot-walking more than two or three hops in a list view is a common and avoidable performance problem.
- Custom fields belong in your own scope with a u_ or x_ prefix. Reusing a platform field for a different meaning is a debt you will pay at the next upgrade.
- If two teams disagree about what a field means, that is a data model problem, not a training problem.
Platform Services
The Glide engine: sessions, caches, semaphores, schedulers
Above the database and below your application logic sits the Now Platform application server, still widely called Glide. It owns the request lifecycle, the JavaScript engine, session state, the caching tiers, the transaction quota and semaphore machinery, the event queue and the scheduler. Almost every serious performance conversation is really a conversation about this layer.
syslog_transaction | Every transaction, with total time, SQL time, business rule time and the URL. Your first stop for slowness. |
sys_trigger | The live scheduler queue. Every job waiting to run, and every job currently running, is here. |
sysauto / sysauto_script | Scheduled job definitions, including scheduled script executions. |
sysevent / sysevent_register | The event queue and the registry of known event names. |
sysevent_script_action | Server scripts triggered by an event rather than by a record change. |
sys_semaphore_set | Semaphore pool definitions and their sizes. |
syslog | The general application log - gs.info, gs.error and platform messages. |
Semaphores: the most important word in ServiceNow performance
Each application node has a fixed number of semaphores - concurrent transaction slots - divided into pools by transaction type, typically a default pool for interactive traffic and separate pools for REST/SOAP integration traffic, and for AMB. A transaction must take a semaphore to run. If all slots in a pool are in use, new requests queue; if the queue is long enough they are cancelled with a semaphore exhaustion error. This is why a handful of very slow queries can make the whole instance feel dead: they are not consuming much CPU, they are holding the slots. Separating integration traffic into its own pool exists precisely so a runaway integration cannot starve human users.
Transaction quotas
Quota rules (Transaction Quota Rules) cap how long a class of transaction may run before it is cancelled - for example a limit on interactive transactions, on REST calls or on scheduled jobs. They are a safety valve, not a tuning tool. When you see 'Transaction cancelled: maximum execution time exceeded', a quota rule did that deliberately to protect the instance.
Caching and why your change did not appear
Dictionary definitions, ACLs, properties, choice lists, UI policies and script includes are cached in memory on every node. Most changes invalidate the relevant cache automatically, but some low-level changes - certain dictionary attributes, some property changes - do not propagate immediately. That is the entire story behind the folklore of running /cache.do. On a multi-node instance, a cache flush is a cluster-wide event and is not free, so it belongs in a change window, not in a habit.
Foreground vs background: the scheduler
Anything that must not block a user runs on the scheduler: scheduled jobs, events, async business rules, SLA recalculation, imports, Discovery, and report caching. sys_trigger is the live queue. Each node runs a limited number of worker threads, so a long-running job occupies a worker for its whole duration. A single badly written scheduled script that runs every minute and takes ninety seconds will slowly consume the entire worker pool - a classic and very common production incident.
Events, notifications and script actions
An event is a lightweight message: a name, the record it concerns, and up to two parameters. Code raises one with gs.eventQueue. The event lands in sysevent and is processed asynchronously. Notifications can be triggered by events, and script actions run server code in response to them. Events are the correct tool when you want to decouple a side effect from the transaction that caused it, and they are much kinder to response times than doing the work inline.
Sessions, impersonation and the user object
The session holds the authenticated user, their roles (expanded through group membership and role inheritance), language, timezone, active domain, and current application scope. gs.getUser() and g_user expose parts of it. Impersonation swaps the effective user while recording who is really behind the keyboard in the session log - which is why impersonating to test ACLs is safe and auditable, and why you should test as a real low-privilege role rather than assuming.
Reading a slow transaction
Open syslog_transaction and compare total response time against SQL time and business rule time. Time dominated by SQL points at a missing index, an unfiltered query or a database view. Time dominated by business rules points at your code, often a GlideRecord query inside a loop. Time in neither is usually rendering: too many related lists, too many form fields, or a heavy client script. Session Debug and the transaction detail page break this down further.
Node roles and where things actually run
Not every node is doing the same thing. Some are handling interactive traffic behind the load balancer while others are dedicated to scheduler work or to specific background processing. This is why 'it is slow' needs a follow-up question: slow for users clicking forms, or slow for jobs finishing? They have different causes and different fixes.
- A GlideRecord query inside a loop is the single most common cause of slow business rules. Query once, use GlideAggregate for counts.
- Async business rules are not instant. They queue on the scheduler and can run seconds later - never rely on them for anything a user sees immediately.
- Flushing the cache on production during business hours affects every node and every user. Treat it as a change.
- gs.sleep and long loops in a transaction hold a semaphore for their entire duration.
- Scheduled jobs that overlap themselves will happily stack up. Check the run time against the schedule interval.
Application Logic
Server-side, client-side, and knowing which is which
This is the layer most ServiceNow careers are spent in. It splits cleanly in two. Server-side code runs on an application node, has full access to the database through GlideRecord, and cannot be bypassed. Client-side code runs in the user's browser, can make the form feel responsive, and can be bypassed by anyone who knows how. Understanding which side you are on, and why, is the single biggest step from beginner to competent developer.
sys_script | Business rules. |
sys_script_include | Script includes. |
sys_script_client | Client scripts. |
sys_ui_policy / sys_ui_policy_action | UI policies and the field actions they apply. |
sys_ui_action | UI actions - buttons, links, related links, context menu items. |
sys_data_policy2 / sys_data_policy_rule | Data policies and their field rules. |
sys_script_fix | Fix scripts. |
sys_scope | Application scopes and their prefixes. |
Business rules: the four types, in the order they matter
A Display business rule runs before the form is sent to the browser and is the correct way to pass server data to client scripts via the g_scratchpad object. A Before rule runs inside the same database transaction, before the record is written, so changes to the current object are saved with no second write - this is where you set field values and abort with current.setAbortAction(true). An After rule runs after the write, in the same transaction, and is for acting on related records. An Async rule is queued to the scheduler and runs later, outside the user's transaction, which is right for expensive work and wrong for anything the user expects to see immediately.
Script includes and why they exist
A script include is a server-side class or function loaded on demand. Three flavours matter. A classic class-style include with initialize and prototype is the standard reusable library. An on-demand function include is a single function, useful for reference qualifiers. A client-callable include extends AbstractAjaxProcessor and is the server half of a GlideAjax call. Putting logic in an include instead of in a business rule means it can be tested, reused, called from flows, and reviewed in one place.
GlideRecord, GlideAggregate, GlideQuery
GlideRecord is the workhorse: new GlideRecord('incident'), addQuery, query, while(gr.next()). Use setLimit when you only need a few, use addEncodedQuery for complex conditions, and never call query() inside a loop over another query. GlideAggregate is for counts, sums and averages - it does the arithmetic in the database rather than dragging rows across. GlideRecordSecure applies ACLs to the results, which matters when server code runs on behalf of a user. GlideQuery is the newer fluent API: chainable, harder to misuse, and it fails loudly instead of silently returning nothing.
Client scripts and the four events
onLoad runs once when the form renders. onChange runs when a specific field changes and receives control, oldValue, newValue and isLoading - the isLoading guard exists because onChange also fires during form load. onSubmit runs when the user saves and can return false to stop it. onCellEdit runs on inline list edits. The API is g_form for the form, g_user for the current user's roles and identity, and g_scratchpad for data handed down by a display business rule.
UI policies vs client scripts: prefer the declarative one
A UI policy makes a field mandatory, visible or read-only based on a condition, with no code, and it can reverse itself when the condition stops being true. A client script does the same thing with script. UI policies run after client scripts, are easier to read, are self-documenting in a list, and survive handover. Reach for a client script only when the logic is genuinely beyond a condition builder. On catalog items the equivalents are Catalog UI Policies and Catalog Client Scripts.
The rule you must never break
Client-side validation is a user experience feature, not a security control. A user with the browser console open can bypass every client script and UI policy you have written, and an integration posting to the Table API never sees them at all. If a rule must always hold, it belongs in a before business rule, a data policy or an ACL. Data policies are particularly useful here because the same rule can be enforced on forms, imports and web services from a single definition.
Scoped applications and cross-scope access
Every application has a scope with a prefix, typically x_ plus a vendor code. Scoping gives you a namespace, a runtime boundary and an explicit contract for what the outside world may touch. Tables carry Application Access settings that declare whether other scopes may read, create, update or delete them and whether scripts outside the scope can call in. Cross-scope privilege records (sys_scope_privilege) log and authorise calls between scopes. Global is the legacy everything-scope: convenient, unbounded, and the reason so many old instances are hard to upgrade.
Order of execution, condensed
On save, the browser runs UI policies and onSubmit client scripts, then posts. On the server the platform checks ACLs, runs Display rules only on read, then before-engines and Before business rules, then the database write, then After business rules in the same transaction, then Async rules on the scheduler, and then flows and workflows triggered by the change. Knowing this order is what turns 'my field is not being set' from a mystery into a two-minute diagnosis.
- current.update() inside a before business rule causes a second write and can recurse. Just set the field; the platform saves it.
- An onChange client script fires during form load unless you guard with if (isLoading || newValue === '') return.
- g_form is not available in a display business rule, and GlideRecord is not available in a client script. Mixing them up is the classic beginner error.
- Never use synchronous GlideAjax (getXMLWait) - it freezes the browser and is deprecated.
- Global scope code can quietly depend on things it does not own. Build new work in a scoped application unless you have a specific reason not to.
Automation & Orchestration
Flow Designer, workflows, SLAs, events and approvals
Automation sits above application logic and below the user experience. Where business rules react to a single database operation, this layer models a process that unfolds over hours or weeks: get an approval, create three tasks, wait for them, call an external system, notify someone, and measure the whole thing against a target. Flow Designer is the strategic tool; the older Workflow editor is still present on many instances and still runs a great deal of production.
sys_hub_flow / sys_hub_action_type_definition | Flow and action definitions. |
sys_flow_context | The execution record of every flow run - your debugging starting point. |
wf_workflow / wf_context / wf_activity | Legacy workflow definitions, running contexts and activities. |
sysapproval_approver | Every individual approval record. |
contract_sla / task_sla | SLA definitions and the running SLA attached to each task. |
sysevent / sysevent_email_action | Events and the notifications they can trigger. |
sys_decision / sys_decision_question | Decision tables and their questions. |
Flow Designer, and why it replaced Workflow
Flow Designer is a natural-language flow builder with a trigger, a sequence of actions, and reusable subflows. It matters architecturally for four reasons: it is scoped and update-set friendly, it exposes a proper execution log so you can see exactly which step failed and with what data, it is the only place IntegrationHub spokes are available, and it can be called from server script through the FlowAPI (sn_fd). Legacy Workflow has no equivalent debugging story and no spoke ecosystem.
Flows, subflows and actions
An action is the smallest reusable unit - it takes inputs, does one thing, returns outputs, and may contain a script step. A subflow is a reusable sequence of actions with its own inputs and outputs, callable from other flows and from script. A flow is the top level and is the only one with a trigger. The rule of thumb is the same as in any codebase: if you have built the same three steps twice, make it a subflow.
Triggers and the wait-for-condition trap
Record triggers fire on create, update or both, and can be told to run once or for every update. Scheduled triggers run on a timetable. Inbound email triggers act on parsed mail. The most misunderstood construct is the Wait For Condition step: the flow parks, and the platform re-evaluates the condition on a schedule. It is not instantaneous, it consumes flow contexts, and a flow with thousands of parked instances is a real operational problem. Where possible, restructure so a new trigger resumes the process instead of parking one.
Choosing between a business rule and a flow
A useful test: does the requirement complete inside one transaction, or does it unfold over time? Setting a field, validating data or copying a value is a business rule. Requesting an approval, creating tasks, waiting, calling an external API and notifying people is a flow. If it needs to be visible and adjustable by a process owner rather than a developer, that is another strong argument for a flow.
SLAs are a state machine, not a timer
An SLA definition has a start condition, a pause condition, a stop condition, a duration and a schedule. When the start condition matches, a task_sla record attaches to the task and begins accumulating time against a business schedule, pausing whenever the pause condition is true. Two things trip people up: the schedule means 4 hours can span two calendar days, and changing an SLA definition does not retro-fit running task_sla records. SLA repair exists for exactly that reason and should be used deliberately.
Approvals
Approvals are rows in sysapproval_approver pointing at a source record. They can be generated by a flow, a workflow activity, an approval rule or script. The important design choices are whether approvals are sequential or parallel, what quorum means (any one, everyone, a percentage), what happens on rejection, how delegation and out-of-office are handled, and how an approval is surfaced - portal, email with action links, mobile push, or a workspace inbox. Approval design is where most process implementations either feel effortless or feel like paperwork.
Events, notifications and the decoupling argument
gs.eventQueue puts a named event on the queue with the record and two parameters. Notifications and script actions subscribe to it. The benefit is that the transaction that caused the event does not pay for the consequences, and you can add a new consequence later without touching the original code. The cost is asynchrony: the event may be processed seconds later, and if the scheduler is backed up, minutes later.
Where Workflow Studio fits
ServiceNow has been consolidating its automation builders into a single Workflow Studio experience covering Flow Designer, Decision Builder, Process Automation Designer and the data connections that feed them. If you are learning today, learn Flow Designer concepts - triggers, actions, subflows, inputs and outputs - because those concepts carry forward regardless of which shell they are presented in.
- Do not build new automation in the legacy Workflow editor. Migrate deliberately, but build new in Flow Designer.
- sys_flow_context grows quickly. Check that flow execution retention is configured before it becomes a table-size conversation.
- A flow that calls an external system without error handling will silently strand records in an intermediate state.
- SLA pause conditions are evaluated against the task. If the state model is vague, the SLA numbers will be too.
- Recursion is real: a flow that updates a record which re-triggers the same flow is an easy accident to have.
Integration
REST, SOAP, IntegrationHub, MID Server and the ECC Queue
Very little value in ServiceNow comes from ServiceNow alone. This layer covers the inbound surfaces other systems call, the outbound mechanisms the platform uses to call others, the MID Server that reaches into private networks, and the bulk data machinery that loads records at scale. Getting it wrong shows up as duplicated records, stale CMDBs, exhausted semaphores and integrations nobody dares to touch.
ecc_queue | Every message in and out of every MID Server. The first place to look when a MID integration misbehaves. |
ecc_agent | MID Server registrations, status, version and validation state. |
sys_rest_message / sys_soap_message | Outbound REST and SOAP message definitions and their HTTP methods. |
sys_ws_definition / sys_ws_operation | Scripted REST API definitions and their resources. |
sys_data_source / sys_import_set / sys_transform_map | Data sources, import set runs and field mapping. |
sys_alias / connection alias tables | Connection and credential aliases used by flows and script. |
discovery_status | One row per Discovery run, with device counts and errors. |
Inbound: the Table API and its siblings
The Table API gives you full REST CRUD over any table you have rights to: GET /api/now/table/incident with an encoded query, POST to create, PATCH to update. The Import Set API posts into a staging table so a transform map can do the mapping - much safer for external systems whose payloads you do not control. The Attachment API handles files. The Aggregate API returns counts and sums without dragging rows. When you need a contract that does not expose your schema, build a Scripted REST API: you define the path, the methods, the request and response shape, and the underlying tables stay private. GraphQL is available where you need a single call to fetch a shaped graph of related data.
Authentication for inbound calls
Basic authentication with a dedicated integration user is the simplest and the least good. OAuth 2.0 is the standard answer, with client credentials for system-to-system and JWT bearer where an identity provider is involved. Mutual TLS is available for high-assurance integrations. Whatever you choose, the integration account should have a purpose-built role granting exactly the table operations it needs. Giving an integration the admin role is the single most common security finding in a ServiceNow audit.
Outbound: RESTMessageV2 and the alias pattern
Outbound calls are defined as REST or SOAP messages with HTTP methods, or built inline in a flow. The architectural detail that matters is Connection and Credential Aliases. Instead of hard-coding an endpoint and credentials in the message, you point at an alias, and each instance resolves that alias to its own connection record. That is what lets the same update set move from dev to test to production and hit three different endpoints with three different credentials, with no code change. Credentials themselves can be held in the platform's encrypted credential store or delegated to an external vault such as CyberArk, HashiCorp Vault or Azure Key Vault.
IntegrationHub
IntegrationHub packages third-party integrations as spokes: collections of ready-made Flow Designer actions for systems like Microsoft Teams, Slack, Active Directory, Azure, AWS, Jira, Workday and hundreds more. You drag an action into a flow, fill in inputs, and you are done. Two things to plan for: spokes are licensed in tiers and consumption is generally measured in transactions, so a chatty integration has a commercial as well as a technical cost; and a custom spoke is a legitimate thing to build when you want your own system exposed to flow builders as a supported set of actions.
The MID Server and why it exists
Your instance lives on the internet. Your servers, databases, LDAP directories and network gear do not. Rather than asking you to open inbound firewall ports to a cloud service, ServiceNow gives you the MID Server: a small Java service you install inside your own network. It makes only outbound HTTPS connections on port 443 to your instance, polling for work. The instance never initiates a connection to your network. Everything Discovery, Orchestration, LDAP integration, JDBC imports and many spokes need to reach internal systems goes through it.
The ECC Queue, in detail
Communication with a MID Server happens through the External Communication Channel queue, the ecc_queue table. When the instance wants work done it writes an output record. The MID Server polls, picks it up, runs the probe or the script, and writes the result back as an input record. A sensor then processes that input and updates the real records. This is why ecc_queue is the correct place to debug: you can see the exact payload sent, the exact payload returned, the timings and the errors. It is also why ecc_queue is a rotated table - it can grow enormously.
MID Server clusters, capabilities and sizing
MID Servers can be grouped into clusters that either load balance across members or provide failover to a standby. Capabilities describe what a MID Server can do (SSH, SNMP, PowerShell, JDBC), applications describe which product areas may use it (Discovery, Orchestration, Cloud Management), and IP ranges describe what it may reach. Together these decide which MID Server picks up a given job. Sizing is driven by concurrent work rather than device count, and separating Discovery MID Servers from integration MID Servers is a common and sensible pattern so that a large Discovery run cannot delay a business-critical integration.
Import Sets, Transform Maps and the Robust Transform Engine
Bulk loading follows a fixed shape: a Data Source defines where the data comes from (file, JDBC, REST, LDAP), rows land in a staging import set table, and a Transform Map maps staging fields to target fields. Coalesce fields decide whether a row is an insert or an update - get coalescing wrong and you will create duplicates at scale. onBefore, onAfter and onStart transform scripts let you intervene. The Robust Transform Engine is the modern execution engine for these transforms, with better performance and clearer error handling. For CMDB loads specifically, IntegrationHub ETL is the preferred tool because it plugs into the Identification and Reconciliation Engine rather than writing straight to CI tables.
Rate limits, quotas and being a good citizen
Inbound REST traffic can be governed by REST API rate limit rules, per user or per role, which return HTTP 429 when exceeded. Integration transactions typically run in their own semaphore pool so they cannot starve interactive users. On the outbound side, respect the other system's limits, make your calls idempotent so a retry cannot double-create, prefer asynchronous patterns for anything slow, and never poll every minute for something that changes daily.
- An integration user with the admin role bypasses your ACLs entirely. Build a least-privilege role instead.
- Coalesce configuration on a transform map is the difference between updating 10,000 records and creating 10,000 duplicates.
- Hard-coded endpoints and credentials in a REST message will follow your update set into production. Use aliases.
- The MID Server is a piece of infrastructure with a lifecycle: it needs patching, certificate management, monitoring and capacity planning.
- Synchronous outbound calls inside a business rule hold a semaphore while the remote system thinks about it. Put them in a flow or make them async.
Security & Access
Authentication, roles, ACLs, domains and encryption
ServiceNow security is layered and every layer is enforced on the server. Network controls decide who may reach the instance at all. Authentication establishes identity. Roles and groups describe entitlement. Access Control Lists decide, record by record and field by field, what an identified user may do. Domain separation partitions data for service providers. Encryption protects data at rest and in transit. Audit records what happened.
sys_security_acl / sys_security_acl_role | ACL definitions and the roles required by each. |
sys_user_role / sys_user_has_role / sys_group_has_role | Roles and how they reach users, directly or through groups. |
sys_user_grmember | Group membership. |
sys_properties (glide.security.*) | Instance security hardening switches. |
sys_audit / sys_audit_delete | Field-level change history and deleted record recovery. |
sysevent (login events) / sys_user_session | Authentication and session activity. |
sys_domain / domain_path | Domain records and the materialised hierarchy path. |
sys_encrypted_config / KMF tables | Encryption configuration and key management. |
The entitlement chain: user to group to role
Almost nobody should have a role assigned directly. The maintainable model is user joins group, group carries roles, roles carry more roles. Roles can contain other roles, so itil implies snc_internal and a custom role can bundle several. When a user's session starts, the platform expands the full role set once and caches it - which is why a newly granted role sometimes needs a logout to take effect. The two roles that deserve special respect are admin, which bypasses ACLs entirely, and security_admin, which is required to edit ACLs at all and must be elevated for each session.
How an ACL is actually evaluated
ACLs are checked from most specific to least specific: a rule for table.field is considered before a rule for table.*, which is considered before the wildcard *.*. For a user to be granted access, the matching rule must pass all three of its parts - the required roles, the condition, and the script - and, critically, both the field-level and the table-level rule must pass. That AND relationship is the part people get wrong: granting a field-level ACL does nothing if the table-level read is denied. Operations are read, write, create, delete and execute. Use the Security Debug session tool to see exactly which rule made the decision rather than guessing.
Row-level filtering with before-query business rules
An ACL decides whether you may see a record you have asked for. A before-query business rule changes what you are asking for, by adding a condition to every query on a table for non-privileged users - for example, restricting HR cases to the ones you are involved in. It is efficient because the filtering happens in the database. It must be written defensively, with an explicit escape for admins and for the right roles, or you will hide records from the people who need them.
Data policies as the enforcement backstop
UI policies apply on forms only. Data policies apply everywhere - forms, imports, web services and script - because they are enforced server-side. If a field must always be populated no matter how the record arrives, a data policy is the right tool, and it can optionally be surfaced as a UI policy so users get the same behaviour on the form.
Domain separation
Domain separation partitions one instance into logical tenants: managed service providers use it so each of their customers sees only their own data, and conglomerates use it for regulated subsidiaries. Every record carries sys_domain and sys_domain_path, and visibility follows the domain hierarchy - a parent domain can see its children, siblings cannot see each other. Process separation extends this so different domains get different business rules, flows and SLAs. It is powerful and it is a one-way door: enabling it on an existing instance is a major programme, and ServiceNow gates it deliberately. Decide before go-live, not after.
Encryption options and what they actually protect against
Everything is TLS-encrypted in transit as a baseline. Full database encryption protects data at rest against physical media compromise. Column Level Encryption protects specific fields so that even a privileged platform user cannot read them without the right encryption context. The Key Management Framework centralises key handling, including customer-managed keys. Choose deliberately: encryption breaks sorting, filtering and reporting on encrypted fields, so encrypting a field that the process needs to search on trades a real capability for a theoretical control.
Authentication patterns
Most enterprises federate: SAML 2.0 or OpenID Connect against an identity provider, with multi-provider SSO so employees, contractors and customers can each use a different source. LDAP integration via the MID Server keeps user and group records in sync. MFA can be enforced by the identity provider or by the platform. Adaptive Authentication adds policies based on network location and device, so an admin login from an unmanaged network can be blocked or step-up challenged. Local accounts should exist only as a documented break-glass path.
Audit, monitoring and hardening
Field auditing writes to sys_audit and drives the activity formatter. Deleted records land in sys_audit_delete and can be restored. Login and session activity is recorded. The Instance Security Center gives a scored view of hardening settings against ServiceNow's recommended baseline, and Instance Scan runs configurable checks against your configuration for security, performance and upgradability findings. In 2026 this picture extends to AI: the AI Control Tower is where AI usage, policy and risk are governed, which is now part of the security conversation rather than adjacent to it.
- The admin role bypasses ACLs. Testing your security model as an admin proves nothing - impersonate a real end user.
- Field-level ACLs do not override table-level denials. Both must pass.
- A missing ACL is a denial, not an allowance. New custom tables need explicit rules or nobody will see them.
- Granting a role to fix an access problem is almost always the wrong fix. Find the ACL that denied it first.
- Domain separation cannot be casually switched on later. Treat it as an architectural decision made before build.
Experience
Workspaces, portals, UI Builder, mobile and Virtual Agent
There is no single ServiceNow UI, and that confuses newcomers more than anything else. There is a classic administrative interface, a component-based workspace experience for agents, a portal framework for self-service, native mobile apps, and a conversational surface. They all read and write the same tables through the same ACLs and business rules - only the presentation differs.
sys_ui_page / sys_ui_form / sys_ui_list | Classic UI pages, form layouts and list layouts. |
sys_ux_page / sys_ux_screen / sys_ux_macroponent | UI Builder pages, screens and components. |
sp_page / sp_widget / sp_portal / sp_instance | Service Portal pages, widgets, portal records and widget instances. |
sc_cat_item / item_option_new / io_set | Catalog items, their variables and variable sets. |
sys_cs_topic / sys_cs_conversation | Virtual Agent topics and conversation records. |
sys_report / pa_indicators / pa_dashboards | Reports, Performance Analytics indicators and dashboards. |
sys_ui_view / sys_ui_view_rule | Form views and the rules that decide which view a user gets. |
Which front end for which audience
The rule is simple and worth stating out loud in every design workshop. Employees and customers who occasionally need something get a portal - Employee Center or a Service Portal build - or the mobile app. Agents and fulfillers who live in the tool all day get a configurable workspace, because it is optimised for handling many records with context. Administrators and developers get the classic UI, because it exposes everything. Trying to serve all three audiences with one interface is the most reliable way to satisfy none of them.
UI Builder and the component model
UI Builder is the strategic front-end tool. Pages are composed of components - a list, a form, a chart, a custom component - wired together with data resources and events rather than with page reloads. Custom components are built with the Now Experience UI Framework and the CLI, in modern JavaScript. Architecturally the shift is from server-rendered pages to a client application talking to APIs, which is why performance tuning for workspaces is about payload and data resources rather than about form layout.
Service Portal, still everywhere
Service Portal is the older but extremely widely deployed portal framework. A portal has a theme and pages; pages are made of containers, rows and columns holding widget instances; a widget has an HTML template, a client controller, a server script and CSS, all in one record. Employee Center is a packaged Service Portal experience. Two practical points: widget server scripts run with the user's rights and can be a security hole if written carelessly, and heavy widget use on a landing page is a common cause of slow first impressions.
Forms, lists and view rules in the classic UI
Form layout, related lists, formatters and list layout are all configuration records rather than code, which is why they can be changed in minutes and why they drift over time. View rules let different roles or conditions receive different form views of the same record. Related lists are the most common cause of a slow form - each one is a separate query, and a form with a dozen related lists on a busy table will feel sluggish no matter how good your code is.
Service Catalog as an experience surface
Catalog items, record producers, order guides and variables are configuration, not code. Variables are typed and can be grouped into reusable variable sets. Catalog UI Policies and Catalog Client Scripts do for catalog forms what UI Policies and Client Scripts do for platform forms. A record producer is the right tool when you want a friendly front door onto an existing table such as incident - it presents a simple form and maps the answers onto the record.
Virtual Agent and conversational design
Virtual Agent runs topics: guided conversations that gather information and take action, backed by natural language understanding to route free text to the right topic. It surfaces in the portal, in workspaces and in Microsoft Teams or Slack. The 2026 direction is that conversational entry points converge into Otto, the unified AI experience, but the underlying design skill is unchanged: know exactly which few journeys deserve a conversation, and hand off cleanly to a human when confidence is low.
Platform Analytics: reports versus Performance Analytics
A report answers 'what is true right now' by querying live data. Performance Analytics answers 'what has been happening over time' by taking scheduled snapshots into its own scoring tables, which is the only reliable way to trend metrics such as open backlog or mean time to resolve. Dashboards can hold both. Choosing PA when you need trends, and a plain report when you need a live list, avoids the classic mistake of trying to reconstruct history from current data.
- Do not build agent tooling in a portal or self-service in the classic UI. Match the surface to the audience.
- Every related list on a form is another query. Trim them before you start optimising code.
- Service Portal widget server scripts can leak data if they query without regard for the user. Use GlideRecordSecure or check rights explicitly.
- UI Builder and Service Portal are different technologies with different skills. Plan for that in your team, not at the end.
- Reports built on database views are convenient and expensive. Watch them on large tables.
AI Platform
Otto, Now Assist, AI Agents, AI Control Tower, Workflow Data Fabric
ServiceNow now positions itself as an AI platform rather than a workflow platform with AI features, and the architecture reflects that. There is a data foundation designed for AI scale, a set of generative skills embedded in the products people already use, an agentic runtime that can plan and act, and a governance layer that inventories and controls all of it. Everything still resolves down through the same tables, ACLs and flows described in the layers below, which is the point: the AI inherits the platform's permissions and audit trail rather than working around them.
sys_generative_ai_* / Now Assist skill tables | Skill configuration and usage records for generative features. |
sn_aia_* (AI Agent tables) | AI agent definitions, tools, instructions and execution records. |
sys_cs_topic / sys_cs_conversation | Conversational topics and transcripts that AI experiences build on. |
ml_capability_definition / ml_solution | Predictive Intelligence solution definitions and trained models. |
AI Control Tower inventory tables | The register of AI use cases, their owners, risk and policy status. |
ServiceNow Otto
Announced on 5 May 2026 at Knowledge 2026 in Las Vegas, Otto is ServiceNow's unified AI experience. It combines the intelligence of Now Assist, Moveworks and AI Experience into a single conversational layer that completes work across departments and systems rather than inside one application. Its four described capabilities are conversational AI, enterprise search across documents, wikis, databases and content stores, AI voice agents with multi-language conversation, and an AI Data Explorer for plain-language questions over enterprise data. Every action it takes is governed by the AI Control Tower, which logs interactions, enforces policy and provides decision transparency. It became available first with ServiceNow EmployeeWorks and AI Control Tower, with a rollout across the product set through the following year.
Now Assist and the skills model
Now Assist is generative AI delivered as skills attached to the work people already do: summarising a long incident or case, drafting resolution notes, generating knowledge articles from resolved tickets, generating code and flows for developers, and answering questions from knowledge. Skills are configurable and can be extended with the Now Assist Skill Kit, which lets you define your own prompts, inputs and grounding data. The models behind them include ServiceNow's own domain-tuned Now LLM as well as external providers where a customer prefers to bring their own.
AI Agents: the shift from assistance to action
An AI agent is defined by a role, a set of instructions, and a set of tools it may use - typically flows, subflows, script includes and integrations. Given a goal, it plans and executes rather than waiting to be told each step. AI Agent Studio is where they are built and tested, and the AI Agent Orchestrator coordinates several agents on a single outcome, deciding which agent handles which part. Architecturally the crucial detail is that agents act through existing platform artefacts: they run flows and honour ACLs, so an agent cannot do something the underlying role could not do.
AI Control Tower and why governance became a layer
Once AI can act, the important question stops being 'can it' and becomes 'should it, and who decided'. AI Control Tower is the inventory and governance plane: it registers AI use cases including third-party ones, assigns owners, applies policy, tracks risk and compliance obligations, and reports on performance and cost. ServiceNow's 2026 positioning at Knowledge leaned heavily on this - governed, autonomous work rather than ungoverned experimentation - and it is the reason AI now appears in security architecture reviews rather than only in innovation slides.
Workflow Data Fabric and zero copy
Agents and analytics need data that lives elsewhere. Workflow Data Fabric connects data across systems on one platform, including zero-copy connections to cloud data platforms so that queries can reach the data where it lives instead of shipping it into ServiceNow first. This matters architecturally because it changes the default answer to 'how do we get that data in' from 'build an integration and a staging table' to 'connect and query', with the governance and lineage handled centrally.
Predictive Intelligence: the older, still useful machine learning
Long before generative AI, ServiceNow shipped Predictive Intelligence: classification models that predict category or assignment group from short description, similarity models that find related records, clustering to spot repeated work, and regression for numeric prediction. These are trained on your own historical records, are cheap to run, are explainable, and remain the right answer for high-volume routing decisions. Do not reach for a language model when a trained classifier will do the job faster and more predictably.
Designing responsibly
The practical guardrails are unglamorous and matter more than the model choice. Keep a human in the loop for anything with irreversible consequences. Ground generative answers in your own knowledge rather than the model's memory. Give agents least-privilege roles exactly as you would an integration user. Log everything and make the logs reviewable. Measure whether the AI actually reduced handling time rather than assuming it did. And be explicit with users about when they are talking to an agent.
- AI features are licensed and metered. Model an estimate of usage before you enable a skill across an entire product line.
- An AI agent with an over-privileged role is an over-privileged integration that can also improvise.
- Generative summaries are only as good as the record. If your work notes are poor, summarisation makes that visible rather than fixing it.
- Do not replace a working Predictive Intelligence classifier with a language model just because it is newer.
- AI product naming moves quickly. Verify current names and packaging against ServiceNow's own site before you put them in a design document.
Development & Release
Instances, scopes, update sets, source control, testing, CI/CD
Because configuration lives in the database, promoting a change in ServiceNow means moving records between instances rather than deploying a build artifact. That single fact shapes the whole application lifecycle: the tooling exists to capture, review, move and test configuration records safely across a chain of instances.
sys_update_set / sys_update_xml | Update sets and the individual captured records inside them. |
sys_remote_update_set / sys_update_preview_problem | Retrieved update sets and the problems found during preview. |
sys_metadata | The parent of every table whose records are captured by update sets. |
sys_app / sys_scope | Applications and their scopes. |
sys_atf_test / sys_atf_test_suite / sys_atf_test_result | Automated tests, suites and their results. |
sn_instance_scan tables | Instance Scan checks and findings. |
sys_upgrade_history_log | Per-record results of an upgrade, including skipped changes. |
Why update sets exist and what they do not capture
Any table that extends sys_metadata is 'application file' - configuration - and its changes are captured into your current update set as sys_update_xml records. That covers business rules, client scripts, UI policies, dictionary changes, flows, ACLs, forms and much more. What it does not capture is data: no user records, no groups, no CMDB CIs, no catalog variables' actual values, no scheduled job history. It also does not capture some things people assume are configuration, which is why every experienced team keeps a written list of what must be moved by hand or by a data-load script.
Preview, skipped changes and merging
When an update set is retrieved on the target instance you preview it before committing. Preview reports problems: a record that has been changed on the target since the source captured it, a missing dependency, a deleted record. You then decide to accept the remote change or keep the local one. Skipping without understanding why is how instances quietly diverge. Update sets can be merged and batched, which helps for large releases, but merging discards history and makes rollback harder - batching is usually the safer choice.
Source control for scoped applications
Scoped applications can be linked to a Git repository. You commit from the instance, branch for parallel work, stash local changes, and apply remote changes on another instance. This gives you what update sets cannot: a real history, meaningful diffs, branch-per-feature development, and the ability for two developers to work on the same application without stepping on each other. The practical pattern on most estates is source control for scoped applications and update sets for whatever remains in global.
The Automated Test Framework
ATF runs tests inside the platform, driving real forms in a real browser session and asserting on real records. Tests are grouped into suites and can be scheduled, which is what makes upgrade regression testing feasible. Two rules keep ATF useful: never run it on production, because it creates and modifies records; and invest in tests for the paths that would hurt most if they broke, rather than trying to test everything and abandoning the effort when it becomes a chore. ServiceNow ships quick-start tests that validate baseline functionality after an upgrade, and those are the cheapest win available.
Instance Scan and upgradability
Instance Scan runs checks against your configuration and raises findings: scripts that use deprecated APIs, tables with no ACLs, business rules that query in a loop, customisations of platform records that will collide at the next upgrade. Running it as part of a definition of done, rather than as a panic before an upgrade, is what keeps technical debt visible.
CI/CD and pipelines
The sn_cicd API set lets an external pipeline - Jenkins, Azure DevOps, GitHub Actions - apply changes, install applications, run test suites, run Instance Scan and roll back. Combined with source control for scoped apps, this makes a genuine pipeline possible: commit, build, deploy to a test instance, run ATF, promote. It requires discipline about scoping and about keeping global clean, which is precisely why the two go together.
Instance strategy in practice
The minimum viable chain is dev, test, prod. Larger programmes add a UAT instance so business users are not testing on the same instance as developers, a training instance that is refreshed on its own schedule, and sometimes a dedicated integration instance so third parties are not pointing at dev. The two decisions that matter most are how often sub-production is cloned from production, and how you protect in-flight work when that clone happens. Clone weekly and nobody trusts sub-production data; clone yearly and nobody trusts the testing done on it.
Upgrades as a repeatable exercise
An upgrade is applied to a sub-production instance first. The Upgrade Monitor reports progress and the skipped-changes list shows every platform record where your customisation blocked a platform update. Each one is a decision: keep the customisation, take the new version, or merge. Teams that customise less have shorter lists and faster upgrades, which is the strongest practical argument for configuring over customising that anyone has ever made.
- Update sets do not move data. Plan foundation data, catalog data and reference data separately, every time.
- Committing an update set on production is not reversible in one click. Back-out exists but has limits - preview carefully instead.
- Two developers in the same update set will hand each other changes they did not mean to send.
- Never develop directly in production, even for 'a small fix'. That is how instances become unupgradeable.
- ATF on production will create real records. There is a property guarding it for a reason - leave it guarded.
What actually happens, step by step
The fastest way to understand an architecture is to follow one request all the way through it. These six traces each follow a different kind of request across the same stack. Colours mark which side of the wire each step happens on.
Almost every 'why did my field not get set' question is answered by knowing where in this sequence your code sits.
Explains g_scratchpad, why some data appears before scripts run, and why heavy related lists make forms slow.
Shows exactly which of your rules an API call obeys and which it never sees.
The clearest illustration of why the ECC Queue is the first place to look for any MID Server problem.
Ties the data model, automation and experience layers together in one story.
Shows that AI is a new caller of the same platform, not a new platform.
The sequence that explains most of your bugs
When someone says 'my code is not running', they usually mean 'my code is running at the wrong time'. This is the sequence for a normal form submit.
The order of execution at a glance
The same five stages run on every insert and every update, whether the record was saved by a person on a form, by an inbound REST call, by an import or by a flow.
Scroll the diagram sideways, or tap Enlarge for a bigger view
In the browser, before the save
Browser- UI policies evaluate and apply field states
- onSubmit client scripts run in Order sequence; returning false cancels the save
- Nothing here is trusted by the server
On the server, before the write
App server- Session resolved, roles expanded, semaphore acquired
- Write ACLs evaluated: field level then table level, both must pass
- Data policies enforced
- Before business rules, in Order sequence
- Before-query business rules apply only to queries, not to this write
The database write
Database- A single INSERT or UPDATE
- System fields maintained: sys_updated_on, sys_updated_by, sys_mod_count
- Audit rows written for audited fields
- Journal input stored as sys_journal_field rows
On the server, after the write
App server- After business rules, in Order sequence, still in the same transaction
- Record-triggered flows and workflows are started
- Async business rules are queued to the scheduler
- Events queued to sysevent for notifications and script actions
Back in the browser
Browser- Form re-renders or redirects
- onLoad client scripts run
- onChange scripts fire during load, hence the isLoading guard
- UI policies apply last and win over client scripts that set the same states
The part of the data model everything else depends on
The CMDB is where most ServiceNow programmes either come together or quietly fall apart. It is not a database of servers - it is the map that lets every other process know what it is talking about.
The CMDB class tree
The CMDB is not a separate product. It is the same table extension you saw in the task tree, applied to everything you own.
Scroll the diagram sideways, or tap Enlarge for a bigger view
cmdb_ci or in one of the hundreds of classes that extend it. The deeper you go, the more specific the fields become. Relationships are the exception: a relationship is not a class, it is its own record in cmdb_rel_ci holding a parent, a child and the type of dependency between them. Get the classes right and reporting works; get the relationships right and impact analysis works.The class hierarchy
cmdb is the root, cmdb_ci is the base configuration item, and everything else extends downward: cmdb_ci_hardware, cmdb_ci_computer, cmdb_ci_server, cmdb_ci_linux_server, and in parallel cmdb_ci_appl for applications, cmdb_ci_db_instance for databases, cmdb_ci_netgear for network devices. Because it uses the same table extension as everything else, a query on cmdb_ci returns every CI in the instance, each still knowing its own class through sys_class_name.
Relationships
cmdb_rel_ci holds every relationship as a parent CI, a child CI and a relationship type such as Runs on, Depends on, Hosted on or Used by. Relationships are what turn a list of assets into a dependency map, and they are what impact analysis, service maps and change collision detection all read.
The Identification and Reconciliation Engine
IRE is the gatekeeper that every well-behaved data source writes through. Identification rules define which attributes uniquely identify a CI of a given class - a serial number, a correlation ID, a fully qualified domain name - so the same server discovered by three tools becomes one CI rather than three. Reconciliation rules define which source is authoritative for which attribute, so Discovery can own the operating system version while an asset system owns the cost centre. Writing straight to CI tables with GlideRecord bypasses all of this, which is exactly how duplicate CIs are born.
CMDB health: the three Cs
Completeness asks whether required attributes are populated. Compliance asks whether records follow the rules - required relationships present, no orphans, correct classes. Correctness asks whether they are accurate, largely measured by staleness and by duplicates. The CMDB Health dashboards score these, and the honest use of them is as a trend rather than as a target: a health score that only goes up because the rules were relaxed has helped nobody.
Where the data comes from
Discovery via MID Server for on-premises infrastructure, Cloud Discovery for AWS, Azure and GCP resources, Service Graph Connectors for certified third-party sources such as endpoint management and monitoring tools, Agent Client Collector for agent-based visibility, and IntegrationHub ETL for bespoke loads. Each should be registered as a data source with its own reconciliation precedence.
Service Mapping
Discovery tells you what exists. Service Mapping tells you what those things add up to. Top-down mapping starts at an entry point such as a URL and follows traffic and configuration to build the map of an application service. Tag-based mapping uses cloud tags. Traffic-based mapping observes connections. The output is an application service CI with a mapped dependency tree, which is what makes impact analysis and service-aware incident management possible.
The Common Service Data Model (CSDM)
CSDM - the Common Service Data Model - is ServiceNow's prescribed way of organising service data so that ITSM, ITOM, ITAM, SPM, SecOps and CSM all mean the same thing by the same words. It is a standard, not a product you install.
The five CSDM domains, left to right
Scroll the diagram sideways, or tap Enlarge for a bigger view
Twelve arguments you will have, settled
Architecture is mostly choosing between two reasonable options. These are the choices that come up on nearly every ServiceNow project, with the rule of thumb that usually decides them.
Business rule or Flow Designer?
Business rule
- The logic completes inside one transaction
- You are setting or validating a field on the current record
- It must run for every write including API calls
- Milliseconds matter
Flow
- The process unfolds over hours or days
- There are approvals, tasks or waits
- You need to call an external system
- A process owner should be able to read and adjust it
Client script or UI policy?
UI policy
- Making a field mandatory, visible or read-only
- The condition can be expressed in the condition builder
- You want it to reverse itself automatically
- You want it readable by the next person
Client script
- You need to set a value, not just a state
- You need to call the server with GlideAjax
- The logic genuinely exceeds a condition
Client-side or server-side validation?
Server-side
- The rule must always hold
- Records also arrive by import or API
- There is a compliance or data-integrity reason
Client-side
- You want instant feedback while typing
- It is a convenience, and the server also enforces it
Extend an existing table or create a new one?
Extend task
- Someone is assigned it and must complete it
- You want SLAs, approvals and workspace behaviour for free
- It genuinely is a kind of work item
New table
- It is reference or configuration data
- Nobody works it as a task
- It has no meaningful relationship to the task lifecycle
Global scope or a scoped application?
Scoped application
- Any new application you are building
- You want a namespace and an explicit boundary
- You want source control and CI/CD
- You may distribute or reuse it
Global
- You are modifying baseline global configuration
- A platform feature genuinely requires it
Update sets or source control?
Source control
- The work is a scoped application
- More than one developer touches it
- You want branches, diffs and history
- You want a CI/CD pipeline
Update sets
- The change is in global scope
- It is a small, isolated configuration change
- Your estate has no Git integration yet
MID Server or a direct REST call?
MID Server
- The target is inside a private network
- No inbound firewall rule is available or desirable
- You need SSH, WMI, PowerShell, SNMP or JDBC
- It is Discovery, Orchestration or LDAP
Direct REST
- The target is internet-reachable and speaks HTTPS
- The other side can authenticate you
- Latency matters and there is no network barrier
Table API or a Scripted REST API?
Scripted REST API
- You want a stable contract that hides your schema
- The caller needs data from several tables in one call
- You need custom validation, shaping or error handling
- A third party is integrating and should not learn your data model
Table API
- Internal, trusted caller
- Simple CRUD on one table
- Speed of delivery matters more than the contract
Import set or write directly with the API?
Import set
- Bulk loads
- The payload shape is outside your control
- You need staging, mapping, coalescing and an error trail
- It is going into the CMDB - then use IntegrationHub ETL
Direct API write
- Single record events
- Real-time, low latency
- You fully control both ends
Report or Performance Analytics?
Report
- What is true right now
- A live list someone will act on
- Ad hoc questions
Performance Analytics
- Trends over weeks and months
- Targets, thresholds and forecasts
- Any question containing the word 'improving'
Now Assist skill or a Predictive Intelligence model?
Predictive Intelligence
- High-volume classification or routing
- You need it explainable and cheap
- You have plenty of historical records to train on
Now Assist
- Generating or summarising language
- Open-ended questions
- Drafting content a human will review
AI agent or a flow?
Flow
- The steps are known and repeatable
- The process must be identical every time
- Auditors will ask exactly what happened
AI agent
- The path varies with the request
- Judgement is needed between steps
- You want it to handle the long tail a flow cannot enumerate
Fourteen mistakes that create technical debt
Every one of these looks reasonable at the moment somebody does it. Each entry explains why it hurts later and what to do instead.
Giving the integration user the admin role
Why it hurtsadmin bypasses every ACL. The integration can now read and write anything, and your entire access model is decorative for that account.
Do this insteadCreate a purpose-built role granting only the table operations that integration needs, and test it by impersonating the integration user.
Querying inside a loop
Why it hurtsA GlideRecord query inside a while loop over another GlideRecord turns one query into thousands. It is the single most common cause of slow business rules and stalled scheduled jobs.
Do this insteadQuery once with an encoded query or an IN condition, use GlideAggregate for counts, and build a lookup object in memory.
Enforcing rules only in client scripts
Why it hurtsAnyone with a browser console, and every API call and import, ignores them completely.
Do this insteadPut the rule in a before business rule or a data policy. Keep the client script as well if you want the friendly message.
Extending incident to make a near-copy
Why it hurtsYou inherit every future change ServiceNow makes to incident, your reporting fragments, and your upgrade skipped-changes list grows every release.
Do this insteadUse the existing table with categorisation, or build a proper scoped application on task.
Writing to CMDB tables directly
Why it hurtsYou bypass the Identification and Reconciliation Engine, which is the only thing preventing duplicate CIs and source conflicts.
Do this insteadLoad through IntegrationHub ETL, a Service Graph Connector, or the Identification Engine API.
Building everything in global scope
Why it hurtsNo namespace, no boundary, no source control story, and cross-application coupling that nobody can safely unpick later.
Do this insteadCreate a scoped application for every new build, and declare its table access explicitly.
Developing directly in production
Why it hurtsThere is no preview, no test, no rollback and no record of intent. It is how instances become unupgradeable.
Do this insteadDev, test, prod. Even for the small fix. Especially for the small fix.
Treating async business rules as instant
Why it hurtsThey queue on the scheduler. Under load they can run seconds or minutes later, so anything the user expects to see immediately will appear to have failed.
Do this insteadUse a before or after rule for anything synchronous, and reserve async for genuinely deferrable work.
Hard-coding endpoints and credentials
Why it hurtsThey travel with the update set into production and hit the wrong system with the wrong credentials.
Do this insteadConnection and credential aliases, resolved per instance.
Skipping update set previews
Why it hurtsSkipped changes are silent divergence. Six months later dev and production behave differently and nobody knows why.
Do this insteadReview every preview problem, decide deliberately, and record the decision.
Piling related lists onto a form
Why it hurtsEach related list is another query on every single form load, on every record, for every user.
Do this insteadKeep the two or three that people actually use, and move the rest to a related-links page or a workspace tab.
Ignoring foundation data
Why it hurtsAssignment, approval routing, entitlement, cost allocation and reporting all read users, groups, locations and companies. Bad foundation data breaks all of them at once.
Do this insteadName a source of truth for each foundation entity before build, and integrate it properly.
Enabling every AI feature at once
Why it hurtsAI capabilities are metered and licensed, and an unmeasured rollout produces cost surprises and unproven value in the same quarter.
Do this insteadPick two use cases with a measurable baseline, register them in AI Control Tower, and expand from evidence.
No automated regression tests before an upgrade
Why it hurtsEvery family release will touch something you customised. Manual regression testing does not scale and is quietly skipped under time pressure.
Do this insteadRun the ServiceNow quick-start tests plus ATF suites for your critical paths, on a sub-production instance, before every upgrade.
Every term on this page, defined
Search it, or filter by the layer a term belongs to.
Practice challenge
2 questionsQ1What do application nodes share?
The database
Nodes share the database, everything else is local to the node.
Q2Where is high availability handled?
By ServiceNow at datacenter level
Datacenter failover is part of the service.
Frequently asked questions
Is ServiceNow multi-tenant or multi-instance?
What is inside a ServiceNow instance?
What is Advanced High Availability?
What database does ServiceNow use?
What is a sys_id?
What is the difference between client-side and server-side?
What is the order of execution when a record is saved?
Why does ServiceNow need a MID Server?
What is the ECC Queue?
How do ACLs actually work?
What is CSDM?
What is the difference between update sets and source control?
What is ServiceNow Otto?
Do AI agents bypass ServiceNow security?
How often does ServiceNow release, and what is the current sequence?
Why is my instance slow?
Want this taught live, with job support?
ServiceNow Training is delivered live by working practitioners, with certification prep and placement support.
See ServiceNow Training →