Service Order Management (SOM)
Last updated 14 Oct 2026
At a glance
Service Order Management (SOM) turns commercial intent into service-level work. COM says what the customer bought; SOM decides which Customer-Facing Services (CFS) must be created, changed or ceased, plans the work and sees it through. It is where commercial language becomes technical language.
The picture
TMF622
TMF641 Reception
TMF633
TMF652 POST
TMF638 update
TMF652
How it works
Where SOM sits
SOM sits on the boundary between BSS (products, prices, customers) and OSS (network, resources, activation). In TM Forum’s ODA it is the Service Order Management function in the Service Management domain. It works at the CFS and RFS layers and is the system of record for the Service Order.
It is not a pass-through between COM and ROM. It keeps its own state, resolves dependencies and handles exceptions.
What SOM is responsible for
| Responsibility | What it means |
|---|---|
| Reception | Accept service orders from COM over TMF641 and validate them against the service catalog |
| Decomposition | Turn CFS order items into RFS order items using catalog rules |
| Orchestration | Plan what runs in parallel, what waits, and what depends on what |
| Delegation | Send resource work to ROM over TMF652 |
| State | Track every item and roll the result up into one order state for COM |
| Exceptions | Retry, compensate, escalate or route to a manual queue |
| Service inventory | Create or update service instances (TMF638) when work completes |
From product order to service order
When COM has validated and approved an order, it maps each Product Order Item to one or more Service Order Items using the product-to-CFS mapping in the catalog, and submits them to SOM as one Service Order.
COM reads the catalog
COMWhich CFS specifications the ordered Product Specification needs, which are mandatory or optional, and which characteristics flow down.
COM builds the service order
COMOne Service Order Item per CFS: the CFS specification, the action (add, modify, delete), characteristic values and a reference back to the product order item.
COM submits it
TMF641POST /serviceOrder. SOM validates it against the service catalog, assigns an ID and acknowledges. The product order moves to inProgress.
SOM takes ownership
SOMSOM plans and runs the work. COM follows progress through TMF641 events but does not control execution.
What a CFS order item says
A CFS order item describes a customer-visible change: the CFS specification, the action, its characteristics, the customer and the place, and its dependencies on other items in the same order (orderItemRelationship). It is technology-neutral. "Internet-Access at 200 Mbps" says nothing about GPON, HFC or fixed wireless; that choice is made when SOM decomposes it, and it can differ by address.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Service Order | SOM | — | COM | TMF641. COM tracks it against the product order that created it. |
| Product Order | COM | — | SOM | TMF622. SOM keeps only the reference back to it. |
| CFS specification and decomposition rules | Service Catalog | — | SOM | TMF633. Read at runtime, not copied into SOM. |
| Service instance (CFS / RFS) | Service Inventory | SOM | — | TMF638. SOM creates and updates it as work completes. |
In practice
Some estates have no SOM. COM sends orders straight to ROM or to activation, or service logic lives inside COM or the integration middleware. It looks like one system fewer. What actually disappears is the service layer.
What goes when SOM is bypassed
| Capability | Without SOM |
|---|---|
| CFS/RFS decomposition | COM has to know the full technical breakdown, so commercial and technical concerns merge |
| Service inventory | No record of active services; assurance cannot link a fault to a customer service |
| Technology choice | Made in COM or the channel, which ties commercial systems to network technology |
| Modify and cease | No current service state to diff against, so changes become full re-provisioning |
The trade-off
What it solves
It separates what was sold from how it is delivered. COM deals in products, ROM in resources, and SOM owns the translation, the plan and the service state in between.
What it does not solve
- A poor service catalog. SOM decomposes only as well as the CFS and RFS model allows.
- Inventory accuracy below it. SOM plans against what inventory says exists.
- Commercial order capture. Validation, pricing and customer approval stay in COM.
What it adds
- Another order layer with its own state machine, events and fallout queue.
- A second decomposition (CFS to RFS) to model, test and govern.
- Order state now spans COM, SOM and ROM, and has to be kept consistent.
Architecture decision
Does this estate need a separate SOM, or can COM drive fulfilment directly?
Separate SOM
Choose when more than one access technology or network domain, modify and cease orders matter, or assurance needs service-to-customer correlation.
COM drives fulfilment directly
Choose when a single product family on a single technology, mostly new connections, with an accepted plan to add SOM before the second technology arrives.
Breaks if COM sends orders straight to ROM or activation. The service layer and its inventory never exist, and every later product inherits COM’s technical shortcuts.
Takeaways
Key Takeaways
- SOM translates commercial intent into service-level work and owns the Service Order
- It works at the CFS and RFS layers, between COM (TMF641 in) and ROM (TMF652 out)
- COM maps product order items to CFS order items from the catalog; SOM takes it from there
- CFS order items are technology-neutral; the technology choice is made in decomposition
Check yourself
COM has submitted a service order. What can COM still do with it, and what can it not?Show answerHide
It can follow progress through TMF641 events and request a cancellation. It does not control execution: SOM owns the plan, the dependencies and the item states.
Why does a CFS order item not say GPON or HFC?Show answerHide
Because the CFS is what the customer sees. The access technology depends on the address and is chosen when SOM decomposes the CFS into RFS, so the product and commercial layers stay independent of technology.
A support agent can see a customer’s product but not which network resources deliver it. What is missing?Show answerHide
The service layer: SOM and the service inventory it maintains, which link the product above to the resources below.