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.
Document control
| 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
1. Scope, drivers and principles
| 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
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] |
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
| 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
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
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
| 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
| 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
| 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
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
| 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
| 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
| 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
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
| 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
| 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
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.