# ServiceNow Platform Design: [Organisation or instance name]

> Platform design for a ServiceNow implementation: instance strategy, product and process scope,
> adoption of the Common Service Data Model (CSDM 5, white paper published May 2025, seven domains),
> CMDB design and the Identification and Reconciliation Engine, Discovery, Service Mapping and MID
> Server topology, integrations (Integration Hub, REST APIs, Service Graph Connectors, Instance Data
> Replication), customisation policy and scoped applications, family release and upgrade strategy,
> security and access control, data governance, AI governance, operating model and roadmap. Replace
> every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one design per ServiceNow estate (production instance plus its sub-production instances).
  Process designs for each product (incident, change, HR case) go in their own documents.
- Settle the instance strategy (section 2) and the CSDM adoption plan (section 4) first: every
  product depends on the service and CI data they define.
- Keep the customisation policy (section 8) strict and enforce it in review. Most upgrade pain comes
  from modified out-of-box records rather than from new scoped applications.
- Check release names, patch targets and support windows against the ServiceNow release notes and
  the release cycle article before every upgrade decision.
- Related documents: ISO/IEC 20000 service catalogue (`compliance/iso-20000-service-catalog`),
  Integration design (`architecture/integration-design`), Data migration strategy
  (`architecture/data-migration-strategy`), Cutover plan (`project/cutover-plan`), Fit-gap analysis
  (`architecture/fit-gap-analysis`), Change request (`ops/change-request`), Business capability map
  (`architecture/business-capability-map`), Salesforce solution design
  (`architecture/salesforce-solution-design`) where cases flow between platforms.
-->

## Document control

