---
sourceDocument: Australia Telecommunications, Media, and Technology
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/telecom-media-technology

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Telecommunications, Media, and Technology

ft:clusterId :

    - telmt

bundleId :

    - telmt

workflow :

    - Customer and Industry


---

# Multi-domain service orders

# Multi-domain service order orchestration {#ariaid-title1}

Release version: Australia  
Updated July 14, 2025  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Multi-domain service order orchestration

Multi-domain service order orchestration in Sales CRM for Telecommunications enables the decomposition of a single customer order into multiple parallel domain orders.
Each domain order is automatically routed to the appropriate fulfillment domain---such as service design, network provisioning, supply chain, or field operations---using catalog-defined specification relationships and TMF Open API standards.
This orchestration coordinates complex service design, resource provisioning, and field operations through automated dependency sequencing and parallel task execution, all managed within a unified orchestration platform.
Show full answer Show less  

## Key Features

* **Multi-domain order decomposition:** Automatically breaks down customer orders into domain-specific orders routed to different fulfillment systems based on catalog rules.
* **Parallel subflow execution:** Runs domain order subflows concurrently when no dependencies exist to reduce total fulfillment time.
* **Catalog-defined dependency sequencing:** Enforces wait conditions between dependent domain orders, ensuring correct sequencing without manual coordination.
* **Multi-standard TMF routing:** Routes domain orders to external systems using TMF641 Service Order standards, eliminating the need for custom adapters.
* **Inbound response consumption:** Automatically processes API responses---such as resource IDs and work order confirmations---and updates domain orders and inventory records.
* **CMDB and Install Base Integration:** Creates or updates configuration items and inventory records during orchestration, maintaining consistent, accurate service and infrastructure data.
* **Outbound request and error management:** Tracks outbound API requests and errors systematically with retry capabilities.
* **Fallout management:** Isolates and tracks domain order tasks that fail without blocking other subflows, allowing targeted issue resolution.

## Key Outcomes

* Eliminates manual order construction and coordination by automating decomposition and sequencing of multi-domain orders.
* Ensures data consistency across orders, inventory, and CMDB through automated mapping and updates during orchestration.
* Reduces overall service fulfillment time by enabling parallel processing of independent domain orders.
* Provides robust error and fallout management to maintain fulfillment flow continuity and facilitate efficient problem resolution.
* Supports standardized integration using TMF Open APIs, simplifying connectivity with multiple external fulfillment systems.  
Sales CRM for Telecommunications decomposes a customer order into multiple parallel domain orders. Each order is routed to the appropriate fulfillment domain using catalog-defined subflows and TMF Open API standards. Dependency sequencing coordinates service design, resource provisioning, and field operations.
Multi-domain service order (MDSO) orchestration in Sales CRM for Telecommunications decomposes a single customer order into multiple domain orders, each routed to a different fulfillment domain using catalog-defined specification relationships. Each domain order runs an independent
subflow a task sequence that triggers an outbound API request, consumes the response, and closes the domain order on completion.

Domain orders run in parallel by default. Where one domain order depends on the output of another, catalog-defined decomposition rules enforce the wait condition automatically. Each domain order routes to its target system using
the appropriate TMF Open API standard. The platform manages outbound requests, inbound responses, and error handling within a single orchestration view.
Figure 1. Multi-domain service order orchestration

## Benefits {#mdso-service-order-orchestration-somt__mdso-benefits}

* A single customer order decomposes into multiple domain orders, each routed to the appropriate fulfillment domain using catalog-defined rules, without manual order construction.
* Catalog-defined decomposition rules enforce dependency sequencing between domain orders automatically, removing the need for manual coordination between fulfillment teams.
* Each domain order routes to its target system using the appropriate TMF Open API standard TMF641 removing the need for custom integration adapters per domain.
* The platform maps characteristic values from external system responses back to the order and inventory records automatically, maintaining data consistency across the order, IBI, and CMDB.
* The platform creates or updates CMDB configuration items during subflow execution, giving operations teams an accurate view of provisioned services without manual CI updates.
* Parallel subflow execution across fulfillment domains reduces the total time from order approval to service activation.
* Fallout management tracks domain orders and tasks that can't complete, enabling targeted resolution without blocking other subflows in the same MDSO.
{#mdso-service-order-orchestration-somt__ul_cmk_dwz_tjc}

## Features {#mdso-service-order-orchestration-somt__mdso-features}

{#mdso-service-order-orchestration-somt__table-mdso-features__entry__2}

| Feature | Description |
|-|-|
| Multi-domain order decomposition | Decomposes a single customer order line item into multiple domain orders, each targeting a different fulfillment domain. Targets include service design, network provisioning, supply chain, or field operations based on catalog-defined specification relationships. |
| Parallel subflow execution | Runs domain order subflows in parallel where no dependency exists, reducing total fulfillment time. Each subflow manages its own task sequence, outbound API call, and response consumption independently. |
| Catalog-defined dependency sequencing | Enforces wait conditions between domain orders using decomposition rules. Dependent subflows pause until the required domain order completes and returns the necessary output. For example, a Circuit ID or service activation confirmation. |
| Multi-standard TMF routing | Routes domain orders to external systems using TMF641 (Service Order) standards within a single orchestration. The outbound standard is determined by the domain order type and the Service Order Outbound Policy decision table. |
| Inbound response consumption | Consumes API responses from external systems including resource identifiers, characteristic values, and work order confirmations and maps them back to the domain order and inventory records automatically. |
| CMDB and IBI integration | Creates or updates CMDB configuration items and Install Base (IBI) inventory records during subflow execution. Characteristic values from service design responses are mapped to CI records, maintaining alignment between the order, inventory, and CMDB. |
| Outbound request and error management | Manages outbound request state, inbound response handling, and error conditions for each domain order. Failed or error outbound requests are tracked in the Outbound Request table \[sn_tmt_core_outbound_request\] for investigation and retry. |
| Fallout management | Creates fallout records for domain order tasks that can't complete. Fallout records are tracked separately from the main fulfillment flow, so other domain orders in the same MDSO continue processing while the fallout is investigated and resolved. |
[Table 1. Multi-domain service order orchestration features]

{#mdso-service-order-orchestration-somt__table-mdso-features}