SOM in Operation: Failures, Inventory & Integration
Last updated 12 Oct 2026
At a glance
In operation, SOM spends much of its effort on orders that do not go to plan. It retries, compensates, escalates and routes fallout to people, keeps service inventory in step with what was actually done, and talks to half a dozen systems over TM Forum APIs and events.
The picture
B2B Fixed L3VPN — New Activation
Interactive BPMN 2.0 workflow demonstrating the end-to-end fulfilment process for a fixed L3VPN enterprise service — from order capture through validation, design, provisioning, activation, and closure. Toggle to AI-Augmented mode to see how AI overlays each step with decision intelligence, automated design, risk prediction, and failure prevention.
Standard L3VPN activation where customer site has existing fibre access. No supplier dependency.
Click any element in the diagram to see details
How it works
When orders fail
In fulfilment, failure is routine: elements are unreachable, resources run out, appointments are missed, partners are late. SOM’s responses:
- Retry transient failures with exponential backoff, up to a limit.
- Manual task: when automation cannot resolve it, create a work item for operations.
- Compensate: undo completed steps when a later one fails, for example release a VLAN when QoS cannot be applied.
- Escalate items held or failed beyond their jeopardy threshold.
- Report partial completion to COM, which decides whether to accept or roll back.
Keeping service inventory true
Service inventory (TMF638) is the record of active service instances. SOM reads it before a modify or cease to find the delta, may create a reserved instance when the order is acknowledged, updates it as items complete, marks it active when the CFS is done, and terminated when a cease completes.
Who SOM talks to
| System | Direction | API / pattern | Purpose |
|---|---|---|---|
| COM | In | TMF641 POST /serviceOrder | Receive service orders |
| COM | Out (events) | TMF641 events | Report order and item state changes |
| Service Catalog | Out (query) | TMF633 | CFS/RFS specifications and decomposition rules |
| Service Inventory | Out (query, update) | TMF638 | Current state before; new state after |
| ROM | Out / in (events) | TMF652 | Resource orders and their outcomes |
| Workforce Management | Out | TMF646 or custom | Field appointments |
| Partners | Out | TMF641 or B2B API | Work delegated to third parties, such as last-mile installation |
COM follows progress by subscribing to TMF641 events (ServiceOrderStateChangeEvent, ServiceOrderItemStateChangeEvent and others) through the TM Forum hub/listener pattern, so it never has to poll.
Process-driven or rule-driven
A process-driven SOM runs a designed workflow per service type: explicit and auditable, but every new service type is a new workflow. A rule-driven SOM generates the plan from catalog rules and dependencies: new types are catalog changes, but paths are harder to predict and test. Most estates are hybrid.
Many SOMs execute their workflows on a BPMN 2.0 engine. The fulfilment flow becomes a versioned model that analysts can read, with parallel and conditional gateways, timers for escalation, compensation handlers and human tasks. Changing a timeout or a failure route is a model change, not a code change.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Service instance | Service Inventory | SOM | Assurance | TMF638. Desired state is on the order; actual state is here. |
| Manual fallout task | SOM (or its work queue) | Operations work queue | — | Must link back to the order item it holds up. |
| Field appointment | Workforce Management | — | SOM | An order item waiting on it shows as pending. |
| Fulfilment workflow model | SOM / BPMN engine | — | — | Versioned; in-flight orders finish on the version they started on. |
In practice
In brownfield estates service inventory is often the weakest record. Services provisioned by older stacks were never written to it, so modify and cease orders find nothing to diff against, and fall out by design until the inventory is reconciled.
Template-based execution of the most common order types, with rule-generated plans for the rest, is the usual compromise between predictability and flexibility.
The trade-off
What it solves
Failure handling, state and inventory updates are owned in one place, so an order that goes wrong is visible, recoverable and reported upstream in TMF641 terms.
What it does not solve
- The causes of fallout, which are mostly catalog and data quality problems upstream.
- Inventory that was never populated for services delivered by older stacks.
- Partner and field delays, which SOM can track but not shorten.
What it adds
- Compensation paths must be designed and tested for every step that can fail late.
- Workflow models need versioning, with in-flight orders kept on the version they started.
- Event subscriptions between SOM, COM and ROM must be monitored, or orders stall silently.
Architecture decision
When automation fails, should SOM roll the order back or hold it for a person?
Compensate and fail
Choose when the failure is deterministic (no capacity, invalid design) and a clean failure lets COM re-offer or re-plan.
Hold and route to a work queue
Choose when the failure is likely fixable by a person (data error, missed appointment) and the work already done is costly to repeat.
Breaks if every failure goes to a manual queue by default. Fallout becomes the normal path, queues grow faster than staff, and nobody fixes the upstream causes.
Takeaways
Key Takeaways
- Failure handling is retry, manual routing, compensation, escalation and partial reporting
- SOM keeps service inventory (TMF638) in step: reserved, updated, active, terminated
- COM follows SOM through TMF641 events, not by polling
- Most estates combine catalog-driven decomposition with process-driven execution, often on BPMN
Check yourself
A cease order falls out because SOM finds no service instance to terminate. What is the likely root cause?Show answerHide
The service was provisioned before (or outside) the current stack and was never written to service inventory. The fix is reconciliation of inventory, not a change to SOM.
How does COM learn that one item in a service order is held?Show answerHide
From a TMF641 ServiceOrderItemStateChangeEvent published by SOM, delivered through COM’s subscription on the event hub.
Fallout is 25% on new connections. Where would you look first?Show answerHide
Upstream of SOM: catalog design (missing or wrong decomposition and dependency rules) and data quality (serviceability, inventory). SOM’s failure handling only manages the symptoms.