<!-- Guidance: Identify the instances, the products licensed and the current family release. A change to instance strategy, the CSDM model or the customisation policy is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [SNOW-PD-001] |
| Production instance | [instance-name].service-now.com |
| Sub-production instances | [dev, test, uat] |
| Hosting | [ServiceNow cloud region / dedicated or regulated offering] |
| Current family release and patch | [Release name, patch number] |
| Products licensed | [ITSM, ITOM, SecOps, SPM, HRSD, CSM, ServiceNow Otto (formerly Now Assist)] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@platform-owner] |
| Approvers/reviewers | [@platform-architect], [@cmdb-manager], [@security-architect], [@itsm-process-owner], [@enterprise-architect] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Platform owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Enterprise architecture | [@name] | [Decision] | YYYY-MM-DD |
| Information security | [@name] | [Decision] | YYYY-MM-DD |
| Service management process owner | [@name] | [Decision] | YYYY-MM-DD |
| CMDB manager | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* CSDM walk stage added; MID Server clusters per data centre |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by the platform design authority |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope, drivers and principles](#1-scope-drivers-and-principles)
2. [Instance strategy](#2-instance-strategy)
3. [Product and process scope](#3-product-and-process-scope)
4. [CSDM 5 adoption](#4-csdm-5-adoption)
5. [CMDB design](#5-cmdb-design)
6. [Discovery, Service Mapping and MID Servers](#6-discovery-service-mapping-and-mid-servers)
7. [Integrations](#7-integrations)
8. [Customisation policy and scoped applications](#8-customisation-policy-and-scoped-applications)
9. [Release and upgrade strategy](#9-release-and-upgrade-strategy)
10. [Security and access control](#10-security-and-access-control)
11. [Data governance and CMDB health](#11-data-governance-and-cmdb-health)
12. [Testing, performance and instance health](#12-testing-performance-and-instance-health)
13. [AI and agent governance](#13-ai-and-agent-governance)
14. [Operating model](#14-operating-model)
15. [Roadmap, decisions and risks](#15-roadmap-decisions-and-risks)
16. [Glossary and references](#16-glossary-and-references)

## 1. Scope, drivers and principles

<!-- Guidance: State the outcomes the platform serves and the principles that settle design disputes. Questions: which teams consume the platform? Which legacy tools does it replace? Pitfall: principles that allow every team to configure the platform its own way. -->

| ID | Driver | Measurable outcome | Owner |
|---|---|---|---|
| DRV-001 *(Example)* | Change failures caused by unknown dependencies | Change-related major incidents reduced by 50 % in a year | @change-manager |
| DRV-002 *(Example)* | Three service desks with separate tools | One service portal and one incident process | @service-desk-lead |
| DRV-003 *(Example)* | No trusted inventory for vulnerability response | 95 % of servers in CMDB with an owner and support group | @cmdb-manager |
| [DRV-NNN] | [Driver] | [Outcome] | [@owner] |

| ID | Principle | Consequence |
|---|---|---|
| SNP-001 *(Example)* | Adopt out of box; configure before customise; never modify base records without design authority approval | Every customisation request is logged and reviewed (section 8) |
| SNP-002 *(Example)* | CSDM is the service and CI data model for every product | No custom service tables; deviations recorded as decisions |
| SNP-003 *(Example)* | Every CI has a data source, an owner and a support group | Manual CIs only for classes no tool can discover |
| SNP-004 *(Example)* | New capabilities are built as scoped applications | Global scope changes need a recorded reason |
| SNP-005 *(Example)* | Stay within the supported release window | Upgrade at least once a year (section 9) |
| [SNP-NNN] | [Principle] | [Consequence] |

## 2. Instance strategy

<!-- Guidance: Decide the number of production instances and the sub-production path. Questions: do residency, regulated data or separate legal entities need separate production instances? How many parallel development streams exist? Pitfall: several production instances for organisational reasons, followed by years of cross-instance integration. -->

### 2.1 Production instance decision

| Criterion | Single production instance | Multiple production instances |
|---|---|---|
| Shared services and shared CMDB | Natural fit | Requires replication or federation |
| Data residency or regulated separation | Addressed through domain separation or data controls, if sufficient | Hard separation |
| Licence and operating cost | Lower | Higher (instances, integrations, admins) |
| Release independence | One upgrade calendar | Independent calendars |
| Reporting across the estate | Native | Needs replication or a data platform |
| *Example decision* | Chosen: one production instance for the group | Rejected: residency met by hosting region and access controls |

### 2.2 Instance landscape

| Instance | Purpose | Clone source and cadence | Data | Access |
|---|---|---|---|---|
| DEV *(Example)* | Build of scoped applications and configuration | Cloned from PROD quarterly, with data preserved for development records | Masked | Developers, admins |
| TEST *(Example)* | Integration and ATF regression | Cloned from PROD before each release | Masked | Testers, developers |
| UAT *(Example)* | Acceptance, upgrade rehearsal, training | Cloned from PROD before each upgrade | Masked where needed | Business testers |
| PROD | Live | n/a | Live | All users |
| [Instance] | [Purpose] | [Clone] | [Data] | [Access] |

```mermaid
flowchart LR
    DEV[DEV: build] -->|Application repository or source control| TEST[TEST: ATF and integration]
    TEST --> UAT[UAT: acceptance and upgrade rehearsal]
    UAT -->|Approved change| PROD[PROD]
    PROD -. clone with exclusions .-> UAT
    PROD -. clone with exclusions .-> TEST
```

Define clone exclusions and preservers so that credentials, integration endpoints, email settings and
MID Server records in sub-production never point at production systems after a clone.

## 3. Product and process scope

<!-- Guidance: List the products, the processes each delivers and the release in which they go live. Pitfall: buying products in bulk and switching them on before the data they depend on exists. -->

| Product area | Processes or capabilities | Release | CSDM stage needed | Owner |
|---|---|---|---|---|
| ITSM *(Example)* | Incident, problem, change, request, knowledge, service catalogue | 1 | Crawl | @itsm-process-owner |
| ITOM *(Example)* | Discovery, Service Mapping, event management, Service Graph Connectors | 1 and 2 | Walk | @itom-lead |
| SecOps *(Example)* | Vulnerability response, security incident response | 2 | Walk | @security-operations-lead |
| SPM *(Example)* | Demand, project and portfolio management | 2 | Run | @pmo-lead |
| Enterprise architecture *(Example)* | Business application and capability portfolio | 3 | Fly | @enterprise-architect |
| HRSD or CSM *(Example)* | HR cases or customer cases | [Release] | Run | [@owner] |
| [Product] | [Processes] | [Release] | [Stage] | [@owner] |

Process designs should align with the organisation's service management system; where it follows
ISO/IEC 20000-1, link services and offerings to the catalogue in ISO/IEC 20000 service catalogue
(`compliance/iso-20000-service-catalog`).

## 4. CSDM 5 adoption

<!-- Guidance: Map the CSDM 5 domains to the products and plan the stages. Questions: which tables must be populated before each product goes live? Who owns each domain's data? Pitfall: trying to populate the whole model at once instead of staging it. -->

### 4.1 Domains

The CSDM 5 white paper (ServiceNow, May 2025) organises the model into seven domains. The table maps
each domain to its owner and the products in this programme that depend on it. Table names are given
only as examples; check the current white paper and your instance's data model.

| Domain | Typical content (examples) | Data owner | Dependent products |
|---|---|---|---|
| Foundation | Company, business unit, department, location, groups, users, product models, contracts, CMDB groups, life cycle values | @foundation-data-owner | All |
| Ideation & Strategy | Product ideas, planning items, strategic priorities, goals, targets | @strategy-office | SPM |
| Design & Planning | Business capabilities, business applications, information objects | @enterprise-architect | Enterprise architecture, SPM, ITSM |
| Build & Integration | DevOps change data, SDLC components, AI system digital assets | @engineering-lead | DevOps change, ITSM |
| Service Delivery | Service instances, application services, applications, infrastructure CIs, technology management services and offerings, dynamic CI groups | @cmdb-manager | ITSM, ITOM, SecOps |
| Service Consumption | Business services, business service offerings, request catalogue | @service-owner-lead | ITSM, CSM, HRSD |
| Manage Portfolio | Portfolios, service portfolio | @portfolio-manager | SPM |

### 4.2 Staged adoption

CSDM guidance recommends staging the model in five steps: Foundation, Crawl, Walk, Run and Fly. Fill
the table with this programme's dates and the evidence that each stage is complete.

| Stage | Focus in this programme | Entry condition | Exit evidence | Target date |
|---|---|---|---|---|
| Foundation | Referential data: companies, locations, groups, users, product models | HR and location feeds agreed | 98 % of users with company, department and location *(Example)* | YYYY-MM-DD |
| Crawl | Business applications, application services, discovered applications and hosts | Foundation complete | Every production application service linked to a business application | YYYY-MM-DD |
| Walk | Technology management services and offerings, dynamic CI groups | Support groups defined | Support and change approval groups derived from offerings for 90 % of CIs | YYYY-MM-DD |
| Run | Business services, business service offerings, service portfolio | Service owners named | Incidents and changes show impacted business service offering | YYYY-MM-DD |
| Fly | Business capabilities, information objects, catalogue links to offerings | EA practice engaged | Capability-to-application mapping complete for tier 1 applications | YYYY-MM-DD |

Record migration from older CSDM versions (for example, application services recorded where CSDM 5
now expects service instance classes) as a backlog with owners, not as a one-off clean-up.

## 5. CMDB design

<!-- Guidance: Define the classes in scope, identification rules, data sources and precedence. Questions: which source wins when two tools report the same attribute? Pitfall: custom CI classes created for reporting convenience. -->

### 5.1 Classes and sources

| CI class (example) | In scope from | Primary source | Secondary sources | Identification rule | Owner |
|---|---|---|---|---|---|
| Windows and Linux servers *(Example)* | Release 1 | Discovery | Cloud Service Graph Connector, endpoint management | Serial number, then name plus domain | @server-lead |
| Cloud resources *(Example)* | Release 1 | Service Graph Connector for the cloud provider | Discovery via cloud APIs | Provider object ID | @cloud-lead |
| Network devices *(Example)* | Release 2 | Discovery | Network management tool | Serial number | @network-lead |
| Application services *(Example)* | Release 1 | Service Mapping and manual service modelling | n/a | Name plus environment | Service owners |
| Business applications *(Example)* | Release 1 | Manual, governed | EA tool import | Name, unique number | @enterprise-architect |
| [Class] | [Release] | [Source] | [Sources] | [Rule] | [@owner] |

### 5.2 Identification and reconciliation

Every import, discovery and connector must write through the Identification and Reconciliation Engine
so that duplicates are prevented and authoritative sources win. Define reconciliation rules per class
and attribute, data refresh rules for stale sources, and a de-duplication process for the duplicates
that still appear.

| Class | Attribute | Authoritative source | Fallback | Staleness rule |
|---|---|---|---|---|
| Server *(Example)* | Operating system version | Discovery | Endpoint management | Discovery data older than 14 days loses priority |
| Server *(Example)* | Assigned support group | Technology management service offering (CSDM walk stage) | Manual | Not applicable |
| [Class] | [Attribute] | [Source] | [Fallback] | [Rule] |

### 5.3 Life cycle

Use the CSDM life cycle stage and stage status fields consistently on every CI class, and map them to
the asset and change processes. Define which stage and status combinations allow incidents, changes
and retirement.

## 6. Discovery, Service Mapping and MID Servers

<!-- Guidance: Design the discovery coverage and the MID Server topology. Questions: which networks can each MID Server reach? Where are credentials stored? Pitfall: one MID Server for the whole estate, with firewall rules opened from it to everything. -->

| MID Server cluster | Location or network zone | Purpose | Servers | Capabilities | Credential store |
|---|---|---|---|---|---|
| MID-DC1 *(Example)* | Data centre 1, server zone | Discovery, Service Mapping, orchestration | 2 (load balanced) | Windows, Linux, SNMP | External vault integration |
| MID-DC2 *(Example)* | Data centre 2, server zone | Discovery, Service Mapping | 2 | Windows, Linux | External vault integration |
| MID-CLOUD *(Example)* | Cloud hub network | Cloud discovery, Integration Hub spokes needing private reach | 2 | Cloud APIs, REST | Instance credential store with restricted roles |
| MID-DMZ *(Example)* | Perimeter zone | Discovery of perimeter devices only | 1 | SNMP | External vault integration |
| [Cluster] | [Zone] | [Purpose] | [n] | [Capabilities] | [Store] |

| Item | Decision |
|---|---|
| Discovery schedules | [Per range and zone, outside backup windows; daily for servers, weekly for network] |
| Coverage target | [Percentage of known IP ranges and cloud accounts discovered] |
| Service Mapping approach | [Top-down from entry points for tier 1 services; tag-based for cloud-native services] |
| MID Server hosting | [Hardened hosts, patching owner, upgrade with each family release] |
| Network rules | [Ports opened per zone, documented and reviewed] |
| Credential policy | [Least-privilege service accounts, rotation, vault integration] |

## 7. Integrations

<!-- Guidance: List integrations, their pattern and their owner. Questions: which integrations need a MID Server for private reach? Which data moves between instances? Pitfall: custom scripted integrations where a supported spoke or connector exists. -->

| Pattern | ServiceNow capability | Use for |
|---|---|---|
| Outbound actions to other systems | Integration Hub spokes and flows in Workflow Studio | Creating tickets, users or records in other tools |
| Inbound APIs | Table API, Scripted REST APIs, Import Set API | Monitoring tools, other service desks |
| CMDB population from third-party tools | Service Graph Connectors | Cloud, endpoint and security tools |
| Bulk import | Import sets with transform maps writing through IRE | One-off and scheduled loads |
| Instance to instance | Instance Data Replication | Sharing records between ServiceNow instances |
| Events from monitoring | Event management connectors | Alerts and correlation |
| Email and chat | Inbound email actions, virtual agent and messaging channels | User contact |

| ID | Source | Target | Pattern | Frequency | Volume per day | MID Server | Error handling | Owner |
|---|---|---|---|---|---|---|---|---|
| INT-001 *(Example)* | HR system | ServiceNow users and departments | Import set via REST, transform map | Hourly | 2,000 | No | Import log review, alert on failure | @identity-lead |
| INT-002 *(Example)* | ServiceNow change | Deployment pipeline | Integration Hub spoke | On approval | 300 | No | Flow error handling, retry | @devops-lead |
| INT-003 *(Example)* | Monitoring tool | ServiceNow events | Event connector | Continuous | 200,000 events | Yes (MID-DC1) | Event queue monitoring | @itom-lead |
| INT-004 *(Example)* | Cloud provider | CMDB | Service Graph Connector | Every 4 hours | 50,000 CIs | No | Connector run log, IRE errors | @cloud-lead |
| [INT-NNN] | [Source] | [Target] | [Pattern] | [Frequency] | [Volume] | [MID] | [Handling] | [@owner] |

Specify each interface in Integration design (`architecture/integration-design`); confirm the spoke
and connector entitlements in your subscription before design sign-off.

## 8. Customisation policy and scoped applications

<!-- Guidance: Define what may change, how and by whom, and how technical debt is measured. Pitfall: modified out-of-box business rules and script includes, which turn every upgrade into a merge exercise. -->

| Change type | Allowed | Approval | Notes |
|---|---|---|---|
| Configuration of out-of-box options and properties | Yes | Product owner | Recorded in update sets or application repository |
| New fields on out-of-box tables | Limited | Design authority | Check CSDM and existing fields first |
| Modification of out-of-box scripts, UI policies, ACLs | Exception only | Design authority with upgrade impact note | Logged as technical debt |
| New scoped applications | Yes | Design authority | Built in App Engine Studio or Studio; naming and scope prefix rules |
| Global scope custom code | Exception only | Design authority | Reason and exit plan recorded |
| Custom tables | Yes, in scoped applications | Design authority | Licence impact checked (custom table entitlements) |
| Store and partner applications | Yes | Design authority and security | Vendor support and release compatibility checked |

| Item | Decision |
|---|---|
| Source control | [Application repository / Git integration for scoped applications] |
| Update set policy | [Naming, owner, one update set per story, batch for release, preview errors resolved before commit] |
| Code review | [Peer review, Instance Scan checks run before promotion] |
| Technical debt measure | [Count of modified out-of-box records and skipped records per upgrade; target trend down] |
| Naming conventions | [Prefixes for tables, script includes, flows, groups] |

## 9. Release and upgrade strategy

<!-- Guidance: Plan upgrades so the platform stays supported and gains new features with controlled risk. Questions: which family release will production run in 12 months? Who signs off skipped records? Pitfall: skipping upgrades until the instance falls out of support and a forced upgrade arrives. -->

ServiceNow names its family releases alphabetically after cities and ships them on a roughly six-monthly
cycle. In October 2026 Zurich and Australia receive patches (check whether Yokohama is still inside
its patch window), and Brazil has been in early availability since 24 September 2026 (per
ServiceNow community; check the available versions page). Check the current release notes and the
release cycle article (KB0547244) for general availability dates, support windows and patch targets
before planning.

| Item | Decision |
|---|---|
| Upgrade frequency | [Every family release / once a year, never falling outside the supported window] |
| Patch policy | [Apply patches within [n] weeks of release after regression test] |
| Upgrade path | DEV, then TEST, then UAT, then PROD, with ATF regression at each step |
| Skipped records review | [Owner per application; decisions to revert to base or keep customisation recorded] |
| Freeze periods | [Business peak periods with no upgrades] |
| Communication | [Release notes summary for process owners, user communication for visible changes] |

| Step | Activity | Owner | Duration *(Example)* |
|---|---|---|---|
| 1 | Review release notes and plan features to adopt | Platform architect | 2 weeks |
| 2 | Upgrade DEV, resolve skipped records | Developers | 1 week |
| 3 | Upgrade TEST, run ATF suite and integration tests | Test lead | 1 week |
| 4 | Upgrade UAT, business testing and training updates | Process owners | 2 weeks |
| 5 | Upgrade PROD in the agreed window, post-upgrade checks | Platform owner | 1 day |

## 10. Security and access control

<!-- Guidance: Describe identity, roles, access control rules and data protection. Pitfall: broad admin role assignments kept after implementation. -->

| Area | Decision |
|---|---|
| Authentication | Single sign-on with the corporate identity provider (SAML or OpenID Connect), MFA enforced |
| Provisioning | Users and groups from the HR or identity system (INT-001); deprovisioning within [n] hours |
| Roles | Role model by persona; admin and security admin roles held by named individuals with elevation |
| Access control rules | Out-of-box ACLs kept; custom ACLs only in scoped applications, reviewed by security |
| Data separation | [Domain separation for managed service provider or legal separation / not used] |
| Encryption | [Platform encryption options, column level encryption for sensitive fields, key management] |
| Instance security hardening | Instance Security Center and hardening settings reviewed each release |
| Logging and audit | [System logs, audit history retention, export to SIEM] |
| Privacy | Personal data fields classified; retention and deletion rules; DPIA (`compliance/dpia`) where needed |

Review role assignments quarterly using Access review (`ops/access-review`).

## 11. Data governance and CMDB health

<!-- Guidance: Define the measures of data quality and who acts on them. Pitfall: health dashboards that nobody owns, so scores fall and the CMDB loses trust. -->

| Measure | Definition | Target *(Example)* | Owner | Review cadence |
|---|---|---|---|---|
| Completeness | Required attributes populated for in-scope classes | 95 % | Class owners | Monthly |
| Correctness | Records passing audit rules against the authoritative source | 90 % | CMDB manager | Monthly |
| Compliance | CIs meeting CSDM relationship rules (for example, application service linked to a business application) | 90 % | CMDB manager | Monthly |
| Duplicates | Duplicate CIs open in the de-duplication queue | Below 0.5 % of CIs | CMDB manager | Weekly |
| Staleness | CIs not updated by any source within the class threshold | Below 5 % | Class owners | Weekly |
| Orphans | CIs without owner or support group | Below 2 % | Class owners | Monthly |

Use the CMDB health dashboards and data manager policies (attestation, archive, retirement) to act on
the measures, and report the trend to the platform design authority.

## 12. Testing, performance and instance health

<!-- Guidance: Define automated regression, performance checks and ongoing instance health practices. Pitfall: an ATF suite built for go-live and never maintained, so upgrades are tested by hand. -->

| Item | Decision |
|---|---|
| Automated Test Framework | Regression suite covering critical journeys per product; run on every upgrade and release |
| Integration tests | Each INT-NNN tested in TEST with a stub or partner test system |
| Performance checks | Transaction response times on key forms and lists; slow query and slow script logs reviewed weekly |
| Instance Scan | Checks for best practice and upgradeability run before each promotion |
| Data volume management | Table rotation and archive rules for large tables such as events, logs and audit |
| Health review | [Monthly platform health review with ServiceNow account team or partner] |

| ID | Scenario | Target *(Example)* | Method |
|---|---|---|---|
| PRF-001 | Open incident form for agents | Under 2 s server response | Transaction logs |
| PRF-002 | Discovery of 10,000 servers | Completes within its window | Discovery status and schedule history |
| PRF-003 | Service portal home page | Under 3 s for 95 % of users | Browser timing |
| [PRF-NNN] | [Scenario] | [Target] | [Method] |

## 13. AI and agent governance

<!-- Guidance: Scope generative AI and agent features, their data and their oversight. Pitfall: enabling AI skills platform-wide without defining which data they may read or which actions they may take. -->

ServiceNow's generative AI is now branded ServiceNow Otto (formerly Now Assist). ServiceNow announced
Otto on 5 May 2026 as one AI experience that brings together Now Assist, Moveworks and AI Experience,
and store applications renamed their in-product labels from August 2026; contracts and older
documentation may still use the Now Assist name, so record both names in the licence register.

| ID | Capability | Product area | Data accessed | Actions allowed | Human oversight | Measure |
|---|---|---|---|---|---|---|
| AI-001 *(Example)* | Incident summarisation | ITSM | Incident, work notes | Draft summary only | Agent reviews before posting | Summary accepted rate above 80 % |
| AI-002 *(Example)* | Agent that triages and routes requests | Service catalogue | Catalogue, user profile | Set category and assignment group | Low-confidence items routed to triage group | Reassignment rate below 10 % |
| [AI-NNN] | [Capability] | [Area] | [Data] | [Actions] | [Oversight] | [Measure] |

For every AI capability, record the roles that can use it, data that is excluded from prompts, the
evaluation before go-live and the monitoring afterwards. The CSDM 5 white paper adds AI-related classes
(AI system digital assets, AI functions and AI applications) so that AI systems can be inventoried and
related to services: populate them for each AI capability in this table. Detailed agent specifications
belong in AI agent specification (`ai-data/ai-agent-spec`).

## 14. Operating model

<!-- Guidance: Show who owns the platform, who builds on it and how demand is prioritised. Pitfall: a platform team that only administers, with no product ownership or design authority. -->

| Role | Responsibilities | Named |
|---|---|---|
| Platform owner | Budget, roadmap, licence management, vendor relationship | [@name] |
| Platform architect | Design authority chair, standards, upgrade planning | [@name] |
| Product owners (per product area) | Backlog, process alignment, acceptance | [@names] |
| CMDB manager | CSDM adoption, data quality, reconciliation rules | [@name] |
| Developers and administrators | Build, configuration, support | [Team] |
| Process owners | Process design and performance for incident, change and request | [@names] |

| Activity | Platform owner | Platform architect | Product owner | CMDB manager | Process owner |
|---|---|---|---|---|---|
| Approve customisation exceptions | A | R | C | C | C |
| Plan upgrades | A | R | C | I | I |
| Prioritise backlog | A | C | R | C | C |
| Maintain CSDM data | I | C | C | A | R |
| Approve process changes | I | C | C | I | A |

## 15. Roadmap, decisions and risks

<!-- Guidance: Connect the CSDM stages, product releases and upgrades into one roadmap, and keep the decision and risk logs. Pitfall: product go-lives scheduled before the CSDM stage they depend on. -->

| Quarter | Platform release | CSDM stage | Products | Upgrade |
|---|---|---|---|---|
| [Q1 YYYY] *(Example)* | Release 1 | Foundation and Crawl | ITSM core | Current family release |
| [Q2 YYYY] *(Example)* | Release 1.1 | Walk | Discovery, Service Graph Connectors | Patch |
| [Q3 YYYY] *(Example)* | Release 2 | Walk | SecOps, Service Mapping tier 1 | Next family release |
| [Q4 YYYY] *(Example)* | Release 3 | Run | SPM, business service offerings | Patch |
| [Quarter] | [Release] | [Stage] | [Products] | [Upgrade] |

| ID | Decision | Options | Reason | Date | Approver |
|---|---|---|---|---|---|
| DEC-001 *(Example)* | Single production instance | Single, one per region | Shared CMDB and services; residency met by region | YYYY-MM-DD | Design authority |
| DEC-002 *(Example)* | Service Graph Connector for cloud CIs | Connector, Discovery only | Supported, faster coverage | YYYY-MM-DD | Design authority |
| [DEC-NNN] | [Decision] | [Options] | [Reason] | YYYY-MM-DD | [Approver] |

| ID | Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| RSK-001 *(Example)* | Duplicate CIs from overlapping sources reduce trust in the CMDB | Medium | High | IRE rules per class, de-duplication queue, health measures | @cmdb-manager |
| RSK-002 *(Example)* | Customised base records delay upgrades | High | Medium | Customisation policy, skipped records review, debt trend | @platform-architect |
| RSK-003 *(Example)* | MID Server compromise gives network reach | Low | High | Hardened hosts, zone-specific clusters, vault credentials | @security-architect |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |

| Requirement ID | Design element | Build item | Test | Status |
|---|---|---|---|---|
| REQ-ITSM-004 *(Example)* | CSDM run stage, business service offerings | Story SN-120 | ATF-CHG-07 impacted service shown on change | Designed |
| REQ-ITOM-011 *(Example)* | INT-004 cloud connector | Story SN-210 | TC-CMDB-03 IRE identification | Built |
| [Requirement] | [Element] | [Item] | [Test] | [Status] |

## 16. Glossary and references

<!-- Guidance: Define the ServiceNow terms used and list the sources checked, with the date. -->

### 16.1 Glossary

| Term | Meaning |
|---|---|
| CSDM | Common Service Data Model: ServiceNow guidance for modelling services and CIs |
| CMDB | Configuration management database |
| IRE | Identification and Reconciliation Engine, which matches incoming CI data and applies source precedence |
| MID Server | Java application installed on customer hosts that lets the instance reach private networks |
| Service Graph Connector | Supported integration that loads third-party data into the CMDB through IRE |
| Scoped application | Application isolated in its own namespace with controlled access to other scopes |
| Family release | A named major ServiceNow platform release |
| Skipped record | A customised record that an upgrade did not overwrite and that needs review |
| ATF | Automated Test Framework |

### 16.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| CSDM 5 white paper, ServiceNow community (Scott Lemm, Rob Koeten) | Published May 2025, checked 2026-10-23 | Domains, adoption stages, AI classes |
| ServiceNow community announcement "CSDM 5: get the white paper" | 6 May 2025, updated 16 June 2025 | Release date |
| ServiceNow release notes, available versions | Checked 2026-10-23 | Section 9 release names and status |
| ServiceNow release cycle article KB0547244 | Not readable without sign-in; check before use | Support policy |
| ServiceNow press release, "ServiceNow Otto creates the unified AI experience for the enterprise", newsroom.servicenow.com | 5 May 2026 | Otto naming, section 13 |
| ServiceNow Store release notes, ITSM AI applications (rename to ServiceNow Otto) | August 2026, checked 2026-10-23 | In-product rename |

## Standard and licence note

Structure aligned with the ServiceNow Common Service Data Model (CSDM 5 white paper, May 2025) and
ServiceNow platform documentation for CMDB, Discovery, MID Server, integrations and family releases. Only
domain names, stage names, product names and release names are used; all explanations, criteria and
examples are original text written for this collection and do not reproduce the white paper. Check the
current CSDM version and ServiceNow release notes before use. ServiceNow, CSDM, ServiceNow Otto and
related product names are trademarks of their owners; this template is not affiliated with or endorsed by them.
Template licence: MIT.