ServiceNow
Start here (plain)
Section titled “Start here (plain)”Many companies keep their day-to-day technology inventory in ServiceNow (often called a CMDB — a database of configuration items). 7lens keeps a shared company picture with clear meanings.
This guide helps you connect the two so you do not invent a second, conflicting company vocabulary inside ServiceNow.
You do not need to be a ServiceNow expert to read the opening sections. The detailed tables later are for people who configure CMDB/CSDM classes and load jobs.
Related 7lens reading: Mapping strategy, Data Model, Applications.
Who this is for
Section titled “Who this is for”| If you are… | This guide helps you… |
|---|---|
| A CMDB / CSDM owner | Choose ServiceNow classes and relationships that keep ServiceNow’s meaning intact |
| An integration engineer | Design extract → transform → load using verified 7lens APIs and ServiceNow-native load paths |
| An application / service owner | See ownership and identity rules that should not be duplicated wrongly |
| An architect | Keep 7lens as the shared meanings; treat ServiceNow as a mapped collaborator |
Purpose: a maintainable, evidence-based integration — not a claim that 7lens “is” CSDM, and not a ServiceNow certification.
How to read the statements below
Section titled “How to read the statements below”| Kind of statement | Meaning in everyday words |
|---|---|
| ServiceNow documented | What ServiceNow’s own docs / CSDM 5 white paper say (cited). |
| 7lens recommendation | How we suggest projecting 7lens into ServiceNow for this integration. Not a ServiceNow product rule. |
| Unresolved / customer decision | Your company must choose; this guide does not invent the answer. |
ServiceNow citation basis: CSDM 5 guidance and ServiceNow Docs pages checked in this research pass (CSDM-to-CMDB mapping page updated 10 September 2026). Confirm against your instance family (for example Yokohama / Xanadu / Washington DC) before go-live.
CSDM is ServiceNow’s Common Service Data Model — their recommended way to structure CMDB data. You will see that acronym in the tables.
What 7lens brings (and what it does not)
Section titled “What 7lens brings (and what it does not)”In plain words first:
- 7lens covers four core parts: who/where (Organization), shared labels (Groups), technology capabilities (Technology), and business applications (Business, including Applications).
- A full Inventory of discovered machines/assets in 7lens is an optional add-on and is not implemented in the current product API. Do not invent Asset sync APIs here.
- Catalogue / definition ideas from CSDM can be mapped conceptually; runtime CMDB items such as Service Instance (CSDM 5 name for Application Service) stay on the ServiceNow side unless your company decides otherwise — OSM treats them as EXTERNAL.
Evidence legend (Coverage column)
Section titled “Evidence legend (Coverage column)”When you read the tables, the Coverage column means:
| Coverage | Plain meaning |
|---|---|
| Recommended | Preferred approach for most customers |
| Partial | Useful join or locator; not a full meaning match |
| Investigate | Candidate; confirm against your CSDM adoption |
| Not mapped | Out of scope or no safe projection yet |
| External | Belongs in ServiceNow (or another system), not forced into 7lens core |
7lens → ServiceNow mapping table
Section titled “7lens → ServiceNow mapping table”The tables below are precise on purpose. Skim the plain opener above first, then use these rows when you configure.
Columns: 7lens concept | ServiceNow concept | Recommended mapping | Additional fields / config | Integration considerations | Coverage | Evidence
Business and Applications
Section titled “Business and Applications”| 7lens concept | ServiceNow concept | Recommended mapping | Additional fields / config | Integration considerations | Coverage | Evidence |
|---|---|---|---|---|---|---|
| Business Domain (recursive) | Business Capability / Capability hierarchy (CSDM design domain) or customer taxonomy | Prefer mapping Domains to capability / portfolio taxonomy the customer already uses in SPM / EA; do not invent a Domain CI class | Customer capability table / SPM taxonomy node if used | Domains are recursive; CSDM capability levels are constrained (CSDM 5 white paper: max hierarchy depth rules). Confirm grain before load. | Investigate | CSDM 5 white paper (Business Capability); 7lens Domain semantics in 7lens-data-model.md |
| Domain → Legal Entity | Company / Business Unit / Department as used for ownership | Map ownership through Domain’s Legal Entity; do not invent a separate Domain owner CI | sys_id of company/dept as external key |
Ownership in 7lens flows Domain → Legal Entity → Organization | Partial | 7lens ownership rules; SN org tables vary by customer |
| Application | Business Application (cmdb_ci_business_app) |
Map each 7lens Application to one Business Application CI | Store 7lens Application id as an external / source attribute (customer chooses field); store SN sys_id back in 7lens only if a customer extension key is agreed |
SN documented: Business Application data belongs in cmdb_ci_business_app, not cmdb_ci_app. Logical design object, not a runtime instance. |
Recommended | CSDM → CMDB mapping (updated 2026-09-10); CSDM 5 white paper |
Application domainId |
Relationship / reference from Business Application to capability / business context | Preserve Domain membership as relationship or reference the customer’s CSDM practice allows | Avoid overloading legacy singular Business Process reference (CSDM 5: considered legacy) | Prefer one-to-many capable links | Partial | CSDM 5 white paper (Business Application ↔ Business Process note) |
Application consumes[].service |
Business Application → Technology Management Service / Service Offering (via relationships), not “consumes Offering” as a 7lens fact | Project consumes as links from BA to the SN classes that represent the mapped Service/Offering |
Relationship type is a customer decision within CSDM-allowed types | 7lens Applications consume Services, not Offerings. Do not invent Application→Offering consumes. |
Recommended | 7lens Applications model; OSM CSDM PARTIAL note |
Application part_of |
Business Application ↔ Business Application design-level relationship | Map to BA–BA relationship only when both ends are BAs; enforce same-Legal-Entity rule in transform | Relationship type: customer decision (design-level connect) | 7lens: at most one parent; acyclic; same Legal Entity | Partial | 7lens part_of rules |
Application depends_on |
BA–BA dependency relationship | Map consumer → dependency; may cross Legal Entity | Distinct from part_of |
Do not infer composition from dependency | Partial | 7lens depends_on rules |
| Application Deployment / Entry Points (target model) | Service Instance / Application Service operational layer (cmdb_ci_service_auto family) |
Do not collapse logical Application into Service Instance. If Deployments exist in 7lens, treat operational projection as SN Service Instance — customer decision until Deployments are production-complete | CSDM 5: Application Service renamed Service Instance; BA↔AS/SI uses Uses::Used By in CSDM v5 (earlier: Consumes::Consumed By). EA Workspace may still need Consumes::Consumed by for TPM/TRM timelines. | Inventory/Discovery must not silently author 7lens Deployments | Investigate | SN CI relationships docs; OSM: Service Instance EXTERNAL |
accountable_person |
Owned by / Managed by / Support group style fields on BA | Map to the customer’s CSDM ownership fields; optional in 7lens | Person/sys_user resolution is customer IdP-specific |
Do not invent a Person entity in 7lens core | Partial | 7lens Application accountability; SN CI ownership fields |
sourcing_model / delivery_model |
Architecture type / install type style attributes on BA (customer field set) | Map only where SN attributes exist with matching meaning; otherwise Group or custom attribute on SN | Do not silently backfill from legacy application_type |
Independent dimensions in 7lens target model | Investigate | 7lens Section 10 sourcing/delivery; SN attribute availability varies |
Technology
Section titled “Technology”| 7lens concept | ServiceNow concept | Recommended mapping | Additional fields / config | Integration considerations | Coverage | Evidence |
|---|---|---|---|---|---|---|
| Technology Stack | Portfolio / taxonomy / technical domain grouping (SPM taxonomy or custom) | Use as classification context; not a mandatory CMDB CI | Group framework locators (TBM/TOGAF) may land as attributes | Stacks are recursive operational competency domains | Investigate | 7lens Technology model; SN SPM taxonomy docs |
| Technology Service | Technology Management Service (CSDM 5; was Technical Service) | Map OSM/7lens Service → Technology Management Service as closest catalogue/management landing | Optional OSM/servicenow_csdm parameter csdm_service_class as locator |
OSM status PARTIAL — 7lens Service is definition grain, not runtime CI | Recommended | OSM CSDM.md; framework catalogue servicenow_csdm |
| Technology Offering | Technology Management Service Offering | Map Offering → Technology Management Service Offering conceptually | OSM uses Characteristics / providers rather than CSDM dimension tables | Partial semantic match | Partial | OSM CSDM.md |
| Platform (in-house) | Platform host / platform app architecture types on Business Application or Technology Management constructs | Prefer: Platform remains Technology; Applications consume Services the Platform offers. If SN uses BA architecture type platform host / platform app, treat as SN modeling choice, not a 7lens Platform rewrite |
New York+ architecture type choices on BA (CSDM white paper) | Do not model Platform as Application in 7lens | Investigate | CSDM 5 white paper (architecture type); 7lens Platform ≠ Application |
| ICT Provider | Company / Vendor CI or Technology Provider concept | Map to company/vendor master data; link from Service/Offering via provider association | sys_id external key |
OSM ICT Provider is catalog master data, not necessarily a CMDB company CI | Partial | OSM CSDM.md; 7lens ICT Provider |
Framework selection servicenow_csdm in Groups |
N/A (7lens control plane) | Activate once in Groups when using 7lens as platform; Technology/Business inherit | Parameters: csdm_service_class, cmdb_ci_class (join keys) |
Framework selection records intent, not certification | Recommended | @7lens/contracts osm-frameworks.ts, framework-catalogue.ts |
Organization, geo, Groups
Section titled “Organization, geo, Groups”| 7lens concept | ServiceNow concept | Recommended mapping | Additional fields / config | Integration considerations | Coverage | Evidence |
|---|---|---|---|---|---|---|
| Organization / Region / Sub-region / Country / Legal Entity | Location hierarchy (cmn_location types) + Company |
Map geo to location types (Region, Country, …) where useful; Legal Entity → Company | CSDM 5 location type choices | Commercial overlays (EMEA/APAC) are not 7lens geo levels | Partial | CSDM 5 location attributes; 7lens Organization model |
| Groups (classification dimensions) | Tags, dynamic CI attributes, SPM taxonomy, Teams related list, custom fields | Prefer representing Group values as classifications in SN; do not recreate Group meta-model inside CMDB | Teams related list for group-type associations on CIs (CSDM 5) | Groups establish strategic ownership/access in 7lens; SN RBAC is separate | Investigate | 7lens Groups; CSDM 5 Teams |
Dependencies, consumption, inventory boundary
Section titled “Dependencies, consumption, inventory boundary”| 7lens concept | ServiceNow concept | Recommended mapping | Additional fields / config | Integration considerations | Coverage | Evidence |
|---|---|---|---|---|---|---|
Canonical consumes[].service |
Relationships among BA, Technology Management Service / Offering | Authoritative technology dependency is 7lens consumes |
— | Inventory evidence (when it exists later) must not replace consumes |
Recommended | 7lens Applications model |
| Inventory Asset | CMDB CI / Service Instance | Not mapped in this iteration — Inventory extension not implemented in 7lens API | — | SN Discovery/Service Mapping remain SN-side. Do not invent Asset sync. | Not mapped | Product README: Inventory not built; OSM CI EXTERNAL |
| Service → Service graph (generic) | CSDM service relationship graph | Not forced into 7lens Technology catalog | — | OSM-C-008: Service→Service relationships EXTERNAL to OSM | External | OSM CSDM.md |
Practical integration approach
Section titled “Practical integration approach”Plain plan: agree what maps to what, agree who owns which field, extract from 7lens, load with ServiceNow’s own import tools, then check the list below.
Prefer ServiceNow-native load paths over inventing a proprietary connector.
1. Assess the ServiceNow estate
Section titled “1. Assess the ServiceNow estate”Document which CSDM version and domains are adopted (Foundation / Design / Manage / Consume), which classes are authoritative, and whether APM / SPM / Discovery / Service Mapping are in use.
2. Review and freeze the mapping
Section titled “2. Review and freeze the mapping”Start from the table above. Record customer decisions (relationship types, external-key fields, Domain→capability grain). Mark Coverage = Investigate items as Accepted / Deferred.
3. Identity and ownership contract
Section titled “3. Identity and ownership contract”Define for each entity type:
- Natural key in 7lens (stable
id) - Correlation key in ServiceNow (
sys_idand/or unique name + class) - System of record per field (7lens vs ServiceNow)
- Conflict policy (7lens wins / SN wins / manual)
4. Configure the ServiceNow target
Section titled “4. Configure the ServiceNow target”Create or confirm target classes, identification rules (IRE), transform maps, and relationship types. Use CSDM-aligned tables (cmdb_ci_business_app, Technology Management Service / Offering classes as adopted).
5. Connect to verified 7lens API capabilities
Section titled “5. Connect to verified 7lens API capabilities”Verified read/write configuration surface (no invented endpoints):
| Capability | Route family (verified in @7lens/api) |
|---|---|
| Full configuration document | GET/PUT /v1/config |
| Axis documents / trees | GET /v1/config/organization, /technology, /business (+ /tree) |
| Entity CRUD under axes | GET/POST/PUT/DELETE /v1/config/... collections |
| Graph read-back | GET /v1/config/graph |
| YAML export/import | GET/PUT /v1/config/yaml |
| Validation | GET /v1/config/validation |
| Group resolutions | GET /v1/config/group-resolutions/:entityType/:entityId |
| Application schema | GET /v1/schemas/applications |
| Health | GET /v1/health |
Auth gap (explicit): API authentication is pending. x-source-id on ingest is unverified (claimed_source_id). Do not treat the API as production-safe for multi-tenant exposure until auth is implemented (product README / API README).
Not available: published Inventory Asset APIs; a first-party “7lens ServiceNow connector” product; guaranteed bidirectional sync semantics.
6. Map and transform
Section titled “6. Map and transform”Transform 7lens JSON/YAML into Import Set / IntegrationHub ETL payloads. Preserve provenance (7lens id, extract timestamp, mapping version).
7. Load into ServiceNow (prefer native options)
Section titled “7. Load into ServiceNow (prefer native options)”Evaluate in this order (all are ServiceNow platform capabilities, not 7lens products):
- Service Graph Connector / IntegrationHub ETL — if a suitable pattern exists or a custom IH ETL map is acceptable (SGC Central, Integration Commons for CMDB).
- Import Sets — CSV/XML/Excel into staging → transform to CMDB; relationships via
cmdb_rel_ci(Populating the CMDB). - CMDB Instance API — programmatic CI create/update when ETL is not suitable (same SN docs family).
- Custom connector — only if 1–3 cannot meet latency/security requirements; treat as customer-owned engineering, not a documented 7lens product.
Use IRE for identification/reconciliation on load.
8. Validate
Section titled “8. Validate”Run the checklist below before declaring the integration complete.
9. Operate
Section titled “9. Operate”Schedule extracts, monitor failed transforms, version the mapping table, and re-validate after CSDM or 7lens model changes.
“Complete integration” validation checklist
Section titled ““Complete integration” validation checklist”Use this like a packing list before you call the work done. An integration is complete for a scoped entity set only when all applicable items pass:
Identity and classes
Section titled “Identity and classes”- Every in-scope 7lens Application has exactly one Business Application in
cmdb_ci_business_app(or an explicit exception list). - No Applications were written to
cmdb_ci_appby mistake. - Correlation keys (7lens id ↔
sys_id) are stored and reversible. - Technology Services map to Technology Management Service (or documented deviation).
Semantics
Section titled “Semantics”-
consumes[].serviceprojections match 7lens (Services only; no invented Offering targets). -
part_of/depends_onare not conflated; Legal Entity rules enforced in transform. - Platforms were not rewritten as Applications unless a documented exception exists.
- Service Instance / Application Service layer is either out of scope or explicitly mapped from Deployments — not silently equated to logical Application.
Ownership and Groups
Section titled “Ownership and Groups”- Ownership fields in SN align with Domain → Legal Entity resolution (or documented override).
- Group classifications have a defined SN landing (or are deferred).
Operational safety
Section titled “Operational safety”- Auth posture for 7lens API access is accepted by security (gap acknowledged if still pending).
- IRE identification rules prevent duplicate CIs on re-load.
- Conflict policy tested with a controlled dual-edit scenario.
- No Inventory/Asset sync was assumed or built against non-existent 7lens Inventory APIs.
Evidence
Section titled “Evidence”- Mapping table version pinned in the runbook.
- Citations for SN classes/relationships recorded for the instance release.
Maintainability
Section titled “Maintainability”| Topic | Practice |
|---|---|
| Citations | Keep SN Docs URLs + date; pin CSDM 5 white paper version used in workshops |
| Native vs config vs extension | Label each field: SN OOB / SN configured / SN custom / 7lens core / 7lens customer extension |
| Model changes | Re-run checklist when 7lens Application v3 Deployments land or CSDM renames apply |
| Unresolved items | Track in the customer decision log; do not silently “fix” Coverage = Investigate rows |
Explicit gaps (this iteration)
Section titled “Explicit gaps (this iteration)”- 7lens Inventory extension and Asset APIs — not built; CMDB CI sync from 7lens Assets is out of scope.
- 7lens API authentication — pending; production exposure blocked until resolved.
- No first-party 7lens↔ServiceNow connector is shipped; use SN-native import/ETL paths.
- Domain ↔ Business Capability grain is customer-specific (Investigate).
- Deployment ↔ Service Instance projection depends on Application Deployment implementation status.
- Product strategy mentions (for example NIS2, Apptio) that are not in the OSM / Groups framework catalogue are not given pages here.
Sources
Section titled “Sources”7lens / OSM
docs/product/7lens-data-model.md,7lens-data-model-business.md,7lens-product-definition.md@7lens/contractsosm-frameworks.ts(servicenow_csdm),framework-catalogue.ts- OSM
models/service-management/CSDM.md(CSDM 5, status PARTIAL) @7lens/apiroute surface; rootREADME.md/packages/api/README.md(auth/Inventory gaps)
ServiceNow (official / vendor)
- How CSDM concepts map to CMDB tables (updated 2026-09-10)
- CSDM 5 white paper (ServiceNow community / product guidance)
- CI relationships in the CSDM (Uses::Used By for BA↔Application Service / Service Instance)
- Populating the CMDB (Import Sets, IntegrationHub ETL, CMDB Instance API, Service Graph Connectors)
- Exploring SGC Central