Service Location Support for Multiple Places in a Single Order Line Item (TMF622 → SOM)

MalayanurKR · 3 weeks ago

Hi Community,

I am looking to understand the out-of-the-box (OOTB) capabilities in ServiceNow Order Management (SOM) for handling multiple service locations on a single Order Line Item (OLI).

Scenario: In a TMF622 Product Order, a single product can contain multiple entries in the place[] array. For example, a product may be associated with three different service locations.

When this order is processed in SOM:

A single Order Line Item (OLI) is created for the product.
The standard Service Location field on the OLI is a reference field and can only store a single location.
As a result, I am unable to directly map all three locations received in the TMF622 place[] array to the OLI.

Questions:

Is there any OOTB capability in SOM to support multiple locations for a single OLI?
How does ServiceNow recommend capturing multiple service locations associated with the same ordered product?
Would the recommended approach be to create multiple Product Specification characteristics (for example, a location characteristic with data type Array.Object) and store the TMF622 place[] data there?
If so, can these location-specific characteristics then be leveraged during decomposition to segregate and process the individual locations?

My primary goal is to understand whether there is an existing OOTB pattern for supporting the TMF622 place array on a single Order Line Item, or if this requires a custom implementation using characteristics.

Any guidance, best practices, or implementation experiences would be greatly appreciated.

Thanks!

Kailash Bhange · a week ago

Here's a new draft that stands on its own:

Hi @MalayanurKR

Good question. This comes up often on TMF622 integrations. Here's how I'd answer each point.

1. Is there an OOTB capability for multiple locations on one OLI?

No. SOM's data model is built on one ordered product at one service location. The Order Line Item's location field is a single reference, and the OOTB TMF622 inbound processing fills it from a single place entry. The rest of the process relies on that one-to-one relationship:

decomposition into service and resource order lines
the installed base (the sold product or service instance is created per location)
field dispatch and site-level fulfilment tasks
billing, assurance and later MACD (Move/Add/Change/Disconnect) orders

So a productOrderItem with three entries in place[] has no OOTB mapping to one OLI.

2. How should multiple service locations be captured?

The recommended pattern is one Order Line Item per service location. This is what SOM is designed for, and it keeps everything downstream OOTB. There are two ways to get there:

Option A: Split at the source (preferred)
The upstream system (CPQ, portal or BSS) sends one productOrderItem per location, each with a single place. This fits the TMF622 model best, because each item can then have its own state, dates and lifecycle.

Option B: Split during inbound processing in ServiceNow
If you can't change the source payload, add pre-processing to the TMF622 inbound handling, either through the API's extension points or a scripted step before order creation. It should:

Loop through place[] and create one line item per entry, with a unique line item ID.
Resolve each place.id or address to a real location or customer site record, and set it in the OLI location field.
Keep the original productOrderItem.id on each split line (for example in a characteristic or custom field). Outbound state updates and TMF622 notifications can then be rolled up and mapped back to the item the upstream system sent.

If the locations have different roles (TMF622 place.role, e.g. installation address vs. billing address), look at whether only one of them is really the service location. The others can often be stored as supporting information instead of creating extra lines.

3. Should place[] go into a characteristic (Array/Object data type)?

It's technically possible, but I wouldn't use it as the main design. It's fine as a pass-through or audit copy of the original payload. The drawbacks of relying on it:

There's no referential integrity to location or site records, and reporting and querying are limited.
The data isn't usable in the order workspace UI or in location-based validations and qualification.
Downstream processes still need one real location per component, so the array has to be unpacked later anyway.
MACD gets difficult: changing or disconnecting one of the three locations is hard when all three sit on one line and one installed product.

4. Can those characteristics drive decomposition per location?

Not OOTB. Decomposition is specification-driven: product spec → service spec → resource spec, with characteristic value mapping. It creates service order lines per mapped specification for each OLI. It doesn't loop over array elements inside a characteristic value.

To split per location from an array characteristic, you'd need custom decomposition logic, such as a custom script or Flow action that parses the array and creates per-location service order lines. You'd also have to build and maintain the status roll-up, error handling and TMF622 notifications yourself. That's usually more custom code and more upgrade risk than splitting the lines at intake. Once they're split, OOTB decomposition and orchestration work per location without changes.

Summary

Approach OOTB alignment Recommendation

One OLI per place (split at source)	Full	✅ Preferred
One OLI per place (split in inbound processing)	High, with a small customization at intake	✅ Good fallback
place[] in an Array/Object characteristic	Low: needs custom decomposition and fulfilment	⚠️ Only as a payload reference

To answer your main question directly: there's no OOTB pattern that supports the TMF622 place[] array on a single OLI. The OOTB-friendly approach is to normalize to one location per line item. Using characteristics for this means a custom implementation.

Hope this helps. Please mark it helpful/correct if it answers your question.

Thanks!

Kailash Bhange