SLM–CMDB Integration
Last updated 14 Oct 2026
At a glance
The ITSM CMDB knows assets; SLM and the service and resource inventories know subscriptions and services. Neither alone can say which customers depend on a failed or changing asset. Linking them, usually through resource inventory, gives one chain from configuration item to customer that incidents and changes can query in either direction.
The picture
BSS/OSS: what was sold and built
SLM / product inventory
Subscription, product instance, SLA terms · TMF637
Service inventory
CFS and RFS instances · TMF638
Resource inventory
Resources and topology · TMF639
Identifier on both sides
TMF639 events, or batch reconciliation
ITSM: what is operated
Incidents and changes
Who is affected? Who is exposed?
CMDB configuration item
Model, location, firmware, change history
“Every subscription on this router”
- CMDB CI
- Resource
- RFS
- CFS
- Product instance + SLA
- Customer
Either direction needs every link present and in step.
How it works
What each side knows
A Configuration Management Database (CMDB) is an ITIL practice, usually inside an ITSM platform such as ServiceNow or BMC Helix. It records configuration items (CIs): routers, switches, virtual machines, licences, circuits, SIM cards, anything that can fail, change or has a lifecycle, with attributes such as model, location and firmware, and relationships between them. It does not track what customers bought.
| Question | SLM and inventories | CMDB | Linked |
|---|---|---|---|
| What did the customer buy? | Product instance, SLA terms, subscription state | Not known | Subscription linked to the CIs beneath it |
| What delivers it? | CFS/RFS decomposition and topology | Asset identity, model, location, firmware | Service topology with real asset identity |
| Who is affected if this CI fails? | Customer-to-service mapping, but perhaps not the failed asset | The failed asset, but no customer context | CI → services → subscriptions → customers, with SLA exposure |
| What is the risk of changing this asset? | Commercial value and SLA commitments | Change history and CI dependencies | Technical dependency and commercial exposure together |
How the link is made
- Fulfilment populates the inventories. SOM writes CFS and RFS instances to service inventory, ROM writes resource records to resource inventory, and SLM records the active subscription with its product structure and SLA terms.
- Resource inventory synchronises to the CMDB. Resource records are created as CIs or matched to existing ones, and each side stores the other’s identifier. This can be event-driven (TMF639 notifications) or batch reconciliation.
- The chain is complete. CI → resource → RFS → CFS → product instance → customer and account. Queries can walk it either way.
- Incidents use it. When monitoring detects a CI fault, the incident workflow can ask which resources, services and subscriptions are affected, and calculate SLA exposure in seconds rather than hours.
- Changes use it. Before planned work on a CI, the change board sees which subscriptions are exposed and their SLA commitments, and can make an informed go or no-go decision.
A worked case: one PE router line card
| Step | Not linked | Linked |
|---|---|---|
| Detection | Alarms against a hostname | Alarms enriched with CI details and linked RFS instances |
| Impact | Spreadsheets and CRM searched by hand, often for an hour or more | Affected enterprise subscriptions and sites listed automatically, with SLA tiers |
| Priority | All faults equal | Higher SLA tiers escalated, breach time estimated |
| Communication | Customers call in; agents check manually | Affected customers notified; agents see the incident against the subscription |
| Resolution | Ticket closed; SLM and CRM unchanged | CI restored, resource, service and subscription status confirmed, customer notified |
| Afterwards | No link from the event to commercial impact | SLA performance measured, credits calculated, trend data to capacity planning |
Queries run from either end: “every subscription on this router” starts at the CMDB and walks up; “every CI behind this customer” starts at SLM and walks down. Both need the chain intact and synchronised.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Configuration items (assets, attributes, CI relationships) | CMDB (ITSM platform) | — | Resource inventory | Asset identity, location, firmware, maintenance windows, change history |
| Network resources and topology | Resource inventory | — | CMDB, fault management | TMF639. Overlaps with CMDB CIs; which side masters which attribute must be agreed per estate. |
| CFS and RFS instances | Service inventory | — | CMDB (as business or technical services, where modelled) | TMF638 |
| Subscriptions / product instances and SLA terms | SLM / product inventory | — | ITSM platform | TMF637 |
| CI-to-resource identifier link | Integration between resource inventory and CMDB | — | — | Held on both records; neither is useful without the other being current |
| Incidents and change records | ITSM platform | — | SLM, service inventory | — |
In practice
Telcos commonly have three places answering “which service does this belong to”: service inventory, resource inventory and the CMDB. They diverge unless one is clearly the master for each attribute and the others reference it (19.3).
Because the ITSM platform is often the most mature system in the estate, some organisations try to extend the CMDB to hold subscriptions and service decomposition as well. It can look simpler, but the CMDB is not built around catalog-driven product and service models, order lifecycles or TMF semantics, and it then competes with the inventories that fulfilment writes. Keeping them complementary, with clear ownership boundaries, avoids two diverging copies of the same service model.
Synchronisation is the operational burden. Batch reconciliation is simpler to build but leaves windows where the chain is wrong; event-driven sync is closer to real time but needs reliable notifications from resource inventory and a defined way to handle failures.
The trade-off
What it solves
Linking the CMDB to SLM and the inventories gives one queryable chain from asset to customer, so incidents and changes can be assessed in commercial and SLA terms.
What it does not solve
- It does not decide which system masters overlapping attributes; that has to be agreed.
- It does not correct either side’s data; it links whatever each holds, including errors.
- It does not cover services provisioned without resource inventory records.
What it adds
- An identifier-matching and synchronisation integration that has to be monitored and reconciled.
- Ownership rules for attributes held in both resource inventory and the CMDB.
- Two upgrade paths, the ITSM platform’s and the inventory’s, that the integration must survive.
Architecture decision
Keep resource inventory and the CMDB in step by events or by batch reconciliation?
Event-driven (TMF639 notifications)
Choose when Resource inventory emits reliable change events and incident triage needs current links
Batch reconciliation
Choose when Change volume is low, events are unreliable or unavailable, and some lag in the chain is acceptable
Breaks if Event-driven sync has no reconciliation behind it, so lost events leave silent gaps; or batch runs so rarely that incidents are triaged against last week’s network.
Takeaways
Key Takeaways
- The CMDB knows assets; SLM and the inventories know subscriptions and services. Linking them gives the chain from asset to customer.
- Resource inventory is usually the bridge, with each side holding the other’s identifier.
- The linked chain serves both incidents (who is affected) and changes (who is exposed).
- Keep the CMDB and the BSS/OSS inventories complementary, with clear ownership per attribute.
Check yourself
A change board wants to know which enterprise customers are exposed by a planned router upgrade. Which records must be linked to answer that?Show answerHide
The router’s CI in the CMDB, its resource record in resource inventory, the RFS and CFS instances in service inventory, and the product instances and SLA terms in SLM.
Why not simply hold subscriptions and service decomposition in the CMDB, since the ITSM platform is already mature?Show answerHide
The CMDB is not built around catalog-driven product and service models or order lifecycles, and fulfilment already writes those to SLM and the inventories. A second copy diverges; linking the two avoids that.